SIP protocol parsing and implementation (C and C ++ use Osip) 11

Chapter 8 query capability

The SIP Options method allows one UA to query the capabilities of another UA or proxy server. This allows the client to detect information about the methods, content types, extensions, and encoding they support, rather than the other end of "calling. For example, before the client inserts a require header field into invite and lists the capabilities that are not supported by the target UAS, it can first use the Options method to query whether the target UAS option to be queried is returned by the target uas in the supported header field of the response. All UA must support the Options method.

The target of the options method is identified by request-Uri, because it can represent different UA or sip servers. If options is located on a proxy server, request-Uri is not set by the client. This is similar to the method used to set request-URI for register requests.

If the server receives an options request with a value of 0 in the max-forwards header field, it must respond to the request without worrying about request-Uri.
This behavior is consistent with HTTP/1.1. This behavior can be used for the "trace route (traceroute)" function to check the capabilities of individual servers in the message routing process by sending a series of ascending max-forwards value options requests.

As a general UA behavior, if options does not respond for a long time, the transaction layer can return a timeout error. This indicates that the target is inaccessible and the query capability is unavailable.

The options request may be sent by one end of the created dialog to query the capabilities that the Peer may use in subsequent dialogs.

Section 1 constructing an options request

The options request is constructed using a standard constructed SIP request rule as discussed in rfc3261 8.1.1.

Options may have a contact header field.

It should contain an accept header field to indicate the type of the message body in the response that the UAC wants to receive. Typically, this may be set to the type used to describe UA's media capabilities, such as SDP (Application/ADP ).

The answer to the options request is considered to be within a limited range and is limited to the request-Uri of the original request. Only when options is sent as part of the conversation, it ensures that the subsequent requests in the session are also received by the server responding to options, the response to the options request is available.

Example of an options request:
Options SIP: carol@chicago.com Sip/2.0
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

Section 2 process options requests

The response to the options request uses the response rule for the standard SIP request described in section 8.2.6 of rfc3261. The response status code must be the same as the status code for the invite response. For example, a 200 (OK) will be returned when the UAs is preparing to accept a call, and a 486 (BUSY HERE) will be returned when the UAs is busy. This allows supply and demand within options days to test the basic status of UAs, which indicates whether the UAS can accept an invite request.

The 200 (OK) response constructed by the options request in the received dialog is the same as the response of the options request outside the constructed dialog, and there is no conflict with the dialog.

Because the proxy server processes different options and invite requests, the use of options is limited. A branch invite can cause multiple 200 (OK) responses. The options request of a branch will only cause one 200 (OK) response, because the options request is processed by the proxy server as a non-invite request. For details, see section 16.7 of rfc3261.

If the proxy server responds 200 (OK) to options, the server's capabilities should be listed in the response. The response cannot contain a message body.

The responses to the allow, Accept, accept-encoding, accept-language, and supported header fields appear in the 200 (OK) response to the options request. If the response is constructed by the proxy server, the allow header domain should be ignored. This is because the proxy server does not process the method. The contact header field may appear in the 200 (OK) response and contains the same semantics as the 3xx response. That is to say, they may list a series of names or methods of users that can be accessed (this can redirect requests ). The warning header field may appear in the response.

A message body may be sent. The type of the message body is determined by the options request's accept header domain (if there is no accept header domain, the default value is application/SDP ). If the type includes a type that can describe media capabilities, UAS should include a message body in the response. Constructing such a message body for application/SDP is described in [13.

Example of the options response constructed by UAS (requests conforming to rfc3261 section 11.1 ):
Options SIP: carol@chicago.com Sip/2.0
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