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

總結

以上是生活随笔為你收集整理的查询能力（SIP OPTIONS）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。