OPTIONS——SIP学习笔记（七）

SIP方法OPTIONS允许UA查询其它UA和代理服务器的能力。这就允许客户端不必“Ringing”对方，即可发现关于支持的方法、内容类型、扩展和编码等信息。

Request-URI确定OPTIONS请求的目标，它可以识别其他的UA和SIP服务器。如果OPTIONS寻址到代理服务器，那么Request-URI设置为没有用户部分，和REGISTER请求的Request-URI设置一样。换言之，服务器接收到Max-Forwards头字段为0的OPTIONS请求，可能不管Request-URI而直接响应请求。

OPTIONS请求可以作为建立对话的一部分发送，查询在对话中以后可能使用的对等物的能力。

构造OPTIONS请求

遵循SIP请求的标准规则来构造OPTIONS请求。

OPTIONS请求可能出现Contact头字段。

Accept头字段应该包括UAC希望从响应中接收到的消息体类型。典型地，这用来设置一种用于描述UA媒体能力的格式。

OPTIONS请求的响应，假定为在原始请求Request-URI的范围内的。然而，仅当OPTIONS作为建立对话的一部分发送时，它才能保证生成OPTIONS响应的服务器可以接收到将来的请求。

处理OPTIONS请求

使用标准规则来构造OPTIONS响应。选择的响应代码必须和INVITE请求已经选择的一样。这允许OPTIONS请求用于确定UAS的基本状态，指示UAS是否接受INVITE请求。

在对话中接收到OPTIONS请求生成200响应，和对话外构造的一样，对对话没有任何影响。

由于代理处理OPTIONS和INVITE请求的不同，OPTIONS的使用有局限性。分发的INVITE请求可能返回多个200响应，而分发的OPTIONS请求只

返回一个200响应，因为代理使用处理non-INVITE处理机制处理的。

如果代理服务器生成OPTIONS响应，那么代理返回200响应，列出服务器的能力。此响应不包括消息体。

Allow、Accept、Accept-Encoding、Accept-Language、Supported头字段应该出现在OPTIONS请求的200响应中。如果代理产生此响应，因为代理是方法不可知的，Allow头字段应该视作模糊的而被忽略。Contact可能出现在200响应中，并和3XX响应有相同的语义，即它们可能列出到达用户的一系列可选的名字和方法。Warning头字段也可能出现。

消息体也可能在OPTIONS请求中发送，其类型由OPTIONS请求的Accept头字段确定（如果Accept头字段不存在，默认值为application/sdp）。如果此类型包括可以描述媒体能力的类型，那么，UAS应该为此目的在响应中包括消息体。

ZhaiPillary

2015/06/07 于上海

博客地址：http://blog.csdn.net/pillary