SIP方法OPTIONS允许一个UA来查询另外一个UA或者proxy服务器的能力。这个提供个客户端一个手段来查询服务端支持的方法，内容类型，扩展，codecs等等。这些都不用”ringing”对方。比如，在客户端试图在INVITE请求头中增加一个请求字段选项的时候，它并不知道对方UAS能否支持这个选项，它就可以用OPTIONS来查询一下UAS，通过检查OPTIONS返回的Supported头域，就可以知道是否支持这个选项。所有的UA都必须支持OPTIONS方法。
OPTIONS请求的目标是用Request-URI指明的，这个既可以是一个UA也可以是一个SIP服务器。如果OPTIONS指向一个proxy服务器，Request-URI设置成为一个没有用户部分（user part）的，类似REGISTER请求中的Request-URI一样。或者，一台服务器收到一个OPTIONS请求并且Max-Forwards头域值是0的时候，它就需要响应这个请求而不需要关心Request-URI的内容。
这个机制就像HTTP/1.1一样。这个机制可以用来实现类似”traceroute”功能来通过发出一系列的有着增量Max-Forwards头域的OPTIONS请求来检查每一个途径节点的能力。
就像对一般UA机制来说，如果OPTIONS没有应答，transaction层能够返回一个超时错误。这个可能标志着对方无法到达因此无响应。OPTIONS请求可以作为建立会话的一部分，用来查询对方的能力使用，这样在后续对话中可以使用双方兼容的方式。
构造OPTIONS请求
一个OPTIONS请求可以根据RFC3261-8.1.1节中的标准构造方法来进行构造。
Contact头域在OPTIONS请求中可以存在，也可以不存在。
Accept头域应当包含在请求中，用来标志UAC希望接收应答中的消息体的类型。通常情况下，这个设置成为UA的多媒体兼容能力，比如SDP(应用/SDP)格式。
对于一个OPTIONS请求的应答是假定是在原请求中的Request-URI范围内的。但是，仅当一个OPTIONS请求作为建立对话的一部分而发送的时候，后续的请求应当由收到并且响应这个OPTIONS请求的服务器进行处理。（就是说如果在建立会话的时候使用OPTIONS请求，那么OPTIONS之后的这些请求都应该由这个OPTIONS查询的服务器处理，这样才能保证使用的特性和OPTIONS查询出来的能力是一样的）
OPTIONS请求的例子：
OPTIONS sip: carol@chicago.com
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节描述）。应答码的选择必须和处理INVITE请求一样的应答码（就像处理INVITE请求一样的返回）。这就是说，200（OK）应当在UAS能够接收请求的时候返回，486（忙）应当在UAS如果忙的时候返回。这样OPTIONS可以用来检测UAS的基本状态，这就是说，我们可以用OPTIONS来知道UAS能否接收INVITE请求。
在一个对话中的OPTIONS请求会产生一个200(OK)的应答，这是和在对话外创建的并且对对话没有任何影响的请求相同。
这个OPTIONS的使用有一定的限制，因为对于proxy处理OPTIONS和INVITE请求的不同。一个分支的INVITE可以有多个200（OK）的应答返回，但是一个分支的OPTIONS只能有单个200（OK）应答返回。因为这是由于proxy处理OPTIONS请求是当作非INVITE的处理。参见16.7节有详细的说明。
如果OPTIONS请求的应答是由proxy服务器给出的，proxy返回一个200（OK）的应答，列出这个服务器的各种选项和能力。
应答没有消息体
Allow，Accept,Accept-Encoding,Accept-Language,和Supported头域应当在200（OK）应答中出现。如果这个是由proxy产生的应答，那么Allow头域应当忽略，因为proxy是方法无关的（也就是说不知道该如何处理方法的）。Contact头域可以在200（OK）的应答中出现，并且与3xx应答有相同的语义。这就是说，他们可以列出指向客户的一串名字和方法的集合（用以转发请求）。一个Warning头域是可以存在的。消息体也可以存在，消息体的类型是由OPTIONS请求的Accept头域指明的(application/sdp是缺省的，如果Accpet头域不存在的话)。如果Accept头域中包含了一个类型能描述媒体接收能力，UAS应当在应答中包含一个消息体用于这个用途。详细的application/sdp包体说明在[13]中描述。
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)
本文转自[水平网]：http://www.goalercn.com/article.php?id=368