146 |
SIP: Understanding the Session Initiation Protocol |
6.1.24 Supported
The Supported header field is used to list one or more options implemented by a UA or server. It is typically included in responses to OPTIONS requests. If no options are implemented, the header field is not included. If a UAC lists an option in a Supported header field, proxies or UASs may use the option during the call. If the option must be used or supported, the Require header field is used instead. Table 6.10 shows the current set of defined feature tags.
An example of the header field is:
Supported: rel100
Table 6.10
Extension Feature Tags
Tag |
Meaning |
answermode early-session eventllist events from-change gruu histinfo
ice join
multiple-refer norefsub outbound
path precondition pref
privacy recipient-list-invite recipient-list-message recipient-list-subscribe rel100
replaces resource-priority sdp-anat sec-agree tdialog
timer
Answer-Mode and Priv-Answer-Mode header fields
Support of early-session content disposition
Resourcelist extension
SIP Events [4]
From and To URI changes in a dialog [14] Globally Routable User Agent URI [15] History-Info header field [10]
Support for ICE [16]
Join call control primitive [17] REFER with resource-list [18]
REFER without implicit subscription and NOTIFYs [19] SIP outbound NAT traversal feature [20]
Path header field [21] SIP preconditions [22] Caller prefs [23]
Privacy mechanisms [24] INVITE with resource list [25] MESSAGE with resource list [26]
SUBSCRIBE with resource list [27]
Reliable provisional response (PRACK) support [28] Replaces call control primitive [29]
Resource-Priority header field [30] Alternative address for NAT (deprecated) [31] SIP security agreement mechanism [32]
header field [33] Session timer feature [34]
SIP Header Fields |
147 |
6.1.25 Timestamp
The Timestamp header field is used by a UAC to mark the exact time a request was generated in some numerical time format. A UAS must echo the header field in the response to the request and may add another numerical time entry indicating the amount of delay. Unlike the Date header field, the time format is not specified. The most accurate time format should be used, including a decimal point. Examples are shown in Table 6.11. The default value of 500 ms is used for T1.. Timestamp is not commonly used.
6.1.26 To
The To header field is a required header field in every SIP message used to indicate the recipient of the request. Any responses generated by a UA will contain this header field with the addition of a tag. (Note that an RFC 2543 client will typically only generate a tag if more than one Via header field is present in the request.) Any response generated by a proxy must have a tag added to the To header field. A tag added to the header field in a 200 OK response is used throughout the call and incorporated into the dialog. The To header field URI is never used for routing—the Request-URI is used for this purpose. An optional display name can be present in the header field, in which case the SIP URI is enclosed in < >. If the URI contains any parameters or username parameters, the URI must be enclosed in < > even if no display name is present. The compact form of the header field is t. Examples are shown in Table 6.12.
6.1.27 User-Agent
The User-Agent header field is used to convey information about the UA originating the request. Based on the HTTP header field of the same name [2], it can contain manufacturer information, software version, or comments. The field may contain multiple tokens, with the ordering assumed to be from most general to most specific. This information can be used for logging or for generating a specific response for a specific UA. For security reasons, this header field may be suppressed. For example, an attacker probing a UA for vulnerabilities could learn the particular vendor and software load that is susceptible to a particular attack
|
Table 6.11 |
|
Examples of a Timestamp Header Field |
Header Field |
Meaning |
|
|
Timestamp: 235.15 |
Client has stamped a start time for the request. |
Timestamp: 235.15 |
This header field from the response has the delay time |
.95 |
|
|
added by the server. |
148 |
SIP: Understanding the Session Initiation Protocol |
|
|
Table 6.12 |
|
|
Examples of a To Header Field |
|
Header Field |
Meaning |
|
To: sip:babage@engine.org;tag=2443a8f7
To: Thomas Edison <sips:edison@elec.com>
t: “Jim B.” <brattain@bell.org>
To: <+1-314-555-1212@carrier.com
;user=phone>;tag=8f7f7ad6675
A single SIP URI with a tag and without a display name.
A display name is used, so the sips URI is enclosed in < >.
A display name in quotes along with a SIP URI enclosed within < >.
Both a URI parameter and tag are used, so URI is enclosed in <>. Note that no line breaks are permitted in a URI.
and reuse that attack against other UAs that have the same software as identified by the User-Agent header field.
Examples include:
User-Agent: Acme/v2.2
User-Agent: Carrier/Beta
6.1.28 Via
The required Via header field is used to record the SIP route taken by a request and is used to route a response back to the originator. A UA generating a request records its own address in a Via header field. While the ordering of most SIP header fields is not significant, the Via header fields order is significant because it is used to route responses. A proxy forwarding the request adds a Via header field containing its own address to the top of the list of Via header fields. A proxy adding a Via header field always includes a branch tag containing a cryptographic hash of the To, From, Call-ID header fields and the Request-URI. A proxy or UA generating a response to a request copies all the Via header fields from the request in order into the response, then sends the response to the address specified in the top Via header field. A proxy receiving a response checks the top Via header field to ensure that it matches its own address. If it does not, the response has been misrouted and should be discarded. The top Via header field is then removed, and the response forwarded to the address specified in the next Via header field.
Via header fields contain protocol name, version number, and transport (SIP/2.0/UDP, SIP/2.0/TCP, etc.) and may contain port numbers and parameters
such as received, rport, branch, maddr, and ttl. A received tag is added to
a Via header field if a UA or proxy receives the request from a different address than that specified in the top Via header field. If an rport tag is included in a Via in a request, a proxy will insert the port the request was received on and use this