在一个新的请求创建以后，前面提到的那些头域已经被构建。添加任何额外的可选头域，需要指定具体的method。

　　SIP请求可以包含一个 MIME解码的消息体。无论在请求中包含什么样的消息体，某些头域必须进行规范化处理，进行内容中的字符整合。更多关于这些头域的说明，参考章节 20.11 到 20.15。

　　请求的目的地是通过计算获得的。除非，在发送请求的路径存在一个逻辑策略强制操作，否则请求目的地必须是通过DNS处理流程来处理，具体处理描述参考 [4]。如果在route set的第一个要素表示是严格路由的话（导致重构请求，具体描述在Section 12.2.1.1）， 这个处理流程也必须使用在请求的Request-URI中。否则，这个流程使用在请求中的第一个Route头中（如果存在的话）或如果当前没有Route的时候，使用在请求的Request-URI。这些流程产生了按序的设置组，包括了地址，端口和参数方式。在处理流程中，URL作为输入数据，他们的处理流程不依赖于URL本身，如果Request-URI设置了一个SIPS的源，UAC必须遵从处理流程 [4]，输入的URL是一个SIPS URI。

　　本地策略可以设定一系列可选的目的地地址。如果Request-URI包含一个SIPS URI，任何可选目的地地址必须支持TLS连接。除此之外，如果请求中没有包含Route头的话，对可选目的地没有任何限定设置。对于已存在的route set来说，通过这样的方式，它可以提供一个简单可选 方式来设定一个outbound proxy 代理。但是，不推荐使用那种方式来设置一个outbound proxy；应该通过一个单URL使用一个已存在的route set替代设置方式。 如果一个请求中包含一个Route头的话，这个请求应该被发送到最顶部的Route地址，但是这个请求也可以被发送到任何服务器，只要UA认可其身份，其身份设置是通过Route和Request-URI 策略设定的。具体的策略设定在此规范中（相反的规范设置RFC 2543）。尤其是一个UAC配置了outbound proxy，它应该尝试发送请求到一个地址，这个地址应该是第一个Route头域地址 ，而不是调整发送策略，这个策略发送所有消息到这个outbound proxy。

　　这样做的目的可以确保outbound proxies不添加Record-Route头域值，这些头值将会被丢出后续的请求路径。它允许不能解析第一个Route URI的终端对outbound proxy代表执行任务。

　　UAC应该遵从对stateful要素定义的处理流程，这个流程在[4]有具体的定义，UAC应该一直尝试每个地址直到连接到一个服务器地址。 每个尝试连接都构成一个新的事务，并且因此每个携带最顶部Via头值的传输都会有一个新的branch参数值。进一步说，在Via头中的传输值被设置为传输方式设定的值。无论这个值怎么设置，这个值是传输方式针对目的地服务器决定的。

　　响应消息首先是通过传输层进行处理，然后在传输到事务层。事务层执行自己的处理流程，然后再传递回TU处理。在TU中的大部分响应处理流程是和具体的method相关的。但是，一些基本的处理方式不依赖于methods本身。

　　在一些情况下，一些由事务层返回的响应消息不是SIP消息，是一个事务层错误。当从事务层收到一个超时错误时，它必须被作为一个408错误。如果由传输层报告了一个致命的传输错误（通常情况下，是因为一个UDP中的致命ICMP错误或TCP的连接错误），这种状态必须被视为一个503错误代码（服务不可用）。

　　UAC必须处理任何无类别等级的最终响应消息，并且UAC也必须可以处理任何x00类别的响应消息。例如，如果一个UAC收到一个无类别响应代码是431的响应消息，此UAC可安全地认为可能在请求中有什么错误发生。一个UAC必须视临时响应消息是不同于100响应的，它也不会被视为183响应消息。UAC必须能够处理100响应和183响应消息。

　　如果在响应消息中出现了一个以上的Via头域值，此UAC应该丢弃这个消息。

