SIP协议与应用场景技术分享笔记-卷1-rfc3261-8

　　以下是关于RFC3261的规范说明，内容比较枯燥。具体理解这些概念，建议读者参考笔者以前的文章：

　　一封信读懂SIP注册消息关键词

　　首先To头也是最重要设定了期望的请求逻辑，或者用户的address-of-record，或者是一个请求目标资源。这可能是或者不是最终请求接收方。To头可能包含一个SIP或者SIPSURL，但是，如果在其他所要求的场景中，它也可以使用其他的URLschemes （例如，tel URL （RFC 2806[9]）。所有的SIP部署必须支持此SIPURI scheme。任何支持TLS部署的，必须也支持SIPS URI scheme。To头支持一个显示名称。

　　UAC可以通过多种方式学习如何对一个特别的请求映射To头。通常情况下，用户建议通过人机界面输入To头，也许通过人工输入URL或从地址薄中选择其地址。很多情况下，用户没有输入完整的URL地址，而是输入一个数字字符串或者字母（例如，“Bob”）。这是UA的自定义的输入方式，用户自己解析这个输入结果。使用字符构建SIPURL的用户部分应用在UA期望名字可以被解析为一种域名格式，植入到SIPURL中的@符号前（例如，sip:bob@example.com）。使用字符构建SIPS的用户部分应用在用户希望通信在安全状态，名称可以被域名解析。右侧域名经常是请求者的主机名称，支持主机域处理出局的请求。对于某些功能来说非常有用，例如，“快速拨号功能”。快速拨号功能要求解析主机域名的用户部分内容。tel URL 可以使用在某些环境中，UA不需要设定域名，只是解析用户已输入的电话号码。更准确地说，每个请求通过的domain都会有这样的机会。举例，一个在机场的用户可能登录系统，通过一个outboundproxy发送请求。如果他输入号码是“411”的话（这个号码是美国当地号码查询系统），这个号码需要解析，然后通过在机场的 outbound proxy做进一步处理，而不是用户的主机domain处理。这种情况下，tel:411就是一个正确的选择路由。

　　一个在dialog外面的请求不能包含一个To tag; 请求中的To来确认dialog的peer。因为没有创建dialog，因此也没有tag出现。

　　关于To 头域的进一步介绍，请参阅Section 20.39。

　　以下是一个有效的To 头域的示例：

　　To:Carol <sip:carol@chicago.com>

　　From

　　From 头指示初始请求的逻辑实体，可能是用户address-of-record地址。就像To头值一样，它包含一个URL地址和可选显示名称。它被SIP要素用来决定一个请求所需要的处理规则（例如，自动拒绝呼叫）。这是非常重要的规则处理，在一个正在运行的UA中，From头不能包含IP地址和这个主机的FQDN，因为它们都不是逻辑名称。

　　From头支持一个显示名称。除了正确的语法以外，一个UAC应该使用这个显示名称"Anonymous"，如果客户实体是隐藏状态，则是一个无实际意义的URL（例如，sip:thisis@anonymous.invalid）。

　　通常情况下，在一个指定UA生成的请求中，其From头的值是由用户或者用户本地域名管理员预设临时值。如果一个指定的UA用来支持多个用户的话，它可能带有一个可切换到属性设置，这个属性设置文件包括一个URL，这个URL和其用户属性实体文件相对应。请求接收方能验证请求的发起方身份，以便确认它们在From报头的身份声明（Section 22规范了更多关于验证的机制设定）。

　　From报头必须包含一个由UAC选择的新的“tag”参数。具体选择细节查看Section 19.3。

　　更多关于From报头细节，参考Section 20.20。

　　例如：

From:"Bob" <sips:bob@biloxi.com> ;tag=a48s
From:sip:+12125551212@phone2net.com;tag=887s
From:Anonymous <sip:c8oqz84zk7z@privacy.org>;tag=hyh8

　　Call-ID

　　Call-ID 头工作方式类似于一个唯一的标识符，它用来成组一系列的消息。在一个dialog处理过程中，任何一方UA发送的所有请求和响应都必须包含相同的Call-ID。每个UA注册中的Call-ID应该是相同的。

　　在一个外部dialog由UAC创建的请求中，Call-ID头必须由UAC选择，在整个处理和时间段上，它可以作为一个全局的唯一标识，除非其他设定的methods处理流程修改它。所有SIPUA必须有其含义来确保这个它们生成的Call-ID头不会被其他UA不经意生成一个新的Call-ID。注意，当获取到请求时，对于某些失败响应处理时，这些失败响应针对此请求要求一个重新修正（例如，认证流程），这些获取到的请求不会认为是一个新的请求，因此，它们不需要一个新的Call-ID。

　　具体细节规范请参考Section 8.1.3.5。

　　规范推荐使用cryptographically random identifiers （RFC 1750[12]）来生成Call-ID。部署格式可以使用此格式"localid@host"。Call-ID是大小写敏感的，可以进行一比特一比特的简单对比。

　　使用cryptographicallyrandom identifiers提供了对会话的保护，防止被黑客篡改，同时也降低了唯一Call-ID的相似度冲突。

　　对于请求来说，不能通过配置或者界面来提供Call-ID头选项选择。

　　关于更多Call-ID头的说明，参考Section20.8。

　　示例：

　　Call-ID:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com