header field contains a URI, but it may not contain the transport, maddr, or ttl URI parameters. A From header field may contain a tag used to identify a particular call. A From header field may contain a display name, in which case the URI is enclosed in < >. If there is both a URI parameter and a tag, then the URI including any parameters must be enclosed in < >. Examples are shown in Table 6.8. A From tag was optional in RFC 2543 but is mandatory to include in RFC 3261.

6.1.15 History Info

The History-Info header field [10] is an extension header field used to capture and convey routing history associated with a SIP request. Information about a request routing can be added whenever a request is retargeted, the Request-URI is rewritten, and so fourth. A Reason header field (Section 6.2.20) is included as a parameter in this header field. Since a request can be forwarded and retargeted multiple times, multiple History-Info header fields can be present (or multiple comma separated History-Info entries). An index parameter is used to keep track of the order of the actions. A common application for History-Info is for voicemail, described in Section 9.4. Below is an example showing three historyinfo entries, and the escaping of the semicolon (%3B) and equals (%3D) in the Reason header field:

History-Info: <sip:UserA@example.com?Reason=SIP%3Bcause%3D302> ;index=1.1,

<sip:UserB@example.com?Privacy=history&Reason=SIP%3Bcause%3D486> ;index=1.2, <sip:45432@vm.example.com>;index=1.3

Table 6.8

Examples of From Header Field

6.1.19 Record-Route

The Record-Route header field is used to force routing through a proxy for all subsequent requests in a session (dialog) between two UAs. Normally, the presence of a Contact header field allows UAs to send messages directly bypassing the proxy chain used in the initial request (which probably involved database lookups to locate the called party). A proxy inserting its address into a Record-Route header field overrides this and forces future requests to include a Route header field containing the address of the proxy that forces this proxy to be included.

A proxy wishing to implement this inserts the header field containing its own URI, or adds its URI to an already present Record-Route header field. The URI is constructed so that the URI resolves back to the proxy server. The UAS copies the Record-Route header field into the 200 OK response to the request. The header field is forwarded unchanged by proxies back to the UAC. The UAC then stores the Record-Route proxy list plus a Contact header field if present in the 200 OK for use in a Route header field in all subsequent requests. Because RecordRoute is bidirectional, messages in the reverse direction will also traverse the same set of proxies. Chapter 16 contains an example of the use of the Record-Route and Route header fields. The lr parameter is new to RFC 3261 and indicates that the proxy server supports “loose routing.” Older RFC 2543 compliant proxy servers create Record-Route URIs that instead of the lr parameter often contain the maddr parameter with an address or host that resolves to that proxy server.

Examples are:

Record-Route: <sip:proxy1.carrier.com;lr>, <sip:firewall33.corporation.com;lr>

Record-Route:<sip:139.23.1.44;lr>

6.1.20 Recv-Info

The Recv-Info header field [12] is used to indicate which INFO packages a UA is willing to receive. Defined INFO event packages allow negotiation between UAs of supported applications using INFO. For example:

Recv-Info: foo

6.1.21 Refer-Sub

The Refer-Sub header field [13] is used to request a particular state for an implicit REFER subscription, or to indicate the state of an existing implicit REFER subscription. When a Refer-Sub: false header field is included in a REFER, the recipient of the REFER is requested not to create an implicit subscription and not