Header Inspection

If a UAS does not understand a header field in a request (that is, the header field is not defined in this specification or in any supported extension), the server MUST ignore that header field and continue processing the message. A UAS SHOULD ignore any malformed header fields that are not necessary for processing requests.

8.2.2.1 To and Request-URI

The To header field identifies the original recipient of the request

designated by the user identified in the From field. The original recipient may or may not be the UAS processing the request, due to call forwarding or other proxy operations⁷¹. A UAS MAY apply any policy it wishes to determine whether to accept requests when the To header field is not the identity of the UAS.

However, it is RECOMMENDED that a UAS accept requests even if they do not

recognize the URI scheme (for example, a tel: URI) in the To header field, or if the To header field does not address a known or current user of this UAS.

If, on the other hand, the UAS decides to reject the request, it SHOULD generate a response with a 403 (Forbidden) status code and pass it to the server

transaction for transmission.

70 For instance, the UAS recognizes the method SUBSCRIBE, but does not support it.

71 For instance, Bob INVITEd Alice, but Alice was not there, and as a result the call got forwarded to Alice’s (SIP based) Voice mail application.

However, the Request-URI identifies the UAS that is to process the request. If the Request-URI uses a scheme not supported by the UAS, it SHOULD reject the request with a 416 (Unsupported URI Scheme)response. If the Request-URI does not identify an address that the UAS is willing to accept requests for, it

SHOULD reject the request with a 404 (Not Found) response. Typically, a UA that uses the REGISTER method to bind its address-of-record to a specific contact address will see requests whose Request-URI equals that contact address. Other potential sources of received Request-URIs include the Contact header fields of requests and responses sent by the UA⁷² that establish or refresh dialogs.

72 For example, Alice INVITEs Bob using the Request-URI “sip:[email protected]”. Bob responds with 200 OK, which includes the Contact header “sip:[email protected]”.

Next Alice uses the URI “sip:[email protected]” in the Request-URI field of the ACK rather than using the original Request-URI (i.e. the one she used in the INVITE).

8.2.2.2 Merged Requests

If the request has no tag in the To header field, the UAS core MUST check the request against ongoing transactions⁷³. If the From tag, Call-ID, and Cseq

exactly match those associated with an ongoing transaction, but the request does not match that transaction (based on the matching rules in Section 17.2.3), the UAS core SHOULD generate a 482 (Loop Detected) response and pass it to the server transaction.

The same request has arrived at the UAS more than once, following different paths, most likely due to forking. The UAS processes the first such request received and responds with a 482 (Loop Detected) to the rest of them.

8.2.2.3 Require

Assuming the UAS decides that it is the proper element to process the request, it examines the Require header field, if present.

The Require header field is used by a UAC to tell a UAS about SIP extensions that the UAC expects the UAS to support in order to process the request properly⁷⁴. Its format is described in Section 20.32. If a UAS does not understand an option-tag listed in a Require header field, it MUST respond by generating a response with status code 420 (Bad Extension). The UAS MUST add an Unsupported header field, and list in it those options it does not understand amongst those in the Require header field of the request.

Note that Require and Proxy-Require MUST NOT be used in a SIP CANCEL request, or in an ACK request sent for a non-2xx response⁷⁵. These header fields MUST be ignored if they are present in these requests.

73 If there is tag in the To header field then by definition the request does NOT belong to an ongoing transaction, but starts a new one, since the To tag was first learned by the UAC only when it received a response (e.g. 200) to the request of the previous transaction. According the rules in section 17.2.3 when a UAS core sends a 2xx response to INVITE, the server transaction is destroyed. (Think about it!)

74 For example: “Require: 100rel” indicates the client’s wish that the server would support the reliable mechanism of 1xx responses (PRACK, 200 Ok etc – RFC 3262).

75 As indicated by the spec about 10 lines below, Require and Proxy-Require are necessary for doing an appropriate preparation/synch-on-features-supported between the client and server for the sake of having smooth session. Doing this preparation in CANCEL or ACK to non-2xx response might just not be the right thing to do (A bit too late we can say…, as there is no session that will follow up, and this may only delay smooth closure of the current transaction).

An ACK request for a 2xx response MUST contain only those Require and Proxy-Require values that were present in the initial request.

Example:

UAC->UAS: INVITE sip:[email protected] SIP/2.0 Require: 100rel

UAS->UAC: SIP/2.0 420 Bad Extension Unsupported: 100rel

This behavior ensures that the client-server interaction will proceed without delay when all options are understood by both sides, and only slow down if options are not understood (as in the example above). For a well-matched

client-server pair, the interaction proceeds quickly, saving a round-trip often required by negotiation mechanisms. In addition, it also removes ambiguity when the client requires features that the server does not understand. Some features, such as call handling fields, are only of interest to end systems⁷⁶.