　　多个出现的Via头域值是请求发起方置入的值，这些消息是错误设置或者配置文件损害导致。

　　对于转发协议的处理上（例如，301响应状态码），客户端应该基于转发请求，在Contact头中使用URL（s）重新构建一个或多个新的请求。这个过程类似于代理对3xx类别响应的递归处理，具体的细节参考16.5和16.6章节。客户端启动时携带初始的目标地址列表，其中包含完整的URL。这是初始请求的Request-URI。 如果客户端希望基于3xx重构新的请求，它会置入这些URLs在目标列表中。在此规范中，对象的限制是，一个客户端可以选择哪个URLs可以置入到目标组设置。当代理递归发生时，客户端处理3xx类别响应时，它一定不能再次添加任何已给定的URL到目标组中。如果初始的请求已经在Request-URL中有一个SIPS URL，客户端可以选择递归到一个非-SIPS URI，但是应该通知转发用户，这是一个不安全的URL。

　　任何新请求可以接收3xx响应，这些响应自己包含初始的URL，这些URL作为contact。可以配置两个地址互相转发。在目标地址组置入一个给定的URL，其目的是防止无限转发环路发生。

　　当目的地组设置增加时，客户端可以以任何顺序对URLs生成新的请求。一般的机制是在Contact头中设置一个"q"参数值来表示顺序。对URL生成的请求可以是并行方式或连续生成方式。一种方式是通过连续方式处理递减的q-值组，并且以并行方式处理在每个q-值组的URL。另外一种方式是按照递减的q-值顺序，仅执行连续处理，在相同q-值的contacts之间任意选择一个值。

　　如果连接在列表中的contact失败，继续连接列表中的下一个地址，直到列表地址连接全部失败。如果地址连接全部失败的话，那么这个请求就已经失败。

　　失败结果应该通过失败响应码来检测（响应码高于399）；对网络错误来说，客户端事务层将会对事务层用户报告传输层所发生的错误。注意，一些响应码（详情参见8.1.3.5）表示请求可被重新获取；重新发送到请求不应该被认为是失败响应。

　　当收到针对某个特定contact地址的失败时，客户端应该尝试下一个contact地址。这样就会导致针对发送的新请求创建一个新客户事务。

　　为了在3xx响应中基于一个contact地址创建一个请求，除了“method-param”和 “header”URI（参考 Section 19.1.1 章节对参数的定义）以外，UAC必须从目标组中拷贝所有URL到Request-URI。它使用“header”参数为新请求创建header头值，覆盖和转发请求中相关的头域值，具体操作规范参考Section 19.1.5。

　　注意，在一些例子中，在contact地址中，已经构成通信关系的头可以替换追加到已存在的请求的头中，这些请求的头是在初始转发请求中的头。作为一个一般规则，如果头域可以接受以逗号隔离的域值列表，那么新的头值可以追加到初始转发到请求中。如果头域不能接受支持追加多个值的话，初始转发请求中的值可以被在contact地址中已经构成通信关系的头域值覆盖。例如，如果返回的contact地址携带了如下值的话：

　　那么，在初始转发请求中的Subject头可以被覆盖，但是这个HTTP URL很少被追加到任何已存在的Call-Info头值中。

　　规范推荐UAC重用在初始转发请求中同样的To，From和Call-ID，但是UAC例如也可以选择更新Call-ID支持新的请求。

　　最后，一旦一个新的请求生成以后，新请求使用一个新客户端事务发送这个请求，因此，它必须在最顶部的Via头中生成一个新的branch ID。关于这一讨论，参考Section 8.1.1.7。

　　从其他角度所期望的，转发响应接收方发送到请求应该重用初始请求的头域和消息体。

　　在一些例子中，Contact头域值可能在UAC端被临时或永久缓冲保存，这取决于收到的状态码和内部超时设置状态。查看21.3.2 和21.3.3章节介绍。

　　未完继续……