SIP Header Fields
6.2 Request Header Fields
This set of header fi elds can only be present in a request.
6.2.1 Accept-Contact
The Accept-Contact [23] header fi eld specifi es to which URIs the request may be proxied. Some additional parameters are also defi ned for Contact header fi elds such as media, duplex, and language. This header fi eld is part of the caller pref-erences extensions to SIP, which have been defi ned to give some control to the caller in the way a proxy server processes a call. The compact form is a.
Some examples follow:
IPv4 address using unicast UDP transport and assumed port of 5060.
Via: SIP/2.0/TCP cube451.offi ce.com:60202 ;branch=z9hG4bK776a
Domain name using TCP transport and port number 60202.
Compact form with domain name using UDP; third search location of forking proxy.
Via: SIP/2.0/TCP 192.168.1.2;received=12.4.5.50 ;rport=42212 ;branch=z9hG4bK334
IPv4 address is nonglobally unique.
Request has been forwarded through a NAT, which has created a mapping with a different IP address and port (mapped address is
12.4.5.50:42212).
Accept-Contact: *;language=en a: *;media=video
6.2.2 Authorization
The Authorization header fi eld is used to carry the credentials of a UA in a request to a server. It can be sent in reply to a 401 Unauthorized response con-taining challenge information, or it can be sent fi rst 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 HTTP digest is described in Section 14.4.1. Examples are shown in Table 6.14.
6.2.3 Call-Info
The Call-Info header fi eld is included in a request by a UAC or proxy to pro-vide a URI with information relating to the session setup. It may be present in an INVITE, OPTIONS, or REGISTER request. The header fi eld parameter purpose indicates the purpose of the URI and may have the values icon, info, card, or other IANA registered tokens.
An example follows:
Call-Info: <http://w w w.code.com/my_picture.jpg>;purpose=icon
6.2.4 Event
The Event header fi eld is used in a SUBSCRIBE (see Section 4.1.7) or NOTIFY (see Section 4.1.8) methods to indicate which event package is being used by the method. In a SUBSCRIBE, it lists the event package to which the client would like to subscribe. In a NOTIFY, it lists the event package that the notifi cation contains state information about. Currently defi ned event packages are listed in Table 4.8.
The compact form is o.
Table 6.14
Example of an Authorization Header Field
Header Field Meaning
Authorization: Digest username=”Cust1”, realm=”company.com”,
nonce=”9c8e88df84f1cec4341ae6e5a359”, opaque=””, uri=”sip:[email protected]”, response=”e56131d19580cd833064787ecc”
This HTTP digest authorization header fi eld contains the credentials of Cust1;
the nonce was supplied by the SIP server located at the URI specifi ed.
The response contains the hashed username and password. No opaque string is present.
SIP Header Fields 151
An example follows:
Event: dialog o: refer
6.2.5 Hide
The Hide header fi eld was defi ned in RFC 2543 but has been deprecated (re-moved) from RFC 3261. It was intended to be used by UAs or proxies to request that the next hop proxy encrypts the Via header fi elds to hide message routing path information. Encrypted Via headers were identifi ed with the hidden Via parameter. However, the security provided and the mechanism requiring next hop trust made the value of this header fi eld minimal.
6.2.6 Identity
The Identity header fi eld [35] is part of the enhanced SIP identity extension, described in more detail in Chapter 14. It is inserted by a proxy server in a for-warded request after the request has been authenticated. The header fi eld con-tains a digital signature over certain parts of the SIP message and the entire message body. The header fi eld is used to certify the identity in the From header fi eld by a proxy in the domain.
6.2.7 Identity-Info
The Identity-Info header fi eld [35] is part of the enhanced SIP identity exten-sion, and is used to convey a URI for the certifi cates containing the public key of the signing proxy. The alg parameter indicates the algorithm used to generate the signature in the Identity header fi eld. In this example, the certifi cate is avail-able from the https URI and the algorithm used is RSA with SHA-1:
Identity-Info: <https://atlanta.example.com/atlanta.cer>
;alg=rsa-sha1
6.2.8 In-Reply-To
The In-Reply-To header fi eld is used to indicate the Call-ID that this request references or is returning. For example, a missed call could be returned with a new INVITE and the Call-ID from the missed INVITE copied into the
In-Reply-To header fi eld. This allows the UAS to determine that this is not an unsolicited
call, which could be used to override call screening logic, for example. Examples of this header fi eld are as follows:
In-Reply-To: [email protected]
In-Reply-To: [email protected], [email protected]
6.2.9 Info-Package
The Info-Package header fi eld [12] is a mandatory header fi eld in an INFO meth-od used to indicate which INFO package is associated with this message. For example:
Info-Package: foo
6.2.10 Join
The Join header fi eld [17] is used in an INVITE to request that the dialog (ses-sion) be joined with an existing dialog (ses(ses-sion). The parameters of the Join header fi eld identify the dialog by the Call-ID, To tag, and From tag in a similar way to the Replaces header fi eld.
If the Join header fi eld references a point-to-point dialog between two user agents, the Join header fi eld is effectively a request to turn the call into a confer-ence call. If the dialog is already part of a conferconfer-ence, the Join header fi eld is a request to be added into the conference. An example call fl ow is shown in Figure 6.1 in which a two-way call is turned into a conference call.
Figure 6.1 Use of Join to create a conference call.
SIP Header Fields 153
If the dialog referenced in the Join header fi eld does not exist, a 481 Call/
Dialog Does Not Exist response is returned. A UA supporting Join should in-dicate this in all requests with a Supported: join header fi eld.
In the following example, the dialog:
To: <sip:[email protected]>;tag=42312 From: <sip:[email protected]>;tag=3443212 Call-ID: 243134123234
would match the Join header fi eld:
Join: 243134123234;to-tag=42312;from-tag=3443212
6.2.11 Priority
The Priority header fi eld is used by a UAC to set the urgency of a request. De-fi ned values are non-urgent, normal, urgent, and emergency. This header fi eld could be used to override screening or by servers in load-shedding mechanisms.
Because this header fi eld is set by the UA, it may not be possible for a carrier network to use this fi eld to route emergency traffi c, for example. An example is:
Priority: emergency
6.2.12 Privacy
The Privacy header fi eld [24] is used by a UAC to request varying degrees and types of privacy. Currently defi ned 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 fi eld is to carry the credentials of a UA in a re-quest to a server. It can be sent in reply to a 407 Proxy Authentication Required
response containing challenge information, or it can be sent fi rst 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 fi eld 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.
6.2.14 Proxy-Require
The Proxy-Require header fi eld 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 fi eld. Because proxies by default ignore header fi elds and features they do not understand, the use of a Proxy-Require header fi eld 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 fi eld instead. An example is:
Proxy-Require: timer
Figure 6.2 Multiproxy authentication example. Note: In this fi gure, P-A stands for the
Proxy-Authorization header fi eld.
Table 6.15
Example of a Proxy-Authorization Header Field
Header Field Meaning
Proxy-Authorization: Digest username=”Customer1”, realm=”company.com”,
nonce=”9c8e88df84f1cec4341ae6e5a359”, opaque=””, uri=”sip:[email protected]”, response=”e56131d19580cd833064787ecc”
This digest authorization header fi eld contains the credentials of Customer1.
The nonce was supplied by the SIP server located at the URI specifi ed. The response contains the hashed user name and password; no opaque string is present.
SIP Header Fields 155
6.2.15 P-OSP-Auth-Token
The P-OSP-Auth-Token header fi eld [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 fi eld [38] is used between trusted intermediar-ies (proxintermediar-ies) 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 fi eld to the user as a “Verifi ed Caller ID” as opposed to a From header value which is unverifi ed. A proxy receiving a P-Asserted-Identity from an-other proxy that it does not trust will remove the header fi eld.
An example is:
P-Asserted-Identity: <sip:[email protected]>
6.2.17 P-Preferred-Identity
The P-Preferred-Identity header fi eld [38] is used by a UA to tell a trusted in-termediary 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:[email protected]>
6.2.18 Max-Breadth
The Max-Breadth header fi eld [39] is part of the solution to an amplifi cation at-tack on forking proxy servers. This header fi eld is inserted by proxy servers and decremented based on the breadth (number of concurrent branches) of a fork-ing operation. When the Max-Breadth count goes to zero, the 440 Max-Breadth Exceeded response is returned. Example:
Max-Breadth: 32
6.2.19 Max-Forwards
The Max-Forwards header fi eld is used to indicate the maximum number of hops that a SIP request may take. The value of the header fi eld is decremented by each proxy that forwards the request. A proxy receiving the header fi eld 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 fi eld in requests generated by an RFC 3261 compliant UA. However, an RFC 2543 UA generally will not include the header fi eld. The suggested initial value is 70 hops.
An example is:
Max-Forwards: 10
6.2.20 Reason
The Reason header fi eld [40] can be used in BYE and CANCEL messages to indi-cate 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 fi eld 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 fi eld [41] is a required header fi eld 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 fi elds. For example, the following Refer-To header fi eld (where a line break has been added for display):
Refer-To: <sip:[email protected]?Replaces=
[email protected]%3Bto-tag%3D5f35a3%3Bfrom-tag%3D8675309>
contains an escaped Replaces header fi eld. The resulting INVITE message gener-ated by this Refer-To header fi eld would have a Request-URI of
and a
SIP Header Fields 157
Replaces: [email protected];to-tag=5f35a3;from-tag=8675309
header fi eld. Note that the characters “;” and “=” are replaced by their hex equiv-alents %3B and %3D. In the next example, the header fi eld containing a method
Refer-To: <sip:[email protected]?method=SUBSCRIBE>
would cause a SUBSCRIBE request to be sent instead of an INVITE, which is the default method if none is present. An example of the Refer-To header fi eld in compact form with an HTTP URL is:
r: <http://w w w.artech-house.com>
6.2.22 Referred-By
The Referred-By header fi eld [42] is an optional header fi eld in a REFER request and a request triggered by a REFER. It provides the recipient of a triggered request with information that the request was generated as a result of a REFER and the originator of the REFER. This information can be presented to the user or have policy applied in deciding how the UA should handle the request.
As this header fi eld could be modifi ed or fabricated, a more secure usage involves the addition of a Referred-By security token. The token is carried as a message body whose content id (cid) is indicated in the Referred-By header fi eld. The token is an S/MIME signature over a message/sipfrag, which con-tains, at a minimum, the From, Date, Call-ID, Refer-To, and Referred-By
header fi elds from the REFER request. An unsigned Referred-By header fi eld may be rejected with a request that the Referred-By security token be included using the 429 Provide Referror Identity response code (see Section 5.4.24). The compact form is b:
Referred-By: <sip:[email protected]>
b: <sips:[email protected]>
6.2.23 Reply-To
The Reply-To header fi eld is used to indicate a sip or sips URI, which should be used in replying to this request. Normally, this URI is present in the From header fi eld (the Contact is not used as it is only assumed valid for the duration of the dialog). However, in some cases, the From cannot be populated with this infor-mation, so the URI in this header fi eld should be used instead of the From URI.
An example is:
Reply-To: <sip:[email protected]>
6.2.24 Replaces
The Replaces header fi eld [29] is used in SIP call control applications. A UA in an established dialog receiving another INVITE with a Replaces header fi eld that matches the existing dialog must accept the INVITE, terminate the existing dialog with a BYE, and transfer all resources and state from the existing dialog to the newly established dialog.
If the Replaces header fi eld matches no dialog, the INVITE must be rejected with a 481 Dialog Does Not Exist response.
In addition, Replaces has one application in pending dialogs. A UAC that has sent an INVITE but has not yet received a fi nal response may receive an INVITE containing a Replaces header fi eld that matches the pending INVITE. The UAC must terminate the pending dialog with a CANCEL (and be prepared to send an
ACK and BYE if a 200 OK eventually arrives) and accept the new INVITE.
For an INVITE containing both a Require: replaces and Replaces header fi eld, this results in the return of one of the following set of responses:
• 200 (if a match is found);
• 481 (if no match is found);
• 420(if Replaces is not supported).
Figure 6.3 shows a call fl ow using Replaces to implement a feature called
“call pickup.” The early parameter means that the replacement should only be done if the dialog is in an early state; if the dialog has transitioned to a confi rmed state, the INVITE should be rejected. Figure 4.9 shows the use of Replaces in an
“attended transfer example.”
This example Replaces header fi eld:
Replaces: 3232904875945;to-tag=34314;from-tag=2343
would match the dialog identifi ed by:
To: <sip:[email protected]>;tag=34314 From: <sip:[email protected]>;tag=2343 Call-ID: 3232904875945
6.2.25 Reject-Contact
The Reject-Contact [23] header fi eld specifi es the URIs to which the request may not be proxied. Some additional parameters are also defi ned for Contact header fi elds such as media, duplex, and language. This header fi eld, along with
SIP Header Fields 159
Accept-Contact and Request-Disposition are part of the SIP caller preferences extensions. The compact form is j. Examples include:
Reject-Contact: sip:[email protected] j: *;media=video
6.2.26 Request-Disposition
The Request-Disposition [23] header fi eld can be used to request servers to either proxy, redirect, or initiate serial or parallel (forking) searches. An example is:
Request-Disposition: redirect
6.2.27 Require
The Require header fi eld is used to list features and extensions that a UAC re-quires a UAS to support in order to process the request. A 420 Bad Extension response is returned by the UAS listing any unsupported features in an
Unsupported header fi eld. If support or use of a feature is desirable but not
Figure 6.3 Call fl ow showing call pickup using Replaces.
required, the Supported header fi eld is used instead. See Table 6.10 for a list of feature tags.
An example is:
Require: rel100
6.2.28 Resource-Priority
The Resource-Priority header fi eld [30] is used to convey resource priority in a SIP request. It has been used to interwork with PSTN pre-emption and priority queuing protocols. The header fi eld contains namespace and a resource priority value, separated by a dot. Multiple values can be included separated by com-mas. Defi ned namespaces for Resource-Priority are included in Table 6.16.
Resource-Priority namespaces supported can be listed in an Accept-Resource-Priority header fi eld. The resource-priority option tag is used to indicate support for this mechanism.
An example is:
Resource-Priority: dsn.fl ash
6.2.29 Response-Key
The Response-Key header fi eld was defi ned in RFC 2543 but was deprecat-ed in RFC 3261 along with all PGP-basdeprecat-ed encryption in favor of S/MIME
The Response-Key header fi eld was defi ned in RFC 2543 but was deprecat-ed in RFC 3261 along with all PGP-basdeprecat-ed encryption in favor of S/MIME