SIP协议解析与实现(c和c 使用osip) 5

第五章 一般用户代理行为

一个用户代理表示一个终端系统。它包含一个用户代理客户端（UAC）和一个用户代理服务器端（UAS)。UAC创建请求，UAS对请求进行响应。UAC能够创建基于外部事件的请求（如用户按下了一个按钮，PSTN线路中的一个信号等）并且能够处理一个应答。UAS能够接收请求，并且基于用户输入、外部激发、程序运行的结果或者一些其它的机制来构造对请求的应答消息。

当UAC发送一个请求，这个请求可能通过多个代理服务器传输，代理服务器将请求向UAS传输。当UAS创建一个应答，应答逆着请求发送的路径发送给UAC。

UAC和UAS的处理依赖于两个主要因素。第一，依赖于请求和应答是否是对话内还是对话外，第二依赖于请求的方法。对话在RFC3261第12章完整的描述。对话表示两个UA之间端对端的关系，它由像INVITE这样特定的SIP方法建立。

这章我们介绍的是UAC和UAS对对话外请求方法的处理规则。

对于请求和应答的安全相关的问题在RFC3261第26节介绍。这包括UAC和UAS之间相互验证的机制。

第一节 UAC行为

请求的创建

这一节主要描述UAC的对话外行为。

一个有效的SIP请求最少必须包含一下头域：To, From, CSeq, Call-ID,Max-Forwards和Via。这些头域在SIP请求中是强制的。它们为许多消息路由服务提供支持。这些服务包括：消息定位、应答的路由、限制消息传播、消息次序和事物的唯一标识。包含方法、请求URI和SIP版本的请求行也是强制出现的。

会话外的INVITE请求是用来创建一个会议的（RFC3261第13节），OPTIONS请求是用来查询能力的（RFC3261第11节）。

Request-URI

初始的Request-URI必须设置成与To头域的值相同。一个值得注意的例外是REGISTER方法。RFC3261第10节将介绍REGISTER方法的Request-URI的设置方法。

由于一些特殊原因，一些预先存在的路由设置会影响一个消息的Request-URI。预先存在的路由设置用于标识一串服务器次序，UAC发送的会话外请求时会按照这个词序经过服务器传递。通常由用户或者服务提供者设置UA或者由非SIP机制处理。如果提供者希望为UA设置一个外部的代理，强烈推荐使用预存在的路由设置，并为这个代理提供一个URI。在包含预存在的路由设置并且含有多个Route头域的方法中，Request-URI的设置方法在RFC3261第12.2.1.1节详细介绍。

To头域

