sip协议解析与实现(c和c++使用osip)11
第八章 查询能力
SIP的OPTIONS方法允许一个UA查询另外一个UA或者一个代理服务器的能力。这能让客户端探测关于它们所支持的方法、内容类型、扩展和编码等信息，而不用\呼叫(ringing)\另外一端。例如，在客户端插入了一个Require头域到INVITE中，并列出了不确定目标UAS是否支持的能力之前，它可以先使用OPTIONS方法查询目标UAS是否要查询的选项被目标UAS在应答的Supported头域中返回。所有UA必须支持OPTIONS方法。
OPTIONS方法的目标使用Request-URI来标识，因为它可以表示不同的UA或者SIP服务器。如果OPTIONS被定位到一个代理服务器，Request-URI不由客户端设置，这类似于REGISTER请求设置Request-URI的方法。
如果服务器接收到一个Max-Forwards头域的值为0的的OPTIONS请求，它要对这个请求进行应答而不用管Request-URI.
这个行为与HTTP/1.1一致。这个行为可以被用于\追踪路由线路(traceroute)\功能，从而使用发送一系列递增的Max-Forwards值的OPTIONS请求的方法检查消息路由过程中个别服务器的能力。
作为一般UA的行为，如果OPTIONS长时间没有应答，事务层能够返回一个超时错误。这将指出，目标是不可到达的并且查询的能力是不可以使用的。
OPTIONS请求可能由建立一个对话的一端发送，用于查询对端在后面的对话中可能会被使用到的能力。 第一节 构造OPTIONS请求
OPTIONS请求使用像RFC3261第8.1.1讨论的标准的构造SIP请求的规则来构造。
OPTIONS可能会有一个Contact头域。
应该包含一个Accept头域用来指出UAC希望接收到的应答中的消息体类型。典型的，这可能被设置成用来描述UA的媒体能力的类型，比如，SDP(application/adp)。
OPTIONS请求的应答被认为是有限定范围的，它被限定在原始请求的Request-URI内。只有当OPTIONS被作为建立对话的一部分发送，它保证会话中后继的请求也由应答OPTIONS的服务器所接收时，对OPTIONS请求的应答才是可用的。
OPTIONS请求的例子：
OPTIONS sip:carol@chicago.com SIP/2.0 Via: SIP/2.0/UDP
pc33.atlanta.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 第二节 处理OPTIONS请求
对OPTIONS请求的应答使用RFC3261第8.2.6节描述的对标准SIP请求的应答规则。应答状态码必须与对INVITE应答的状态码采用相同的选择。例如，一个200（OK）将会在UAS准备接受一个呼叫时候被返回，一个486（Busy Here）将会在UAS繁忙的时候被返回。这允许OPTIONS日内供求用来探测UAS的基础状态，基础状态是指它可以指出这个UAS是否能够接受一个INVITE请求。
对接收到的对话内OPTIONS请求构造的200（OK）应答与构造对话外的OPTIONS请求的应答一样，并且与对话没有任何冲突。
由于代理服务器处理OPTIONS和INVITE请求不同，所以对OPTIONS的使用方法是有一定限制的。一个有分支的