sip协议解析与实现(c和c 使用osip)11

  • 格式:doc
  • 大小:25.50 KB
  • 文档页数:5

下载文档原格式

  / 5
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

sip协议解析与实现(c和c++使用osip)11

第八章查询能力

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.

这个行为与HTTP/1.1一致。这个行为可以被用于"追踪路由线路(traceroute)"功能,从而使用发送一系列递增的

Max-Forwards值的OPTIONS请求的方法检查消息路由过程中个别服务器的能力。

作为一般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 sip:carol@ SIP/2.0

Via: SIP/2.0/UDP

;branch=z9hG4bKhjhs8ass877

Max-Forwards: 70

To: <sip:carol@>

From: Alice

<sip:alice@>;tag=1928301774

Call-ID: a84b4c76e66710

CSeq: 63104 OPTIONS

Contact: <sip:alice@>

Accept: application/sdp

Content-Length: 0

第二节处理OPTIONS请求

对OPTIONS请求的应答使用RFC3261第8.2.6节描述的对标准SIP请求的应答规则。应答状态码必须与对INVITE应答的状态码采用相同的选择。例如,一个200(OK)将会在UAS准备接受一个呼叫时候被返回,一个486(Busy Here)将会在UAS繁忙的时候被返回。这允许OPTIONS日内供求用来探测UAS的基础状态,基础状态是指它可以指出这个UAS是否能够接受一个INVITE请求。

对接收到的对话内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节的请求):

OPTIONS sip:carol@ SIP/2.0

Via: SIP/2.0/UDP

;branch=z9hG4bKhjhs8ass877 Max-Forwards: 70

To: <sip:carol@>

From: Alice

<sip:alice@>;tag=1928301774 Call-ID: a84b4c76e66710

CSeq: 63104 OPTIONS

Contact: <sip:alice@>

Accept: application/sdp

Content-Length: 0