To头域首先指出这个请求期望的逻辑接收者，或者用户报告的地址，或者这个请求目标的资源。这可能是也可能不是这个请求最终的接收者。To头域可能包含SIP或SIPS URI。但是它也可以使用其它的URI模式（例如，tel URL (RFC 2806 [9]）。所有的SIP实现必须支持SIP URI模式。To头域还允许一个显示名称（display name）。

一个UAC有很多方法来设置一个特殊的请求的To头域。通常用户通过用户接口手工输入或者在一列地址簿中选择URI来设置To头域。通常用户不输入完整的URI，而只是一串数字或者字母（如"bob"）。UA能够解释这些输入，UA将用户输入的名字进行处理，加上域名等信息，形成SIP URI（例如：sip:bob@example.com）。使用SIPS URI暗示用户要进行安全通信。"@"后面通常是请求方的域名。这个域名用于处理外部请求。Tel URI用于当UA不希望指定域名而由用户指定了一个电话号码。

一个对话外请求的To头域不能包含To标签(tag)。因为To头域中的标签表示对话中的一端。

参阅RFC3261第20.39节了解关于To头域更多的信息。下面是一个有效的To头域的例子:
To: Carol <sip:carol@chicago.com>

From头域

From头域标识请求发起人的逻辑ID，这可能是用户注册的地址。与To头域一样，它包含一个URI和一个可选的显示名称。它被SIP元素决定如何处理这个请求（例如，对于某些发送者，采取自动拒绝接听的操作）。因此，在From头域中不包含UA运行的本地IP地址和本地域名是非常重要的，因为这些是不合理的名字。

From头域可以包含一个显示名称。如果发送者隐藏自己的标识，那么UAC应该使用一个有匿名含义的，但语法有效的URI（像：sip:thisis@anonymous.invalid）。

在一个请求中From头域的值通常由UA的用户或者本地域名管理员预先指定的。如果这个UA有多个使用者，它将能够根据用户的标识自动切换配置。请求的接收者能够通过From头域鉴别一个请求的发送源，从而来确定是谁发送的请求（RFC3261第22节详细介绍关于验证的相关内容）。

From头域必须包含一个新的"tag"参数，这个参数由UAC生成。RFC3261第19.3节介绍如何确定"tag"参数。

关于From头域更多信息参见RFC3261第20.20节。下面是From头域的一些例子：
      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头域唯一标识一序列消息。UA必须保证在一个对话内的所有请求和应答的Call-ID头域值相同。

对于UAC创建的新的会话外请求的Call-ID头域，除非该方法特殊说明，否则UAC必须分配从空间和时间上全局唯一的标识。所有SIP UA必须有方法保证它们生成的Call-ID头域不会被其它UA生成。注意，当因为接收到一个失败应答,且这个应答要求修改请求的时候，重发的请求不被认为是个新请求，所以不需要重新构造Call-ID头域。参考RFC3261第8.1.3.5节。

推荐使用cryptographically随机标识（RFC1750）生成Call-ID头域。可以使用"本地标识@域名"的格式。Call-ID头域是大小写敏感的。关于Call-ID详细内容参看RFC3261第20.8节。下面是Call-ID头域的例子：
  Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com

CSeq头域

CSeq头域用于标识和排序事务。它由一个序号和一个方法名组成。方法名必须与请求中的方法相同。对话外的非REGISTER请求中的序号是任意的。序号必须是个32位无符号整数并且必须小于2**31。RFC3261第12.2.1.1节详细讨论了如何构造对话外的CSeq头域。下面是CSeq头域的例子：
      CSeq: 4711 INVITE

Max-Forwards头域

Max-Forwards头域用来限制一个请求发送到目的地址中间过程所经过的转发节点数（也称跳数(hop)）。这个头域由一个整数组成。这个整数被每一跳递减。如果一个请求在被发送到目的地前，Max-Forwards头域的值被减到0，这个请求将被拒绝，请求的发送者将接收到483（太多跳）的失败应答。

一个UAC必须向每个请求中插入Max-Forwards头域，且初始值应该是70。这个值已经足够大来保证请求不会被非循环的SIP网络扔掉。但是在一个循环的SIP网络中，这个值又不够消耗代理服务器资源。比较小的值要小心使用，并且只有知道UA所在的网络环境很好的情况下使用。

Via头域

Via头域用于标识一个事物的传输和标识应答将回复的地方。只有当下一跳被选择且能够接收消息的时候，才会向一个Via头域插入一个值。

当UAC创建一个请求，它必须向这个请求插入Via头域。其中协议名和协议版本必须分别是SIP和2.0。Via头域必须包含一个branch（分流）参数。这个参数用来标识这个请求创建的事物。它在服务器端和客户端都被使用。

branch参数的值在这个UA所发送的请求中必须在空间和时间上都是唯一的。CANCEL和对于非2xx应答的ACK消息是个例外。CANCEL请求将带有与要取消的请求相同的branch参数值。在RFC3261第17.1.1.3节将讨论对于非2xx应答的ACK将包含与这个非2xx应答所对应的INVITE请求相同的branch参数值。

branch参数必须以"z9hG4bK"开头，这7个字母作为模数。所以，服务器接收到这个请求，可以确定branch ID的结果是符合本手册的。

当请求被传输层处理的时候（RFC3261第18节），Via头域的maddr, ttl, and sent-by组成部分的值将被设置。代理服务器处理Via头域的相关信息在RFC3261第16.6节第8项和第16.7节第3项。

Contact头域

Contact头域支持SIP URI或者SIPS URI。后继的请求能够使用这些URI精确的接触到这个UA实例。Contact头域必须出现并且包含一个SIP URI或SIPS URI在任何能够创建一个对话的请求当中。在本手册中能够创建一个对话的请求只包含INVITE请求。对于这些请求，Contact头域是全局范围的。也就是说，Contact头域值包含的URI是UA希望接收请求的URI，即使是并发的会话外请求，这个URI也必须是有效的。

如果请求URI或者Route头域最顶端的值包含一个SIPS URI，那么Contact头域也必须包含SIPS URI。

关于Contact头域更多的详细信息参看RFC3261第20.10节。

Supported头域和Require头域

如果UAC支持对SIP的扩展，且这个扩展能够被服务器回应，那么这个UAC必须在请求中为包含一个Supported头域列出可选的标签（RFC3261第19.2节）。

可选的标签必须只包含在RFC中定义的标准扩展。这是为了防止服务器为客户实现的非标准的、自定义的特性提供服务。

如果UAC希望发送一个UAS能够理解的扩展，UAC必须向请求中插入Require头域来为这个扩展列出可选的标签。如果UAC希望在请求中使用一个扩展并且任何转发代理都知道这个扩展，那么它必须向请求中插入Proxy-Require头域为这个扩展列出可选标签。

像Supported头域一样，Require头域和Proxy-Require头域必须只包含标准扩展。

额外的消息组成部分

在一个新的请求中上面描述的头域已经被适当的创建好后，可以插入一些额外的该方法指定的可选的头域。

SIP请求可能包含一个MIME-encoded消息体。不管请求包含的消息体的类型是什么，某些头域必须明确的表达消息体的内容。更多了解头域的信息参看RFC3261第20.11节到20.15节。