RFC3261: SIP:11.2 OPTIONS请求的处理
11.2 Processing of OPTIONS Request 11.2 OPTIONS请求的处理 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. 对OPTIONS的响应是使用第8.2.6节中讨论的SIP响应的标准规则构建的。所选择的响应代码必须与请求为INVITE时所选择的代码相同。也就是说，如果UAS准备好接受呼叫，则返回200（OK），如果UAS正忙，则返回486（Busy Here），等等。这允许OPTIONS请求用于确定UAS的基本状态，其可以是UAS是否将接受INVITE请求的指示。 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. 在对话内接收到的OPTIONS请求会生成200（OK）响应，该响应与在对话外构建的响应相同，不会对对话产生任何影响。 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. 由于OPTIONS和INVITE请求的代理处理方式不同，OPTIONS的使用受到限制。虽然分叉的INVITE可能会导致返回多个200（OK）响应，但分叉的OPTIONS只会导致一个200（正常）响应，因为它是由使用非INVITE处理的代理处理的。有关规范性详细信息，请参见第16.7节。 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. 如果对OPTIONS的响应是由代理服务器生成的，则代理会返回一个200（OK），列出服务器的功能。响应不包含消息体。 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. 对OPTIONS请求的200（OK）响应中应存在Allow、Accept、Accept Encoding、Accept Language和Supported报头字段。如果响应是由代理生成的，则应省略Allow标头字段，因为它不明确，因为代理与方法无关。Contact报头字段可以存在于200（OK）响应中，并且具有与3xx响应中相同的语义。也就是说，他们可以列出一组替代名称和联系用户的方法。可能存在警告报头字段。 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].
可以发送消息体，其类型由OPTIONS请求中的Accept报头字段确定（如果Accept报头字段不存在，则application/sdp为默认值）。如果类型包括一个可以描述媒体能力的类型，UAS应该为此目的在响应中包括一个消息体。[13]中描述了在application/sdp的情况下这种消息体的构造细节。
Example OPTIONS response generated by a UAS (corresponding to the request in Section 11.1): UAS生成的OPTIONS响应示例（对应于第11.1节中的请求）： SIP/2.0 200 OK Via: SIP/2.0/UDP pc33.atlanta.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)
（SDP未显示）