| Article Index |
|---|
| Header Fields in SIP |
| Page 2 |
| Page 3 |
| Page 4 |
| Page 5 |
| Page 6 |
| Page 7 |
| Page 8 |
| Page 9 |
| Page 10 |
| Page 11 |
| Page 12 |
| Page 13 |
| Page 14 |
| Page 15 |
| Page 16 |
| All Pages |
Page 3 of 16
20.2 Accept-Encoding
The Accept-Encoding header field is similar to Accept, but restricts
the content-codings [H3.5] that are acceptable in the response. See
[H14.3]. The semantics in SIP are identical to those defined in
[H14.3].
An empty Accept-Encoding header field is permissible. It is
equivalent to Accept-Encoding: identity, that is, only the identity
encoding, meaning no encoding, is permissible.
If no Accept-Encoding header field is present, the server SHOULD
assume a default value of identity.
This differs slightly from the HTTP definition, which indicates that
when not present, any encoding can be used, but the identity encoding
is preferred.
Example:
Accept-Encoding: gzip
20.3 Accept-Language
The Accept-Language header field is used in requests to indicate the
preferred languages for reason phrases, session descriptions, or
status responses carried as message bodies in the response. If no
Accept-Language header field is present, the server SHOULD assume all
languages are acceptable to the client.
The Accept-Language header field follows the syntax defined in
[H14.4]. The rules for ordering the languages based on the "q"
parameter apply to SIP as well.
Example:
Accept-Language: da, en-gb;q=0.8, en;q=0.7
20.4 Alert-Info
When present in an INVITE request, the Alert-Info header field
specifies an alternative ring tone to the UAS. When present in a 180
(Ringing) response, the Alert-Info header field specifies an
alternative ringback tone to the UAC. A typical usage is for a proxy
to insert this header field to provide a distinctive ring feature.
The Alert-Info header field can introduce security risks. These
risks and the ways to handle them are discussed in Section 20.9,
which discusses the Call-Info header field since the risks are
identical.
In addition, a user SHOULD be able to disable this feature
selectively.
This helps prevent disruptions that could result from the use of
this header field by untrusted elements.
Example:
Alert-Info: <http://www.example.com/sounds/moo.wav>




