12.2 对话中的请求 当两个 UA 之间的对话建立以后，他们都可以在对话中初始化一个新的事务 （transaction）。如果 UA 发送请求，将遵循 UAC 的事务规则。UA 接收请求将遵循 UAS 的规则。在建立对话的事务过程中，UA 扮演的角色可能是不一样的。 在对话中的请求可以包含Record-Route和Contact头域。不过，虽然他们会修改 remote target 的 URI，但是这些请求也不会导致对话的路由集被改变。明确说，如果请求不是 刷新 target 的请求，那么这个请求不会更改对话的 remote target URI,如果请求是刷新 target 的请求，那么这个请求才会更改对话的 remote target URI。对于用 INVITE 建立 的对话来说，唯一的能够刷新 target 的请求就是 re-INVITE(见 14 节说明)。可能会有其 他扩展定义通过其他方法来刷新 target 的请求。 注意 ACK 不是一个刷新 target 的请求。 刷新 target 请求只会更改对话的 remote target URI，并且更改由 Record-Route 指定的 路由集合。如果更新路由集合会带来严重的和 RFC2543 向后兼容问题。 12.2.1 UAC 行为 12.1.1.1 产生请求 在对话中的请求是通过用许多对话的状态部分来构造的。在 TO 头域中的 URI 部分必 须设置成为对话状态中的 remote URI。To 头域的 tag 参数必须设置成为 dialog ID 中的 remote tag 部分。请求的 From URI 必须设置成为对话状态中的 local URI。From 头域 的 tag 参数必须设置成为 dialog ID 的 local tag 部分。如果 remote 或者 local tag 是空 值，那么 tag 参数必须分别从 From 或者 To 头域中去除。 在请求序列中的原始请求的 To 和 From 头域的 URI 的使用方法是为了向下兼容 RFC2543 协议的，在 RFC2543 协议中，使用 URI 作为对话的标志。在这个规范中， 只有 tags 用于区分对话。有可能在本协议的后续版本中，在对话中的请求必须强制反 应原始请求的 To 和 From 头域的 URI 将会去除。 请求的 Call-ID 必须设置成为对话的 Call-ID。在对话中的请求必须严格遵循单个递增的 Cseq 序列号（每次增加 1）（当然要除了 ACK 和 CANCEL，这两个请求中的 Cseq 必 须和原始的请求或者确认请求一样）。因此，如果本地序列号（local sequence number）

17.1 客户端事务 客户端事务是通过维持一个状态机来提供服务的。 TU 和客户端事务通过一个简单的接口进行通讯。当 TU 希望初始化一个新的事务，它 创建一个客户端事务并且通过设置 ip 地址，端口和 transport 来把一个 SIP 请求交给它 传送。然后客户端事务开始执行它自己的状态机。合乎规格的应答会从客户端事务传送 给 TU。 总共有两种类型的客户端事务状态机，根据 TU 传递的请求的方法不同来区分的。一个 用于处理 INVITE 请求。这种状态机对应的是一个 INVITE 客户事务。另外一个是用来 处理其他所有的非 INVITE 请求的。它对应的是非 INVITE 客户事务。对于 ACK 来说， 是不存在客户事务的。如果 TU 希望送一个 ACK 请求，它直接交给通讯层进行通讯处 理。 INVITE 事务和其他事务是不同的，因为它的时间周期很长。通常，对于 INVITE 请求 的应答来说，都需要人的参与，这样会导致在应答 INVITE 请求之前会有很长的延时。 在三方握手（人，两方机器）的时候也会有很长的延时。在另一方面，其他请求的响应 都是很快就完成的。因为其他非 INVITE 请求事务是双方的握手，TU 能够立刻对非 INVITE 请求作出应答。 17.1.1 INVITE 客户事务 17.1.1.1 INVITE 事务概述 INVITE 请求包含了一个三方的握手。客户端事务发送一个 INVITE，服务端事务回送一 个应答，客户端事务发送一个 ACK。对于非可靠传输（比如 UDP），客户端事务每隔 T1 重发请求，每次重发后间隔时间加倍。T1 是一个估计的循环时间（round-trip time， RTT），缺省设置成为 500ms。几乎所有的事务定时器都以 T1 为单位，并且调整 T1 的 值也就调整了那些定时器的值。请求不会在可靠的通讯协议上重新发送。在接收到 1xx 应答以后，重发机制完全停止，并且客户端等待更进一步的应答。服务端事务可以发送 附加的 1xx 应答，这个应答并非由服务端事务可靠传输。 后，服务端事务会发送一个 终结应答。对于非可靠的传输协议，应答会间隔时间来重发，对于可靠的传输协议，它 只发送 1 次。对于客户端事务所接收的每一个终结应答，客户端事务都发送一个 ACK， 用于终止应答的重发送。 17.1.1.2 正式的描述 INVITE 客户端事务的状态机在图 5 中展示。初始状态，”calling”，必须保证 TU 是用 INVITE 请求来初始化一个新的客户端事务。客户端事务必须把请求发送到通讯层来进 行发送（18 节）。如果使用的是非可靠传输的通讯层，客户端事务必须启动一个定时器 A 并且由缺省值 T1 组成。如果是一个可靠的通讯协议，那么客户端事务不应当启动定

