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: [email protected]
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9Hg4bKhjhs8ass877
Max-Forwards: 70
To: <sip:[email protected]>
From: Alice <sip:[email protected]>;tag=1928301774
Call-ID: a84b4c76e66710
Cseq : 63104 OPTIONS
Contact: <sip:[email protected]>
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:[email protected]>;tag=93810874
From: Alice <sip:[email protected]>;tag=1928301774
Call-ID: a84b4c76e66710
Cseq: 63104 OPTIONS
Contact: <sip:[email protected]>
Contact: mailto:[email protected]
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
