sip协议有哪些 SIP协议规范RFC3261中文分享-SIP

11 Querying for Capabilities // SIP 能力查询

SIP method OPTIONS 支持一个UA查询

其他UA或者代理服务器相关的支持能力。这种方式允许客户端发现supported methods，content types，extensions，codecs，等相关能力支持。无需对第三方“振铃”。例如，客户端在INVITE中插入一个Require 头选项，客户端不能确定这个选项是否被目的地UAS所支持的话，客户端可以通过OPTION选项查询目的地UAS来是否支持此选项，UAS将会返回option结果，通过一个Supported头来表示查询结果。所有的UA必须支持OPTIONS method。

OPTIONS 请求目的地通过Request-URI来确认，此目的地确认消息可定位另外UA或一个SIP服务器端。如果此OPTIONS标识地址到一个代理服务器，此Request-URI设置为不带用户部分信息，这种处理方式和注册请求中的 Request-URI相似。

或者，服务器收到一个OPTIONS请求，携带的Max-Forwards头域值为零的选项，不管Request-URI，服务器端可以响应这个请求。

这种处理方式在HTTP/1.1中非常普遍。这种处理方式可以作为一种“traceroute”功能来检查个体跳点服务器支持能力，跳点服务器会发送一系列的OPTIONS请求，并且携带递增的Max-Forwards头域值。

就像一般的UA处理场景例子，如果OPTIONS没有产生响应消息，事务层会返回一个超时错误。这也表示目的地是不可达的地址，因此是一个无效的地址。

OPTIONS请求可以作为一个已创建的dialog的部分消息来发送，它可以查询对端的支持能力，这个支持能力可以使用在后续的dialog中。

11.1 Construction of OPTIONS Request

OPTIONS 请求使用标准的SIP请求规则来构建的，具体规则参考Section 8.1.1。

Contact头域可能出现在OPTIONS请求中。

Accept头应该包括在OPTIONS请求中，此头用来表示此消息体类型，UAC希望在回复的响应中收到此消息体类型。通常情况下，这是一种消息格式，这种格式用来描述一个UA的媒体能力，例如SDP（application/sdp）。

针对OPTIONS请求的响应假设限定在原始请求的Request-URI中。可是，仅当OPTIONS被作为已创建的dialog部分消息发送时，保证生成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

11.2 Processing of OPTIONS Request

对OPTIONS的SIP响应的构建是通过标准规则来实现的，具体的讨论在Section 8.2.6。响应码的选择必须和INVITE请求中的请求统一。如果UAS准备接受呼叫，那么将会返回200（OK），如果UAS处于示忙状态，那么486(Busy Here) 将会被返回，等等。这样就会支持OPTIONS请求来决定UAS的基本状态，可以用来表示UAS是否会接受一个INVITE请求。

在dialog中收到OPTIONS请求，此OPTIONS请求生成一个200（OK）响应，这个响应等同于一个已创建的，dialog之外的请求，这个请求不会对此dialog有任何影响。

因为代理对OPTIONS的处理方式和INVITE请求处理方式的不同，OPTIONS有其局限性。分叉的INVITE会导致返回多个200（OK）响应，一个分叉的OPTIONS将仅导致一个单个的200（OK）响应，因为它被视为代理使用了non-INVITE处理方式。具体详细介绍参考Section 16.7。

如果OPTIONS的响应是由代理服务器生成的话，代理返回一个200（OK），列出服务器的支持能力。响应消息中不包含消息体内容。

Allow，Accept，Accept-Encoding，Accept-Language，和Supported头应该出现在OPTIONS请求的200（OK）的响应中。如果响应消息是由代理生成的话，Allow头应该被省略，它是不规范的，代理对method具有不可知性。Contact头可能出现在200（OK）的响应中，和3xx响应的语义相同。在这种语义环境中，响应消息中可能列出可达用户的一系列可选名称和methods。告警头也可能出现在响应消息中。

消息体也可能被发送，发送何种类型的消息取决于OPTIONS请求中的Accept头域（如果没有出现此Accept头的话，默认发送application/sdp）。如果类型中包含了一种消息类型的话，这个类型描述了媒体能力的话，UAS应该在响应中包含一个消息体来说明媒体支持能力。关于这样的application/sdp构建方式，参考[13]。

根据在Section 11.1中的一个UAS请求生成的OPTIONS响应示例：

SIP/2.0 200 OK

Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877 ;received=192.0.2.4

To: <sip:carol@chicago.com>;tag=93810874

From: Alice <sip:alice@atlanta.com>;tag=1928301774

Call-ID: a84b4c76e66710

CSeq: 63104 OPTIONS

Contact: <sip:carol@chicago.com>

Contact: <mailto:carol@chicago.com>

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE

Accept: application/sdp

Accept-Encoding: gzip