SIP协议中文版，RFC3261，对于英文基础比较差的通信专业或者音视频开发者，是个不错的文档。文档主要介绍建立音视频通话的全过程。

RFC3261中文版.pdf

12.1 创建一个对话 对话是由对一组特定请求的没有失败的应答来创建的。在本规范中，只有包含 To tag 的 2xx 和 101－199 应答，并且请求是 INVITE 的，会建立一个对话。当收到一个非终 结应答的时候，对话会建立成”early”状态，并且成为 early dailog。创建对话的时候可以 使用 Extension 来定义扩展。13 节描述了 INVITE 请求的更多细节。在这里，我们描述 与方法无关的对创建对话状态的处理。 UA 必须按照下边描述的方法对 dialog ID 进行赋值。

16.3 验证请求 在 proxy 转发请求之前，它必须检查消息的合法性。一个合法的消息必须经过如下的检 查： 1、 合法的语法 2、 URI scheme 3、 大转发次数 4、 (可选)循环检测（loop detection） 5、 proxy-require 6、 proxy-authorization 如果任何一步失败了，proxy 都必须作为 UAS（8.2）一样，应答一个错误码。 注意 proxy 并不要求检查合并的请求，并且不能把合并的请求当作一个错误的情况。终 端接收到合并的请求会根据 8.2.2.2 节讲述的内容进行分解。 1、 合法的语法。 请求要能够被服务端事务处理，那么请求就必须是语法无误的。请求中的任何与检查相 关的部分或者与请求转发节相关的部分都必须语法严格无误。在检查中，其他部分的严 格与否，在检查中都被忽略，并且在转发消息过程中保持不变。例如，proxy 不会由于 非法的 Date 头域而拒绝请求。同样的 proxy 不会在转发请求的时候移去非法的 Date 头 域。这个是为了设计成为可扩展的。以后的扩展可能定义新的方法、新的头域。proxy 不能拒绝由于包含了不认识的方法或者不认识的头域而拒绝转发这个请求。 2、 URI scheme 检查 如果 Request-URI 包含一个 proxy 所不能理解的 URI 形式，那么 proxy 应当通过返回 一个 416 来拒绝这个请求（Unsupported URI scheme）。 3、 大转发次数检查 大转发次数 Max-Forwards 头域（20.22）是用来限制转发的次数的。如果请求没有 包含 Max-Forwards 头域，那么这个检查将被忽略。如果请求包含了一个 Max-Forwards 头域，并且这个头域大于 0，那么这个检查就跳过。如果请求包含一个 Max-Forwards 头域，并且这个头域为 0，那么这个 proxy 不能转发这个请求。如果请求是 OPTIONS 请求，那么 proxy 可以作为 终响应者来响应这个请求，并且遵循 11 节讲述的产生应 答。否则 proxy 应当返回一个 483（too many hops）应答。 4、 可选的 Loop Detection 检查 proxy 可以检查看看转发是否可能导致循环。如果请求包含一个 Via 头域，并且这个头 域值，和 proxy 早先保留的请求的头域值相同，那么这个请求就是以前经过过本 proxy。 要么这个请求就是循环处理了，要么就是合法的循环处理。要检测请求是否循环处理， proxy 可以用 branch 参数，根据 16.6 节的第 8 步来计算，并且和接收到的 Via 头域做 比较。如果参数相等，那么请求就循环了。如果不等，那么请求就是合理的经过，并且 继续处理。如果检测到了循环，那么 proxy 应当返回一个 482（LoopDetechted）应答。 5、 Proxy-Require 检查 本协议的以后的扩展可能会要求额外的 proxy 特性。所以终端会在请求中包含一个 Proxy-Require 头域来表明会使用到那些特性，这样 proxy 就可以根据 Proxy-Require 判定自己是否能够支持这些特性。 如果请求包含一个Proxy-Require头域(20.29)并且有一个或者多个本proxy不能理解的 option-tags。那么这个 proxy 必须返回一个 420（Bad Extension）错误，并且这个错误

看很多地方都是GB版的，发个IETF中文版的上来大家共享下，以供大家共同学习！

本文档描述了会话发起协议（SIP），即有一个或多个参与者的用于创建、修改和终止会 话的应用层控制（信令）协议。这些会话包括 Internet 电话呼叫、多媒体分发和多媒体会 议。

sip协议详解 中文版 有目录版，取之于网络，用之于网络，网上没有目录，这个是我自己添加的目录