第八章 查询能力 SIP的OPTIONS方法允许一个UA查询另外一个UA或者一个代理服务器的能力。这能让客户端探测关于它们所支持的方法、内容类型、扩展和编码等信息,而不用"呼叫(ringing)"另外一端。例如,在客户端插入了一个Require头域到INVITE中,并列出了不确定目标UAS是否支持的能力之前,它可以先使用OPTIONS方法查询目标UAS是否要查询的选项被目标UAS在应答的Supported头域中返回。所有UA必须支持OPTIONS方法。 OPTIONS方法的目标使用Request-URI来标识,因为它可以表示不同的UA或者SIP服务器。如果OPTIONS被定位到一个代理服务器,Request-URI不由客户端设置,这类似于REGISTER请求设置Request-URI的方法。 如果服务器接收到一个Max-Forwards头域的值为0的的OPTIONS请求,它要对这个请求进行应答而不用管Request-URI. 作为一般UA的行为,如果OPTIONS长时间没有应答,事务层能够返回一个超时错误。这将指出,目标是不可到达的并且查询的能力是不可以使用的。 OPTIONS请求可能由建立一个对话的一端发送,用于查询对端在后面的对话中可能会被使用到的能力。 第一节 构造OPTIONS请求 OPTIONS请求使用像RFC3261第8.1.1讨论的标准的构造SIP请求的规则来构造。 OPTIONS可能会有一个Contact头域。 应该包含一个Accept头域用来指出UAC希望接收到的应答中的消息体类型。典型的,这可能被设置成用来描述UA的媒体能力的类型,比如,SDP(application/adp)。 OPTIONS请求的应答被认为是有限定范围的,它被限定在原始请求的Request-URI内。只有当OPTIONS被作为建立对话的一部分发送,它保证会话中后继的请求也由应答OPTIONS的服务器所接收时,对OPTIONS请求的应答才是可用的。 OPTIONS请求的例子: 第二节 处理OPTIONS请求
对接收到的对话内OPTIONS请求构造的200(OK)应答与构造对话外的OPTIONS请求的应答一样,并且与对话没有任何冲突。 由于代理服务器处理OPTIONS和INVITE请求不同,所以对OPTIONS的使用方法是有一定限制的。一个有分支的INVITE能够引起返回多个200(OK)应答。而一个分支的OPTIONS请求将只引起一个200(OK)应答,因为OPTIONS请求被代理服务器视为非INVITE请求来处理。参看RFC3261第16.7节的详细说明。 如果代理服务器对OPTIONS进行200(OK)应答,在应答中应该列出这个服务器的能力。应答不能包含消息体。 Allow,Accept,Accept-Encoding,Accept-Language和Supported头域应答出现在对OPTIONS请求的200(OK)应答中。如果是代理服务器构造的应答,Allow头域应该被忽略。这是因为代理服务器不针对方法进行处理。Contact头域可能出现在200(OK)应答中,并且包含与3xx应答包含相同的语义。也就是说,它们可能列出可以接触到的用户的一系列名字或者一系列方法(这样可以重定向请求)。Warning头域可能出现在应答中。 可能发送一个消息体,消息体的类型由OPTIONS请求的Accept头域决定(如果没有Accept头域,默认为application/sdp)。如果类型中包括一个可以描述媒体能力的类型,UAS应该为此在应答中包含一个消息体。为application/sdp构造一个这样的消息体将在[13]中描述。 UAS构造的OPTIONS应答的例子(符合RFC3261第11.1节的请求):
|
|