用户代理行为

概述
用户代理分两种：UAC和UAS。区分的依据在于请求方和响应方。
当一个请求发生之时，即使用某个方法，根据请求方和响应方产生了UAC和UAS，从而可以建立起事务（Transaction）来。所以UAC和UAS是对某个事务而言，或某个请求而言。

UAC和UAS的处理由两个特点。第一，基于请求或者应答是否在一个对话里，第二，基于请求的方法（method）。

UAC特性
1 产生一个请求
一个合法的SIP请求必须至少包含如下头域：TO,FROM,Cseq,Call-ID,Max-Forwards,Via;这些字段在所有SIP请求中必须包含。这6个字段是SIP消息的基本组成部分，他们提供了用于路由用的核心信息，包含了消息的地址，响应的路由，消息传递次数，详细的顺序，事务的唯一标志。
1.1 Request-URI
最开始的Request-URI头域应该是TO头域的的值。
1.2 Call-ID
Call-ID是一个在一系列消息中，区分一组消息的唯一标志。在对话中的任一UA的所有请求和所有应答的Call-ID必须一致。在UA的每次注册中，都应该是一样的。在会话外的时候，UAC发起一个新的请求，这个Call-ID头域必须由UAC产生一个全局（在时间和空间上都是）唯一的Call-ID,除非是请求头的方法（method）指明了别的产生方式。所有的SIPUA都必须保证自己产生的Call-ID不会和其他UA产生的Call-ID重复。
我们强烈建议用密码乱序随机串（RFC1750）来产生Call-ID。实现中，可以用类似”localid@host”这样的格式产生。Call-ID是大小写敏感的，并且通过简单字节/字节的来进行比较。
1.3 Cseq
Cseq头域是用来区分和做位事务的顺序使用的。他由一个方法（method）和一系列的顺序号码组成。方法（method）必须和请求的方法一致。对于对话外的非REGISTER请求来说，顺序号码可以是任意的。这个顺序号码必须可以由32位的无符号整数表达，必须小于2^31。
1.4 Via
Via头域是标志了用于事务传输的传输设备，并且也标志了应答送回的地址。只有当需要通过选择传输设备到达下一个节点(hop)的时候，才需要在头域中包含Via域。。当UAC创建一个请求，它必须在头域中添加一个Via域。protocol名字和protocol版本必须分别是SIP和2.0。Via头域必须包含一个分支(branch)参数。这个参数用于区分请求创建的事务。这个参数客户端和服务器都会使用。除了CANCEL和给非2xx应答的ACK以外，branch参数对UA发出的所有的请求来说，在时间和空间上必须唯一。CANCEL请求的branch参数必须和他所取消的请求的branch参数一致。给非2xxx（non－2xx）应答的ACK必须和其对应的的INVITE请求有相同的branchID。
1.5 Contact
Contact头域提供了访问后续请求的特定UA实例的联系方法.在任何会建立一个对话的请求中，Contact头域必须提供和包含一个SIP或者SIPSURI。在这个规范中定义的方法中，只有INVITE请求会建立一个会话。
1.6 Supported和Require
如果UAC支持服务端响应请求的SIP扩展，UAC应该在请求的时候包含一个Supported头域说明optionstags描述那些SIP扩展。optiontags中出现的扩展说明必须是遵循RFCs的标准扩展说明。
如果UAC要求UAS能够支持扩展，以便UAS能够处理UAC的特定请求，那么它必须在请求头中增加一个Require头域来说明处理本特定请求需要什么样的一个扩展optiontags。如果UAC需要请求经过的所有proxy都支持它发出的某个请求的扩展部分，它必须增加一个Proxy-Require头域来说明需要Proxy支持何种optiontag扩展。

2 发送请求
于是，我们就开始查找请求发送的目标。除非有其他的特定说明，目标必须是通过DNS来查找的，处理过程由RFC3263来定义。。如果路由表(routeset)中的第一个元素表明这是一个严格路由，那么这些过程必须在请求的Request-URI中说明。否则，这些过程在请求中被应用于第一个Route头域中（如果存在），或者在请求的Request-URI中（如果Route头域不存在）。这样一些过程产生了一系列的地址，端口，和用于传输的传输器。
本地策略可以指定一套额外的目的地用于发送。例如简单的外发（outbound）proxy的事前路由的选择。如果请求包含了Route头域，请求应该发送到Route头域最上边的一个位置，但是请求也可能被发给由本文档约定的Route或者Request-URI所指定的服务器(同RFC2543定义的相反)。特别的，一个配置了外发proxy的UAC应该首先尝试把请求发送给由第一个Route头域值指定的位置，而不是采用把所有消息都发给外发proxy的策略。这就保证了外发的proxy通过不增加Record-Route头域而不参与后续请求的路径。这个也允许让不能分析第一个RouteURI的终端，把请求交给外发proxy来发送。

