分享

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

 gljin_cn 2014-03-16

第八章 查询能力

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@chicago.com SIP/2.0
      Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877
      Max-Forwards: 70
      To: <sip:carol@chicago.com>
      From: Alice <sip:alice@atlanta.com>;tag=1928301774
      Call-ID: a84b4c76e66710
      CSeq: 63104 OPTIONS
      Contact: <sip:alice@pc33.atlanta.com>
      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@chicago.com SIP/2.0
      Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877
      Max-Forwards: 70
      To: <sip:carol@chicago.com>
      From: Alice <sip:alice@atlanta.com>;tag=1928301774
      Call-ID: a84b4c76e66710
      CSeq: 63104 OPTIONS
      Contact: <sip:alice@pc33.atlanta.com>
      Accept: application/sdp
      Content-Length: 0

 

    本站是提供个人知识管理的网络存储空间,所有内容均由用户发布,不代表本站观点。请注意甄别内容中的联系方式、诱导购买等信息,谨防诈骗。如发现有害或侵权内容,请点击一键举报。
    转藏 分享 献花(0

    0条评论

    发表

    请遵守用户 评论公约

    类似文章 更多