Querying for capabilities-capability query (Excerpted from RFC 3261)

Translator: 9 times on the Lushan Road

 

The SIP method options allows one UA to query the capabilities of another UA or proxy server. This provides a client to query methods supported by the server, such as content types, extensions, and codecs. None of these require the "Ringing" peer. For example, when the client tries to add a request field option to the invite request header, it does not know whether the UAS of the other party can support this option, so it can use options to query UAS, check the supported header field returned by options to check whether this option is supported. All UA must support the Options method.

The target of the options request is specified by request-Uri. This can be either an UA or a SIP server. If options points to a proxy server, request-Uri is set to a user-less part, similar to request-URI in a register request. Alternatively, when a server receives an options request and the value of the Max-forwards header is 0, it must respond to the request without worrying about the request-URI content.

This mechanism is like HTTP/1.1. This mechanism can be used to implement the "traceroute" function to check the capabilities of each route node by sending a series of options requests with an incremental max-forwards header domain.

For the general UA mechanism, if options does not respond, the transaction layer can return a timeout error. This may indicate that the other party cannot arrive and thus there is no response. The options request can be used as part of the session establishment to query the capabilities of the other party, so that the two sides can be compatible in subsequent conversations.

 

 

An options request can be constructed according to the standard constructor in section 8.1.1.

The contact header field may or may not exist in the options request.

The accept header field should be included in the request to indicate the type of the message body that the UAC wants to receive in the response. Generally, this setting becomes the multimedia compatibility of UA, such as the SDP format.

The response to an options request is assumed to be within the original request-Uri range. However, when an options request is sent as part of a conversation, subsequent requests should be processed by the server that receives and responds to this options request. (That is to say, if the options request is used when the session is established, all the requests after options should be processed by the options query server, in this way, the features used are the same as those queried by options)

 

Example of an options request:

Options SIP: carol@chicago.com

Via: SIP/2.0/udp pc33.atlanta ta.com; branch = z9hg4bkhjhs8ass877

Max-forwards: 70

To: <SIP: carol@chicago.com>

From: Alice <SIP: alice@atlanta.com>; tag = 1928301774

Call-ID: a84b4c76e66710

CSeq: 63104 options

Contact: <SIP: alice@pc33.atlanta.com>

Accept: Application/SDP

Content-Length: 0

 

The construction of the response to options follows the standard construction rules (described in section 8.2.6 ). The answer code must be the same as the response code used to process the invite request (just like the response code used to process the invite request ). This means that 200 (OK) should be returned when the UAS can receive the request, and 486 (busy) should be returned when the UAs is busy. In this way, options can be used to check the basic status of UAS. That is to say, we can use options to determine whether UAS can receive INVITE requests.

The options request in a dialog produces a 200 (OK) response, which is the same as the request created outside the dialog and has no impact on the dialog.

The use of this options has certain restrictions, because the proxy processes the options and invite requests differently. Invite of a branch can have multiple 200 (OK) responses, but the options of a branch can only have a single 200 (OK) response. This is because the proxy processes the options request as a non-invite. See section 16.7 for details.

 

If the answer to the options request is provided by the proxy server, the proxy returns a 200 (OK) response, listing the various options and capabilities of the server.

No message body for the response

The allow, Accept, accept-encoding, accept-language, and supported header fields should appear in the 200 (OK) response. If the response is generated by the proxy, the allow header field should be ignored because the proxy is method-independent (that is, it does not know how to handle the method ). The contact header field can appear in the 200 (OK) response and has the same semantics as the 3xx response. That is to say, they can list a set of names and Methods pointing to the customer (used to forward requests ). A warning header can exist. The message body can also exist. The type of the message body is specified by the options request's accept header field (Application/SDP is the default, if the accpet header field does not exist ). If the accept header contains a type that can describe the media receiving capability, UAS should include a message body in the response for this purpose. The detailed description of application/SDP package is described in [13.

The options response example generated by UAS. (Corresponding to the request example in section 11.1)

Sip/2.0 200 OK

Via: SIP/2.0/udp pc33.atlanta ta.com; branch = z9hg4bkhjhs8ass877

; Received = 192.0.2.4

To: <SIP: carol@chicago.com>; tag = 93810874

From: Alice <SIP: alice@atlanta.com>; tag = 1928301774

Call-ID: a84b4c76e66710

CSeq: 63104 options

Contact: <SIP: carol@chicago.com>

Contact: mailto: carol@chicago.com

Allow: Invite, ack, cancel, options, bye

Accept: Application/SDP

Accept-encoding: Gzip

Accept-language: En

Supported: foo

Content-Type: Application/SDP

Content-Length: 274

(SDP not shown)