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

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 希望接收到的应答 媒体能力的类型，比如， SDP(application/adp) 。 中的消息体类型。典型的，这可能被设置成用来描述UA 中的消息体类型。典型的，这可能被设置成用来描述 UA 的 OPTIONS 请求的应答被认为是有限定范围的，它被限定在 原始请求的 Request-URI 内。只有当 OPTIONS 被作为建立 对话的一部分发送，它保证会话中后继的请求也由应答 OPTIONS 的服务器所接收时， 对 OPTIONS 请求的应答才是 可用的。 OPTIONS 请求的例子： OPTIONS sip: carol@ SIP/2.0 Via: SIP/2.0/UDP ;branch=z9hG4bKhjhs8ass877 Max-Forwards: 70 To: lt;sip:carol@gt; From: Alice lt;sip:alice@gt;;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 63104 OPTIONS Contact: lt;sip:alice@gt; Accept: application/sdp Content-Length: 0 第二节 处理 OPTIONS 请求 对 OPTIONS 请求的应答使用 RFC3261 第 8.2.6 节描述的对 标准 SIP 请求的应答规则。应答状态码必须与对INVITE 应答的状态码采用相同的选择。例如， 标准 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 ）应答，在应答 中应该列出这个服务器的能力。应答不能包含消息体。