134 |
SIP: Understanding the Session Initiation Protocol |
|||
|
|
Table 6.1 |
|
|
|
|
Compact Forms of SIP Header Fields |
||
|
|
Header Field |
Compact Form |
|
|
|
Accept-Contact |
a |
|
|
|
Allow-Event |
u |
|
|
|
Call-ID |
i |
|
|
|
Contact |
m |
|
|
|
Content-Encoding |
e |
|
|
|
Content-Length |
l |
|
|
|
Content-Type |
c |
|
|
|
Event |
o |
|
|
|
From |
f |
|
|
|
Refer-To |
r |
|
|
|
Referred-By |
b |
|
|
|
Reject-Contact |
j |
|
|
|
Subject |
s |
|
|
|
To |
t |
|
|
|
Via |
v |
|
|
|
|
|
|
6.1 Request and Response Header Fields
This set of header fields can be present in both requests and responses.
6.1.1Accept
The Accept header field is defined by HTTP [2] and is used to indicate acceptable message Internet media types [3] in the message body. The header field describes media types using the format type/sub-type commonly used in the Internet. If not present, the assumed acceptable message body format is application/sdp. A list of media types can have preferences set using q value parameters. The wildcard “*” can be used to specify all sub-types. Examples are given in Table 6.3.
6.1.2Accept-Encoding
The Accept-Encoding header field, defined in HTTP [2], is used to specify acceptable message body encoding schemes. Encoding can be used to ensure a SIP message with a large message body fits inside a single UDP datagram. The use of q value parameters can set preferences. If none of the listed schemes are acceptable to the UAC, a 406 Not Acceptable response is returned. If not included, the assumed encoding will be text/plain. Examples include:
SIP Header Fields |
135 |
Table 6.2
Header Fields That May Be Inserted or Modified by Proxies
Hop-by-Hop Header Fields
Alert-Info
Call-Info
Content-Length
Date
Error-Info
Max-Breadth
Max-Forwards
Organization
Priority
Proxy-Authenticate
Proxy-Authorization
Proxy-Require
Record-Route
Reason
Require
Route
Via
WWW-Authenticate
Security-Client
Security-Verify
Security-Server
Answer-Mode
Priv-Answer-Mode
History-Info
Path
Identity
Identity-Info
P-Asserted-Identity
Reason
Resource-Priority
Auth-Info
|
Table 6.3 |
|
Examples of an Accept Header Field |
Header Field |
Meaning |
|
|
|
This is the default assumed even if no |
Accept: application/sdp |
|
|
Accept header field is present. |
Accept: text/* |
Accept all text encoding schemes. |
Accept: application/
h.245;q=0.1, Use SDP if possible, otherwise, use H.245. application/sdp;q=0.9
136 |
SIP: Understanding the Session Initiation Protocol |
Accept-Encoding: text/plain
Accept-Encoding: gzip
6.1.3Accept-Language
The Accept-Language header field, defined in HTTP [2], is used to specify preferences of language. The languages specified can be used for reason phrases in responses, informational header fields such as Subject, or in message bodies. The HTTP definition allows the language tag to be made of a primary tag and an optional subtag. This header field could also be used by a proxy to route to a human operator in the correct language. The language tags are registered by IANA, and the primary tag is an ISO-639 language abbreviation. The use of q values allows multiple preferences to be specified. Examples are shown in Table 6.4.
6.1.4Alert-Info
The Alert-Info header field can be used to provide a “distinctive ring” service. If present in an INVITE, the UAS may use the URI to fetch an alert tone to be used in place of the default alerting tone—that is, it would be rendered to the called party. If present in a 180 Ringing response, the UAC may use the URI to fetch a ring-back tone to be rendered to the calling party. In both uses, the URI is fetched and rendered without user intervention, so careful policy rules are necessary to avoid unwanted sounds and noises being generated.
One use is for a trusted proxy to insert the header field with a local (to the domain of the user agent) URI. This then allows for very simple policy in the user agent in deciding whether or not to render. Another approach is for a URN to be used, which would tell the user agent which service tone to play for the user.
An example is shown here:
Alert-Info: <http://www.provider.com/tones/internal_caller.pcm>
Table 6.4
Examples of an Accept-Language Header Field
Header Field |
Meaning |
Accept-Language: fr
Accept-Language: en, ea
Accept-Language: ea; q=0.5, en ;q=0.9, fr ;q=0.2
French is the only acceptable language.
Acceptable languages include both English and Spanish.
Preferred languages are English, Spanish, and French, in that order.
SIP Header Fields |
137 |
6.1.5Allow
The Allow header field is used to indicate the methods supported by the UA or proxy server sending the response. The header field must be present in a 405 Method Not Allowed response and should be included in a positive response to an OPTIONS request. Allow is often present in INVITE and 200 OK responses. An example is:
Allow: INVITE, ACK, BYE, INFO, OPTIONS, CANCEL
6.1.6Allow-Events
The Allow-Events header field [4] is used to list the event packages that are supported. A UA that supports SIP events will then know that it may send a SUBSCRIBE for that event package. The list of currently defined packages is in Table 4.8. The compact form is u.
Examples are shown here:
Allow-Events: dialog
u:conference
6.1.7Answer-Mode
The Answer-Mode header field [5] is used to request an immediate answer (200 OK) to an INVITE. Two values, Manual and Auto, have been defined. The Manual setting is normal behavior while Auto means the request should be accepted immediately without input from the user. A header field parameter require is defined to indicate that if the requested behavior is not permitted, the request should be rejected with a 403 Forbidden response. This extension can be used for a number of features including loopback tests, intercom, and push-to-talk. The Answer-Mode header field can be included in a 200 OK response to an INVITE to indicate how the request was answered. For example, if the require parameter is not present and the call is answered by the user, an Answer-Mode: Manual header field can be included in the 200 OK. The Priv-Answer-Mode is similar but requests a privilege treatment. The SIP option tag answermode is used to indicate support for this extension. Example:
Answer-Mode: Auto;require
6.1.8Call-ID
The Call-ID header field is mandatory in all SIP requests and responses. It is part of the dialog used to uniquely identify a call between two user agents. A