port for routing the response. This indicates that a NAT or firewall proxy is in the message path. If present, the received and or rport tags are used in response routing. (The hidden parameter, deprecated in RFC 3261, was used to indicate that the Via header field has been encrypted.) A branch parameter is added to Via header fields by UAs and proxies, which is computed as a hash function of the Request-URI, and the To, From, Call-ID, and CSeq number. A second part is added to the branch parameter if the request is being forked as shown in Figure 3.4. The maddr and ttl parameters are used for multicast transport and have a similar meaning as the equivalent SIP URI parameters. The compact form of the header field is v. Examples are given in Table 6.13.

6.2 Request Header Fields

This set of header fields can only be present in a request.

6.2.1Accept-Contact

The Accept-Contact [23] header field specifies to which URIs the request may be proxied. Some additional parameters are also defined for Contact header fields such as media, duplex, and language. This header field is part of the caller preferences extensions to SIP, which have been defined to give some control to the caller in the way a proxy server processes a call. The compact form is a.

Some examples follow:

Table 6.13

Examples of a Via Header Field

Accept-Contact: *;language=en

a:*;media=video

6.2.2Authorization

The Authorization header field 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 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 HTTP digest is described in Section 14.4.1. Examples are shown in Table 6.14.

6.2.3Call-Info

The Call-Info header field is included in a request by a UAC or proxy to provide a URI with information relating to the session setup. It may be present in an INVITE, OPTIONS, or REGISTER request. The header field 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://www.code.com/my_picture.jpg>;purpose=icon

6.2.4Event

The Event header field 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 notification contains state information about. Currently defined event packages are listed in Table 4.8. The compact form is o.

Table 6.14

Example of an Authorization Header Field

An example follows:

Event: dialog

o:refer

6.2.5Hide

The Hide header field was defined in RFC 2543 but has been deprecated (removed) from RFC 3261. It was intended to be used by UAs or proxies to request that the next hop proxy encrypts the Via header fields to hide message routing path information. Encrypted Via headers were identified with the hidden Via parameter. However, the security provided and the mechanism requiring next hop trust made the value of this header field minimal.

6.2.6Identity

The Identity header field [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 forwarded request after the request has been authenticated. The header field contains a digital signature over certain parts of the SIP message and the entire message body. The header field is used to certify the identity in the From header field by a proxy in the domain.

6.2.7Identity-Info

The Identity-Info header field [35] is part of the enhanced SIP identity extension, and is used to convey a URI for the certificates containing the public key of the signing proxy. The alg parameter indicates the algorithm used to generate the signature in the Identity header field. In this example, the certificate is available 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.8In-Reply-To

The In-Reply-To header field 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 field. This allows the UAS to determine that this is not an unsolicited