| The Warning header field is used to carry additional information about the
status of a response. Warning header field values are sent with responses
and contain a three-digit warning code, agent name, and warning text.
- Warning Text: The "warn-text" should be in a natural language that is
most likely to be intelligible to the human user receiving the response.
This decision can be based on any available knowledge, such as the location
of the user, the Accept-Language field in a request, or the Content-Language
field in a response.
- Warning Code: The currently-defined "warn-code"s have a recommended
warn-text in English and a description of their meaning. These warnings
describe failures induced by the session description. The first digit of
warning codes beginning with "3" indicates warnings specific to SIP. Warnings
300 through 329 are reserved for indicating problems with keywords in the
session description, 330 through 339 are warnings related to basic network
services requested in the session description, 370 through 379 are warnings
related to quantitative QoS parameters requested in the session description,
and 390 through 399 are miscellaneous warnings that do not fall into one of
the above categories. Additional "warn-code"s can be defined.
Any server may add WarningHeaders to a Response. Proxy servers must place
additional WarningHeaders before any AuthorizationHeaders. Within that
constraint, WarningHeaders must be added after any existing WarningHeaders
not covered by a signature. A proxy server must not delete any WarningHeader
that it received with a Response.
When multiple WarningHeaders are attached to a Response, the user agent
should display as many of them as possible, in the order that they appear
in the Response. If it is not possible to display all of the warnings, the
user agent first displays warnings that appear early in the Response.
Examples of using Warning Headers are as follows:
- A UAS rejecting an offer contained in an INVITE SHOULD return a 488 (Not
Acceptable Here) response. Such a response SHOULD include a Warning header
field value explaining why the offer was rejected.
- If the new session description is not acceptable, the UAS can reject it
by returning a 488 (Not Acceptable Here) response for the re-INVITE. This
response SHOULD include a Warning header field.
- A 606 (Not Acceptable) response means that the user wishes to communicate,
but cannot adequately support the session described. The 606 (Not Acceptable)
response MAY contain a list of reasons in a Warning header field describing
why the session described cannot be supported.
- Contact header fields MAY be present in a 200 (OK) response and have the
same semantics as in a 3xx response. That is, they may list a set of
alternative names and methods of reaching the user. A Warning header field
MAY be present.
For Example:
Warning: 307 isi.edu "Session parameter 'foo' not understood"
author:
BEA Systems, NIST
version:
1.2 |