e 4.7 shows the use of Replaces in an "attended transfer example." This example Replaces header field: Replaces: 3232904875945@server.org;to-tag=34314;1 from-tag=2343 would match the dialog identified by: To: k<sip:moe@example.org>;tag=34314 From: <sip: larry@server.org>;tag=23 Call-ID: 3232904875945@server.org 6.2.24 Reject-Contact The Reject-Contact [4] header field specifies the URIs to which the request may not be proxied. Some additional parameters are also defined for SIP Header Fields Called Caller Pickup party INVITE 180 Ringing INVITE (Replaces) 200 OK CANCEL 200 OK Media session Figure 6.4 Call pickup call flow using Replaces. Contact header fields such as media, duplex, and language when used in this header field. This header field, along with Accept-Contact and Request-Disposition are part of the SIP caller preferences exten- sions. The compact form is j. Examples include: Reject-Contact: sip:admin@boss.com j: ;media=video 6.2.25 Request-Disposition The Request-Disposition [4] header field can be used to request servers to either proxy or redirect, or initiate serial or parallel (forking) searches. An example is: Request-Disposition: redirect 6.2.26 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 SIP: Understanding the Session Initiation Protocol 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.8 for a list of feature tags. An example is: Require: rel100 6.2.27 Response-Key The Response-Key header field was defined in RFC 2543 but was depre- cated in RFC 3261 along with all PGP-based encryption in favor of S/MIME encryption. 6.2.28 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 mo