Querying for Capabilities -- 能力问询 (摘译自 RFC 3261)

最新推荐文章于 2024-01-05 17:19:52 发布

NorZ

最新推荐文章于 2024-01-05 17:19:52 发布

阅读量759

点赞数

分类专栏： SIP+IMS 文章标签：服务器扩展 c

SIP+IMS 专栏收录该内容

2 篇文章 0 订阅

订阅专栏

译者：崮山路上走9遍

SIP方法OPTIONS允许一个UA来查询另外一个UA或者proxy服务器的能力。这个提供个客户端一个手段来查询服务端支持的方法，内容类型，扩展，codecs等等。这些都不用”ringing”对方。比如，在客户端试图在INVITE请求头中增加一个请求字段选项的时候，它并不知道对方UAS能否支持这个选项，它就可以用OPTIONS来查询一下UAS，通过检查OPTIONS返回的Supported头域，就可以知道是否支持这个选项。所有的UA都必须支持OPTIONS方法。

OPTIONS请求的目标是用Request-URI指明的，这个既可以是一个UA也可以是一个SIP服务器。如果OPTIONS指向一个proxy服务器，Request-URI设置成为一个没有用户部分（user part）的，类似REGISTER请求中的Request-URI一样。或者，一台服务器收到一个OPTIONS请求并且Max-Forwards头域值是0的时候，它就需要响应这个请求而不需要关心Request-URI的内容。

这个机制就像HTTP/1.1一样。这个机制可以用来实现类似”traceroute”功能来通过发出一系列的有着增量Max-Forwards头域的OPTIONS请求来检查每一个途径节点的能力。

就像对一般UA机制来说，如果OPTIONS没有应答，transaction层能够返回一个超时错误。这个可能标志着对方无法到达因此无响应。OPTIONS请求可以作为建立会话的一部分，用来查询对方的能力使用，这样在后续对话中可以使用双方兼容的方式。

一个OPTIONS请求可以根据8.1.1节中的标准构造方法来进行构造。

Contact头域在OPTIONS请求中可以存在，也可以不存在。

Accept头域应当包含在请求中，用来标志UAC希望接收应答中的消息体的类型。通常情况下，这个设置成为UA的多媒体兼容能力，比如SDP(应用/SDP)格式。

对于一个OPTIONS请求的应答是假定是在原请求中的Request-URI范围内的。但是，仅当一个OPTIONS请求作为建立对话的一部分而发送的时候，后续的请求应当由收到并且响应这个OPTIONS请求的服务器进行处理。（就是说如果在建立会话的时候使用OPTIONS请求，那么OPTIONS之后的这些请求都应该由这个OPTIONS查询的服务器处理，这样才能保证使用的特性和OPTIONS查询出来的能力是一样的）

OPTIONS请求的例子：

OPTIONS sip: carol@chicago.com

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的应答的构造遵循标准的构造规则（8.2.6节描述）。应答码的选择必须和处理INVITE请求一样的应答码（就像处理INVITE请求一样的返回）。这就是说，200（OK）应当在UAS能够接收请求的时候返回，486（忙）应当在UAS如果忙的时候返回。这样OPTIONS可以用来检测UAS的基本状态，这就是说，我们可以用OPTIONS来知道UAS能否接收INVITE请求。

在一个对话中的OPTIONS请求会产生一个200(OK)的应答，这是和在对话外创建的并且对对话没有任何影响的请求相同。

这个OPTIONS的使用有一定的限制，因为对于proxy处理OPTIONS和INVITE请求的不同。一个分支的INVITE可以有多个200（OK）的应答返回，但是一个分支的OPTIONS只能有单个200（OK）应答返回。因为这是由于proxy处理OPTIONS请求是当作非INVITE的处理。参见16.7节有详细的说明。

如果OPTIONS请求的应答是由proxy服务器给出的，proxy返回一个200（OK）的应答，列出这个服务器的各种选项和能力。

应答没有消息体

Allow，Accept,Accept-Encoding,Accept-Language,和Supported头域应当在200（OK）应答中出现。如果这个是由proxy产生的应答，那么Allow头域应当忽略，因为proxy是方法无关的（也就是说不知道该如何处理方法的）。Contact头域可以在200（OK）的应答中出现，并且与3xx应答有相同的语义。这就是说，他们可以列出指向客户的一串名字和方法的集合（用以转发请求）。一个Warning头域是可以存在的。消息体也可以存在，消息体的类型是由OPTIONS请求的Accept头域指明的(application/sdp是缺省的，如果Accpet头域不存在的话)。如果Accept头域中包含了一个类型能描述媒体接收能力，UAS应当在应答中包含一个消息体用于这个用途。详细的application/sdp包体说明在[13]中描述。