The SIP method OPTIONS allows a UA to query another UA or a proxy server as to its capabilities113. This allows a client to discover information about the
113 Practically OPTIONS is also often used as an out-of-dialog keep-alive mechanism.
supported methods, content types, extensions, codecs, etc. without "ringing" the other party. For example, before a client inserts a Require header field into an INVITE listing an option that it is not certain the destination UAS supports, the client can query the destination UAS with an OPTIONS to see if this option is returned in a Supported header field. All UAs MUST support the OPTIONS method.
The target of the OPTIONS request is identified by the Request-URI, which could identify another UA or a SIP server. If the OPTIONS is addressed to a proxy server, the Request-URI is set without a user part, similar to the way a Request-URI is set for a REGISTER request.
Alternatively, a server receiving an OPTIONS request with a Max-Forwards header field value of 0 MAY respond to the request regardless of the Request-URI.
This behavior is common with HTTP/1.1. This behavior can be used as a
"traceroute" functionality to check the capabilities of individual hop servers by sending a series of OPTIONS requests with incremented Max-Forwards values.
As is the case for general UA behavior, the transaction layer can return a timeout error if the OPTIONS yields no response. This may indicate that the target is unreachable and hence unavailable.
An OPTIONS request MAY be sent as part of an established dialog to query the peer on capabilities that may be utilized later in the dialog.
11.1 Construction of OPTIONS Request
An OPTIONS request is constructed using the standard rules for a SIP request as discussed in Section 8.1.1.
A Contact header field MAY be present in an OPTIONS.
An Accept header field SHOULD be included to indicate the type of message body the UAC wishes to receive in the response. Typically, this is set to a format that is used to describe the media capabilities of a UA, such as SDP
(application/sdp).
The response to an OPTIONS request is assumed to be scoped to the Request-URI in the original request. However, only when an OPTIONS is sent as part of an
established dialog is it guaranteed that future requests will be received by the server that generated the OPTIONS response.
Example OPTIONS request:
OPTIONS sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877 Max-Forwards: 70
To: <sip:[email protected]>
From: Alice <sip:[email protected]>;tag=1928301774 Call-ID: a84b4c76e66710
CSeq: 63104 OPTIONS
Contact: <sip:[email protected]>
Accept: application/sdp
Content-Length: 0
11.2 Processing of OPTIONS Request
The response to an OPTIONS is constructed using the standard rules for a SIP response as discussed in Section 8.2.6. The response code chosen MUST be the same that would have been chosen had the request been an INVITE. That is, a 200 (OK) would be returned if the UAS is ready to accept a call, a 486 (Busy Here) would be returned if the UAS is busy, etc. This allows an OPTIONS request to be used to determine the basic state of a UAS, which can be an indication of whether the UAS will accept an INVITE request.
An OPTIONS request received within a dialog generates a 200 (OK) response that is identical to one constructed outside a dialog and does not have any impact on the dialog.
This use of OPTIONS has limitations due to the differences in proxy handling of OPTIONS and INVITE requests. While a forked INVITE can result in multiple 200 (OK) responses being returned, a forked OPTIONS will only result in a single 200 (OK) response, since it is treated by proxies using the non-INVITE handling.
See Section 16.7 for the normative details.
If the response to an OPTIONS is generated by a proxy server, the proxy returns a 200 (OK), listing the capabilities of the server.
The response does not contain a message body.
Allow, Accept, Accept-Encoding, Accept-Language, and Supported header fields SHOULD be present in a 200 (OK) response to an OPTIONS request. If the response is generated by a proxy, the Allow header field SHOULD be omitted as it is
ambiguous since a proxy is method agnostic. Contact header fields MAY be
present in a 200 (OK) response and have the same semantics as in a 3xx response.
That is, they may list a set of alternative names and methods of reaching the user. A Warning header field MAY be present.
A message body MAY be sent, the type of which is determined by the Accept header field in the OPTIONS request (application/sdp is the default if the Accept
header field is not present). If the types include one that can describe media capabilities, the UAS SHOULD include a body in the response for that purpose.
Details on the construction of such a body in the case of application/sdp are described in [13].
Example OPTIONS response generated by a UAS (corresponding to the request in Section 11.1):
SIP/2.0 200 OK
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877 ;received=192.0.2.4
To: <sip:[email protected]>;tag=93810874
From: Alice <sip:[email protected]>;tag=1928301774 Call-ID: a84b4c76e66710
CSeq: 63104 OPTIONS
Contact: <sip:[email protected]>
Contact: <mailto:[email protected]>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE Accept: application/sdp
Accept-Encoding: gzip
A key concept for a user agent is that of a dialog. A dialog represents a peer-to-peer SIP relationship between two user agents that persists for some time.
The dialog facilitates sequencing of messages between the user agents and proper routing of requests between both of them. The dialog represents a context in which to interpret SIP messages. Section 8 discussed method independent UA processing for requests and responses outside of a dialog. This section
discusses how those requests and responses are used to construct a dialog, and then how subsequent requests and responses are sent within a dialog.
A dialog is identified at each UA with a dialog ID, which consists of a Call-ID value, a local tag and a remote tag. The dialog ID at each UA involved in the dialog is not the same. Specifically, the local tag at one UA is identical to the remote tag at the peer UA. The tags are opaque tokens that facilitate the generation of unique dialog IDs.
A dialog ID is also associated with all responses and with any request that contains a tag in the To field. The rules for computing the dialog ID of a message depend on whether the SIP element is a UAC or UAS. For a UAC, the Call-ID value of the dialog Call-ID is set to the Call-Call-ID of the message, the remote tag is set to the tag in the To field of the message, and the local tag is set to the tag in the From field of the message (these rules apply to both requests and responses). As one would expect for a UAS, the Call-ID value of the dialog ID is set to the Call-ID of the message, the remote tag is set to the tag in the From field of the message, and the local tag is set to the tag in the To field of the message.
A dialog contains certain pieces of state needed for further message
transmissions within the dialog. This state consists of the dialog ID, a local sequence number (used to order requests from the UA to its peer), a remote
sequence number (used to order requests from its peer to the UA), a local URI, a remote URI, remote target, a Boolean flag called "secure", and a route set, which is an ordered list of URIs. The route set is the list of servers that need to be traversed to send a request to the peer. A dialog can also be in the
"early" state, which occurs when it is created with a provisional response, and then transition to the "confirmed" state when a 2xx final response arrives. For other responses, or if no response arrives at all on that dialog, the early dialog terminates.
12.1 Creation of a Dialog
Dialogs are created through the generation of non-failure responses to requests with specific methods. Within this specification, only 2xx and 101-199
responses with a To tag, where the request was INVITE, will establish a dialog.
A dialog established by a non-final response to a request is in the "early"