3 处理应答
3.1 transaction层的错误
在某些情况下，从transaction层返回的应答不一定是一个SIP消息，而是一个transaction层的错误。当从transaction层收到一个timeout错误的时候，必须将这个timeout错误当作是收到了一个状态码是408（请求timeout）的应答。如果transport层报告了一个严重错误（通常取决于UDP传输中的严重的ICMP错误，或者是TCP连接中的错误），必须把这个错误当作是状态码503（服务未提供）的错误。
3.2 未知的应答
UAC必须把自己不认识的所有最终应答当作是x00的那类应答，当然UAC也必须能够处理所有的类别应答的x00的应答。并且，UAC必须能够处理所有的不认识的非终结应答响应当作是183(sessionprogress)。一个UAC必须能够处理100和183应答。
3.3 Vias
如果在应答中，有不只一个Via头域值存在，那么UAC应该丢弃这个消息。包含超过一个Via头域值的消息是因为被错误的路由或者消息被破坏。
3.4 处理3xx应答
由于接收到一个重定向的应答（比如，状态码是301的应答），客户端应该用在Contact头域中的URI(s)来组织一个或者多个基于重定向以后的新请求。客户发起请求的时候只有一个目标URI，就是原始请求中的Request-URI。如果客户端想在这个请求基础上重构一个基于3xx类别应答的新请求，那么就需要把这个需要尝试的URIs放到目标集合中去。
3.5 处理4xx应答
某个4xx应答码要求特定的UA处理，和请求的方法无关。

UAS特性
UAS在处理对话外的请求的时候，有一组规则需要遵守，这组规则与方法无关。
UASs应当遵循本节所规定的顺序来处理请求。（就是说，首先是身份认证，然后是方法判定，然后是头域，然后按照本文规定处理剩余部分）
1 方法判定（略）
2包头判断
如果UAS不认识请求中的包头域（就是说，包头域不在本规范中定义或者不在任何扩展中定义），那么服务器必须忽略掉这个包头域并且继续处理本请求。UAS必须忽略任何处理本请求所不需要的长得畸形的包头域。
2.2 合并的请求
如果请求的To头域中没有tag标志，UAS的处理核心必须检查基于正在进行的transactions上的请求。如果接收到的请求和正在处理的transaction的请求中的头域Fromtag,Call-ID,CSeq精确匹配了，但是请求并不匹配那个事务，UAS核心应该产生一个482（检测到循环）应答并且给服务器的transaction层发送。
2.4 应用扩展
如果UAS希望应用一部分SIP扩展，那么不可以在产生应答的时候做SIP扩展，除非这个扩展是在请求中的Supported头域中指明了的。如果这个扩展并没有在本请求的Supported头域中指明，那么服务端必须基于基准SIP给出应答，或者给出已知客户端支持的扩展应答。在极少数情况下，如果服务端不用扩展就无法处理请求，那么服务端应该发送421（需要扩展支持）应答。这个应答说明如果没有适当的扩展就无法给出正确的应答。在应答中需要的扩展必须在应答中的Require头域中指出。我们并不推荐这个方法，因为它会降低协同工作的能力。
2.6 产生应答
2.6.1 发送一个临时响应
很多情况下，在与方法无关的应答规范中，在非INVITE请求的情况下，我们都要求UAS不应该发送临时应答给请求者。在这种情况下，UAS应该尽快发送一个终结应答给非INVITE请求。
2.6.2 包头和Tags
应答中的Via头域必须和请求中的Via头域相等，而且顺序也必须相等。如果请求中包含了Totag，那么应答中的To头域必须和请求中的To头域相等。如果请求中的To头域并不包含Tag,那么应答中的To头域的URI必须和请求中的TO头域的URI相等；此外，UAS还必须增加一个Tag到To头域上（100（trying）应答是一个例外，在100中可能已经存在了一个tag）。这就提供了一个UAS正在应答的标志，也许就是对话ID的一部分。对同一个请求来说，它的应答必须有相同的tag标志，包括终结应答和临时应答（同样100（trying）除外）。
2.7 无状态UAS行为
无状态UAS就是说UAS本身不保持事务的状态。
无状态的UAS有下列重要的特性：
o 无状态的UAS不许发送临时应答（1xx）
o 无状态的UAS必须忽略ACK请求
o 无状态的UAS必须忽略CANCEL请求
3 发送应答
服务端事务使用最上边的Via头域值来决定把应答发送到哪里。