网络自己发 sip invite_SIP协议规范RFC3261中文分享-9

8.1.1.5 CSeq

CSeq 头的目的是对事务确认和排序。它由一个序列号和一个method构成。这个method 必须匹配请求的method。对于dialog之外的非-注册请求，此序列号码是一个任意值。这个序列号码必须是一个可表达的值，此值是一个32-bit unsigned 整数，并且它必须少于 2**31。只要它遵守以上指南，客户端可以使用任意机制选择CSeq头。

Section 12.2.1.1 讨论了在dialog中CSeq的构成方式。

例如：

CSeq: 4711 INVITE

8.1.1.6 Max-Forwards

Max-Forwards头支持一个有限的跃点数，此跃点数是一个请求从此路径开始的初始点到传输到最终目的地经过的跃点。它由一个整数构成，每经过一个跃点，跃点数会自动减少一个数字。如果这个Max-Forwards值在抵达请求的最终目的地前降低到0，它将会被拒绝，同时返回一个483(Too Many Hops) 错误响应。

UAC必须在每个请求中插入一个Max-Forwards头，发起的请求中初始的这个值应该是70。 这个数值已经足够大，可以保证在一个SIP网络环境中没有环路时请求不会被丢弃，但是有时环路发生的时候可能也没有消耗很多的代理资源。用户可以选择比较低的值设置，但是一定要注意，UA需要了解此网络拓扑环境。

8.1.1.7 Via

Via头值表示一个传输方式，这个传输方式实际上是响应消息发送到地址，这个地址是针对事务和确认来说的。只有下一跳的传输选择以后，Via头才能被添加(参考使用流程[4])。

当UAC创建一个请求后，它必须在请求中插入一个Via。协议名称和协议版本必须是SIP 和2.0。 Via 头必须包含一个branch参数。这个参数用来确认被这个请求创建的事务。这个参数支持客户端和服务器端。

无论是从空间和时间角度来看，branch参数在这个UA发送的所有请求中具有唯一性。这个规则对CANCEL和non-2xx响应的ACK是例外。就像我们在下面讨论的一样，CANCEL 请求的branch参数和这个请求被取消的参数是一样的。同样，在Section 17.1.1.3的讨论中，一个对non-2xx响应的ACK响应也有同样的branch ID，这个ID和INVITE响应它的是一样的。

The uniqueness property of the branch ID parameter, to facilitate its use as a transaction ID, was not part of RFC 2543.

branch ID必须按照规范的格式来处理，它必须以字符"z9hG4bK"开头。这七个字符是一种比较神奇的处理方式(7被认为可以支持足够的资源，以便保证和旧规范RFC 2543兼容，旧规范没有选择这个数值，所以不会导致冲突)，因此，收到这个请求的服务器端可以决定通过这种方式来构建branch ID。

Via头的maddr，ttl，和其他请求将在传输层处理(Section 18)。

对于代理来说，Via处理方式在Section 16.6Item 8 和Section 16.7 Item 3说明。

8.1.1.8 Contact

Contact头提供一个SIP或SIPS URL，这个URL用来联系指定的UA示例的后续的请求。这个头必须是现存状态，并且在请求中包含完整的SIP或者SIPS URL，可以支持dialog创建。在此规范中定义的methods，它们仅包括INVITE请求。对于这些请求来说，Contact的范围是全局的。这也表示，Contact头值包含一个URL，UA通过这个URL接收请求，并且这个URL必须是有效的，甚至可以使用在后续的请求中，这些请求已经不在dialog范围内的请求。

如果Request-URI或最顶部的Route 头值中包含了一个SIPS URL，这个Contact也必须包含一个SIPS。

关于更多Contact头域的说明，参考Section 20.10。

8.1.1.9 Supported and Require

如果UAC支持拓展功能的话，服务器端可以支持对此的响应，UAC应该在请求中列出一个可选标签tags来表示可支持的拓展功能，可选择并且参考(Section 19.2)。

列出的可选标签必须来源于在标准规范RFC中定义的拓展。这样做的目的是服务器端防止客户端强制使用非标准的，或厂家定义的功能接收服务。在一个请求中，测试类的和信息类的RFC拓展明确说明不能使用在Supported头中，因此，我们经常看到使用由厂家定义的拓展。

如果UAC希望坚持让服务器理解这个拓展功能，UAC坚持使用这个拓展的话，UAC必须在请求中插入一个Require头，这个头在可选标签中列出来表示需要服务器端支持这个拓展。

如果UAC希望在代理中坚持使用这个拓展功能的话，并且需要在代理路径理解这个拓展的话，UAC必须在请求可选标签列表中插入一个Proxy-Require头表示需要代理支持的拓展。

就像刚才在Supported头使用说明的一样，在Require和Proxy-Require头中的可选标签所支持的拓展必须来自于标准RFC定义的拓展。

关于更多Contact头域的说明，参考Section 20.10。

待续。。。

www.dinstar.cn

关注微信公众号：asterisk-cn，获得有价值的Asterisk行业分享

Asterisk freepbx FreeSBC技术文档: www.freepbx.org.cn

融合通信商业解决方案，协同解决方案首选产品：www.hiastar.com

Asterisk/FreePBX FreeSBC，官方qq技术分享群(3000千人)：589995817