which is then forwarded. In loose routing, a proxy does not rewrite the RequestURI, but either forwards the request to the first URI in the Route header field or to another loose routing element. In loose routing, the request must route through every server in the Route list (but may also route through other servers) before it may be routed based on the Request-URI. In strict routing, the request must only route through the set of servers in the Route header field with the Request-URI being rewritten at each hop. A proxy or UAC can tell if the next element in the route set supports loose routing by the presence of an lr parameter. An example is:

Route: <sip:proxy@example.com;lr>

Chapter 16 contains an example of the use of the Record-Route and Route header fields. Examples of Route header fields constructed from the example Record-Route header fields in Section 6.1.19 are:

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

Route: <sip:139.23.1.44;lr>

6.2.31 RAck

The RAck header field [10] is used within a response to a PRACK request to reliably acknowledge a provisional response that contained an RSeq header field. The RAck header field echoes the CSeq and the RSeq from the provisional response. The reliable sequence number is incremented for each response sent reliably. A call flow is shown in Figure 4.11. An example is:

RAck: 8342523 13 INVITE

6.2.32 Security-Client

The Security-Client header field [32] is part of the SIP security agreement extension used to negotiate security settings between a UA and a proxy server. The Security-Client header field is used by a UA to declare the mechanisms it supports in a SIP request. UAs and servers compare the security mechanisms in the Security-Client header field with the mechanisms in the Security-Server header field (see Section 6.3.9) and choose the common mechanism with the highest preference value. The SIP option tag sec-agree can be used in Supported, Require, and Proxy-Require header fields. For example:

Security-Client: digest

6.2.33 Security-Verify

The Security-Verify header field [32] is part of the SIP security agreement extension, used to negotiate security settings between a UA and a proxy server. The Security-Verify header field is used by a UA to echo the mechanisms received in a Security-Server header (see Section 6.3.9) field from a server. If the request is sent with integrity protection, a proxy and user can detect a bid-down attack in the security agreement negotiation. For example:

Security-Client: digest

6.2.34 Session-Expires

The Session-Expires header field [21] is used to specify the expiration time of the session. To extend the session, either UA can send a re-INVITE or UPDATE with a new Session-Expires header field. At the expiration of the interval in the Session-Expires, either UA may send a BYE and call-stateful proxies may destroy any state information. A proxy may shorten the expiration time by reducing the interval in the header field as it proxies the request. A UAS confirms the session timer by including the Session-Expires header field in the response to the request. A UAS may also shorten the interval by reducing the interval. An example is:

Session-Expires: 3600

6.2.35 SIP-If-Match

The SIP-If-Match header field [45] is part of the SIP publication mechanism. It is included in a PUBLISH request meant to refresh, modify, or remove previously published state. The header field contains the entity tag of the state information that was returned in a SIP-ETag (Section 6.3.12) header field in a 2xx response to an earlier PUBLISH. If the entity-tag is no longer valid (i.e. the state information has expired, been deleted, replaced, or lost), the server will return a 412 Conditional Request Failed response (Section 5.4.13). See Figure 8.5 for a call flow. Example:

SIP-If-Match: 73ikd0Kw3e1D0ds

6.2.36 Subscription-State

The Subscription-State header field [3] is a required header field in a NOTIFY request. It indicates the current state of the subscription. Values defined include active, pending, or terminated. Additional parameters include expires,