Replaces: sdjfdjfskdf@there.com;to-tag=5f35a3;from-tag=8675309

header field. Note that the characters “;” and “=” are replaced by their hex equivalents %3B and %3D. In the next example, the header field containing a method

Refer-To: <sip:UserC@client.anywhere.com?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 field in compact form with an HTTP URL is:

r:<http://www.artech-house.com>

6.2.22Referred-By

The Referred-By header field [42] is an optional header field 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 field could be modified 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 field. 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 fields from the REFER request. An unsigned Referred-By header field 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:user@host.com>

b:<sips:friend@neighbor.org>

6.2.23Reply-To

The Reply-To header field 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 field (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 information, so the URI in this header field should be used instead of the From URI.

An example is:

Figure 6.3 Call flow showing call pickup using Replaces.

Accept-Contact and Request-Disposition are part of the SIP caller preferences extensions. The compact form is j. Examples include:

Reject-Contact: sip:admin@boss.com

j:*;media=video

6.2.26Request-Disposition

The Request-Disposition [23] header field 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 field is used to list features and extensions that a UAC requires 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 field. If support or use of a feature is desirable but not

required, the Supported header field 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 field [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 field contains namespace and a resource priority value, separated by a dot. Multiple values can be included separated by commas. Defined namespaces for Resource-Priority are included in Table 6.16. Resource-Priority namespaces supported can be listed in an Accept-Resource- Priority header field. The resource-priority option tag is used to indicate support for this mechanism.

An example is:

Resource-Priority: dsn.flash

6.2.29 Response-Key

The Response-Key header field was defined in RFC 2543 but was deprecated in RFC 3261 along with all PGP-based encryption in favor of S/MIME encryption.

6.2.30 Route

The Route header field is used to provide routing information for requests. RFC 3261 introduces two types of routing: strict and loose routing, which have similar meaning as the IP routing modes of the same name. In strict routing, a proxy must use the first URI in the Route header field to rewrite the Request-URI,