sip方法options允許乙個ua來查詢另外乙個ua或者proxy伺服器的能力。這個提供客戶端乙個手段來查詢服務端支援的方法，內容型別，擴充套件，codecs等等。比如，在客戶端試圖在invite請求頭中增加乙個請求字段選項的時候，它並不知道對方uas能否支援這個選項，它就可以用options來查詢一下uas，通過檢查options返回的supported頭域，就可以知道是否支援這個選項。所有的ua都必須支援options方法。
options請求的目標是用request-uri指明的，這個既可以是乙個ua也可以是乙個sip伺服器。如果options指向乙個proxy伺服器，request-uri設定成為乙個沒有使用者部分（userpart）的，類似register請求中的request-uri一樣。或者，一台伺服器收到乙個options請求並且max-forwards頭域值是0的時候，它就需要響應這個請求而不需要關心request-uri的內容。
options請求可以作為建立會話的一部分，用來查詢對方的能力使用，這樣在後續對話中可以使用雙方相容的方式。
1構造options請求
contact頭域在options請求中可以存在，也可以不存在。
對於乙個options請求的應答是假定是在原請求中的request-uri範圍內的。但是，僅當乙個options請求作為建立對話的一部分而傳送的時候，後續的請求應當由收到並且響應這個options請求的伺服器進行處理。（就是說如果在建立會話的時候使用options請求，那麼options之後的這些請求都應該由這個options查詢的伺服器處理，這樣才能保證使用的特性和options查詢出來的能力是一樣的）.
2處理options請求
在乙個對話中的options請求會產生乙個200(ok)的應答，這是和在對話外建立的並且對對話沒有任何影響的請求相同。
如果options請求的應答是由proxy伺服器給出的，proxy返回乙個200（ok）的應答，列出這個伺服器的各種選項和能力。應答沒有訊息體 。
allow，accept,accept-encoding,accept-language,和supported頭域應當在200（ok）應答中出現。如果這個是由proxy產生的應答，那麼allow頭域應當忽略，因為proxy是方法無關的（也就是說不知道該如何處理方法的）。
參考
rfc3261
如何提高查詢資料能力
我原先也不會查詢資料，自從2011年努力開始自學程式設計之後，終於入門了程式設計，也在不知不覺中提高了查詢資料的能力。幾乎可以說 只有你想不到，沒有你找不到 如果你找不到，那是你不夠好。因此查詢資料和鑑別好的資料的能力決定了自學的效率，為什麼有的人可以很快學會一樣技能，而有的人光是找資料就迷茫了？這...
SIP協議簡介（五）之能力查詢（OPTIONS）
sip方法options允許乙個ua來查詢另外乙個ua或者proxy伺服器的能力。這個提供個客戶端乙個手段來查詢服務端支援的方法，內容型別，擴充套件，codecs等等。這些都不用 ringing 對方。比如，在客戶端試圖在invite請求頭中增加乙個請求字段選項的時候，它並不知道對方uas能否支援這...
演算法能力和實現能力
起因是看東西累了就去zoj上挑些簡單題來娛樂下。結果驚奇的發現，到目前為止沒有幾道是一次過的，這些題真的看起來挺傻得結果還是老做不對。話說回來，回顧之前的專案，感覺是花了巨多的時間，很忙，但是說起來又沒什麼東西。涉及到演算法也基本是兩三句話搞定或者別人做過的。基本做的東西和演算法沒有太大關係，在de...