reason, and retry-after. Values defined for the reason parameter include

deactivated, giveup, probation, noresource, rejected, and timeout.

An example is:

Subscription-State: terminated ;reason=rejected

6.2.37 Suppress-If-Match

The Suppress-If-Match header field [46] is an extension for conditional notification. Normally, a SUBSCRIBE sent to refresh a subscription will always generate a NOTIFY, even if no state information has changed since the last notification. If a SIP-ETag was included in a previous notification, the entity tag can be included in the Suppress-If-Match header field and included in a refresh SUBSCRIBE. If the state has not changed, a 204 No Notification response is sent and no NOTIFY will be sent. For example:

Suppress-If-Match: Lek31sd

6.2.38 Target-Dialog

The Target-Dialog header field [33] is used for authenticating out of dialog SIP requests. A common use case is for the authorization of out-of-dialog REFERs in call transfer scenarios. The header field contains the dialog identifier of the other dialog, which includes the Call-ID, local, and remote tags.

For example:

Target-Dialog: 3847349833;to-tag=434232;from-tag=33424212

6.2.39 Trigger-Consent

The Trigger-Consent header field provided [43] is used in resource lists requests to trigger consent lookups. For example:

Trigger-Consent: sip:alice@atlanta.example.com

6.3 Response Header Fields

These header fields are present only in responses.

6.3.1Accept-Resource-Priority

The Accept-Resource-Priority header field [30] is used to indicate which Resource-Priority namespaces are supported by the UA. It can be included in

a 200 OK to an OPTIONS or in a 417 Unknown Resource Priority response. An

example is:

Accept-Resource-Priority: ets

6.3.2Authentication-Info

The Authentication-Info header field can be inserted in responses when performing mutual authentication using HTTP Digest. In normal HTTP Digest as described in Section 14.4.1, the server challenges the client to provide a shared secret, which the client then provides in a repeat of the request containing an Authorization or WWW-Authenticate header field. For mutual authentication, the server would then provide an Authentication-Info header field containing either a next nonce or a response in an rspauth parameter. The response auth digest is calculated by the server from the SIP response using the same algorithm as the successful request authentication and same shared secret (client’s username and password). In this way, the server proves that it also knows the client’s secret, providing mutual authentication. The credentials are carried in the rspauth parameter in the header field. Few SIP implementations support this header field.

An example is:

Authentication-Info: rspauth=”9105jr98li459jgfp”

6.3.3Error-Info

The Error-Info header field is used in failure response to convey more information about an error. A UAC receiving the header field in a failure response may fetch and render the URI to the user. The header field can be used to give the client the choice of how the error can be presented to the user. For example, a client with a graphical interface will likely display the reason phrase on the response, which should provide very specific information about the failure. However, an audio-only UA does not have this capability (although a text-to-speech synthesizer could be used to provide this capability). Instead, an audio-only UA could fetch the URI and play the resulting audio stream to the user.

If the URI is a sip or sips URI, the UA may treat the Error-Info as a Contact in a redirection response, which would result in a SIP session established to play the recording.

An example is:

Error-Info: <sip:recording5@announcementsrus.com>

6.3.4Flow-Timer

The Flow-Timer header field [20] is part of the SIP outbound extension described in Section 10.11.3. The Flow-Timer header field is used by a registrar to tell a UA after how many seconds the server will consider the registration flow dead if no keep alive is sent by the UA. For example:

Flow-Timer: 120

6.3.5Min-Expires

The Min-Expires header field is used in a 423 Interval Too Brief response (Section 5.4.22) from a registrar rejecting a REGISTER request in which one or more Contacts have an expiration time that is too short. The header field contains an integer number of seconds that represents the minimum expiration interval that the registrar will accept. A client receiving this header field can update the expiration intervals of the registration request accordingly and resend the REGISTER request.

An example is:

Min-Expires: 1200

6.3.6Min-SE

The Min-SE header field [34] is a required header field in a 422 Session Timer Interval Too Small response (Section 5.4.21). The response may also be present in an INVITE or UPDATE containing a Session-Expires header field. It contains an integer number of seconds.

An example is:

Min-SE: 480

6.3.7Permission-Missing

The Permission-Missing header field [43] is part of the SIP consent framework. It is used in a 470 Consent Needed response to indicate the URIs to which the relay does not have permission to forward the request. An example of an instant message relay is given in Section 8.5.4. For example:

Permission-Missing: sip:voynitch@yale.edu

6.3.8Proxy-Authenticate

The Proxy-Authenticate header field is used in a 407 Proxy Authentication

Required authentication challenge by a proxy server to a UAC. It contains the nature of the challenge so that the UAC may formulate credentials in a ProxyAuthorization header field in a subsequent request. Examples are shown in Table 6.17.

6.3.9Security-Server

The Security-Server 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-Server header field is used by a server to declare the mechanisms it supports in a 494 Security Agreement Required header field. UAs and servers compare the security mechanisms in the Security-Client header field (see Section 6.2.32) with the mechanisms in the Security-Server header field and choose the common mechanism with the highest preference value. The

Security-Server header field may also be present in a 421 Extension Required

response if the server requires this mechanism. The SIP option tag sec-agree can be used in Supported, Require, and Proxy-Require header fields. Example:

Security-Server: tls;q=0.5, digest; q=0.4, ipsec-ike;q=0.1

6.3.10 Server

The Server header field is used to convey information about the UAS generating the response. The use and contents of the header field are similar to the UserAgent header field in Section 6.1.27. An example is:

Server: Dotcom/B3

6.3.11 Service-Route

The Service-Route header field [44] can be used in a 2xx response to a REGISTER request. It can be used by a registrar server to provide to the registering UA URIs to include in a preloaded Route header field in future requests. The Service-

Table 6.17

Example of Proxy-Authenticate Header Field

Proxy-Authenticate: Digest