SIP Header Fields |
153 |
If the dialog referenced in the Join header field does not exist, a 481 Call/ Dialog Does Not Exist response is returned. A UA supporting Join should indicate this in all requests with a Supported: join header field.
In the following example, the dialog:
To: <sip:moe@example.org>;tag=42312
From: <sip:larry@server.org>;tag=3443212
Call-ID: 243134123234
would match the Join header field:
Join: 243134123234;to-tag=42312;from-tag=3443212
6.2.11 Priority
The Priority header field is used by a UAC to set the urgency of a request. De-
fined values are non-urgent, normal, urgent, and emergency. This header field
could be used to override screening or by servers in load-shedding mechanisms. Because this header field is set by the UA, it may not be possible for a carrier network to use this field to route emergency traffic, for example. An example is:
Priority: emergency
6.2.12 Privacy
The Privacy header field [24] is used by a UAC to request varying degrees and types of privacy. Currently defined tags include critical, header, id, session,
user, or none.
An example follows:
Privacy: header;user;critical
6.2.13 Proxy-Authorization
The Proxy-Authorization header field is to carry the credentials of a UA in a request to a server. It can be sent in reply to a 407 Proxy Authentication Required response containing challenge information, or it can be sent first without waiting for the challenge if the form of the challenge is known (e.g., if it has been cached from a previous call). The authentication mechanism for SIP digest is described in Section 14.4.1. A proxy receiving a request containing a Proxy-Authorization header field searches for its own realm, and if found it processes the entry. If the credentials are correct, any remaining entries are kept in the request when it is forwarded to the next proxy. An example of this is in Figure 6.2.
Examples are shown in Table 6.15.
154 |
|
|
SIP: Understanding the Session Initiation Protocol |
||||||||||||||||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Figure 6.2 Multiproxy authentication example. Note: In this figure, P-A stands for the ProxyAuthorization header field.
|
Table 6.15 |
||
|
Example of a Proxy-Authorization Header Field |
||
Header Field |
Meaning |
||
|
|
|
|
Proxy-Authorization: Digest |
This digest authorization header field |
||
contains the credentials of Customer1. |
|||
username=”Customer1”, |
|||
The nonce was supplied by the SIP server |
|||
realm=”company.com”, |
|||
nonce=”9c8e88df84f1cec4341ae6e5a359”, |
located at the URI specified. The response |
||
opaque=””, uri=”sip:user@company.com”, |
contains the hashed user name and |
||
response=”e56131d19580cd833064787ecc” |
|||
password; no opaque string is present. |
|||
|
|
||
6.2.14 |
Proxy-Require |
|
|
The |
Proxy-Require header field is used |
to list features and extensions that |
|
a UA requires a proxy to support in order to process the request. A 420 Bad Extension response is returned by the proxy listing any unsupported feature in an Unsupported header field. Because proxies by default ignore header fields and features they do not understand, the use of a Proxy-Require header field is needed for the UAC to be certain that the feature is understood by the proxy. If the support of this option is desired but not required, it is listed in a Supported header field instead. An example is:
Proxy-Require: timer
SIP Header Fields |
155 |
6.2.15 P-OSP-Auth-Token
The P-OSP-Auth-Token header field [36] is used to transport an Open Settlements Protocol (OSP) token [37] with a SIP INVITE request. A gateway or proxy server receiving a token can verify the token and use this information about accepting the INVITE or rejecting the call. This approach is suitable for a clearinghouse model of VoIP carrier interconnection.
An example is:
P-OSP-Auth-Token: 3b8a40c10b4930ff19a85766c15182a34048d9398b834d6 ;realm=”carrier.com”
6.2.16 P-Asserted-Identity
The P-Asserted-Identity header field [38] is used between trusted intermediaries (proxies) to assert the identity of a UA that has been authenticated using some means such as those described in Chapter 14. A UA receiving a request from a proxy that it trusts will typically render the value in a P-Asserted-Identity header field to the user as a “Verified Caller ID” as opposed to a From header value which is unverified. A proxy receiving a P-Asserted-Identity from another proxy that it does not trust will remove the header field.
An example is:
P-Asserted-Identity: <sip:user@example.com>
6.2.17 P-Preferred-Identity
The P-Preferred-Identity header field [38] is used by a UA to tell a trusted intermediary which identity it would prefer to be asserted on its behalf when more than one identity is associated with that UA.
An example is:
P-Preferred-Identity: <sip:alternate@example.com>
6.2.18 Max-Breadth
The Max-Breadth header field [39] is part of the solution to an amplification attack on forking proxy servers. This header field is inserted by proxy servers and decremented based on the breadth (number of concurrent branches) of a forking operation. When the Max-Breadth count goes to zero, the 440 Max-Breadth Exceeded response is returned. Example:
Max-Breadth: 32
156 |
SIP: Understanding the Session Initiation Protocol |
6.2.19 Max-Forwards
The Max-Forwards header field is used to indicate the maximum number of hops that a SIP request may take. The value of the header field is decremented by each proxy that forwards the request. A proxy receiving the header field with a value of zero discards the message and sends a 483 Too Many Hops response back to the originator.
Max-Forwards is a mandatory header field in requests generated by an RFC 3261 compliant UA. However, an RFC 2543 UA generally will not include the header field. The suggested initial value is 70 hops.
An example is:
Max-Forwards: 10
6.2.20 Reason
The Reason header field [40] can be used in BYE and CANCEL messages to indicate the reason why the session or call attempt is being terminated. It can carry a SIP response code or a Q.850 cause value (from an ISUP REL message, for example).
For example, a forking proxy could include the following header field in a CANCEL sent to a leg after one leg has answered the call.
Reason: SIP ;cause=200 ;text=”Call completed elsewhere”
6.2.21 Refer-To
The Refer-To header field [41] is a required header field in a REFER request, which contains the URI or URL resource that is being referenced. It may contain any type of URI from a sip or sips to a tel URI to an http or mailto URI. For a sip or sips URI, the URI may contain a method or escaped header fields. For example, the following Refer-To header field (where a line break has been added for display):
Refer-To: <sip:UserC@client.anywhere.com?Replaces=
sdjfdjfskdf@there.com%3Bto-tag%3D5f35a3%3Bfrom-tag%3D8675309>
contains an escaped Replaces header field. The resulting INVITE message generated by this Refer-To header field would have a Request-URI of
sip:UserC@client.anywhere.com
and a