4请求转发

对于上一步确定的每一个目的地，proxy转发请求都遵循下列步骤：
1）、 拷贝一个接收到的请求
2）、 更新Request-URI
3）、 更新Max-Forwards头域
4）、 可选增加一个Record-Route头域
5）、 可选增加附加的头域
6）、 路由信息后处理
7）、 决定下一个节点地址、端口、通讯协议。
8）、 增加一个Via头域值
9）、 如果需要，增加一个Content-Length头域
10）、 转发这个新的请求
11）、 设置定时器C
（2） 更新Request-URI
在拷贝好的请求中的Request-URI必须用目的地的URI进行替换。
（3） Max-Forwards
如果拷贝的头域包含一个Max-Forwards，proxy必须把这个域值减一。
如果拷贝的头域没有包含一个Max-Forwards头域，proxy必须自己增加一个头域，缺省值是70。现在有一些UA不会在请求中填写Max-Forwards头域。
（4）Record-Route
在建立一个对话的请求时，如果希望保留这个请求创建的对话中，后续的请求依旧是要经过本proxy，那么本proxy必须增加一个Record-Route头域值在这个拷贝中，并且增加的这个头域值应当是在其他现存的Record-Route头域之前。
而在对话建立之后的请求中，即使不再增加Record-Route，对话之中的请求还是会经过该代理服务器，除非终端UA重建一个对话。
在Record-Route头域中防止的URI必须是SIP或者SIPSURI。这个URI必须包含一个lr参数。
当proxy需要查看所有对话中的消息的时候，我们就需要Record-routeing，即一般在建立对话的请求INVITE中包含Record-Route头域。
（6）处理路由信息
如果请求的拷贝中包含了Route头域，这个proxy必须检查这个Route头域的第一个值。如果这个URI并没有包含lr参数，那么proxy必须根据下列步骤修改这个请求：
－ proxy必须把Request-URI放在Route头域中的最后一个值。
－proxy必须把第一个Route头域的值放在Request-URI中，并且从Route头域中删去。
（7）确定下一个节点的地址，端口和通讯协议。
proxy可以有自己的策略来决定发送请求到特定的IP地址，端口和transport，可以和Route的值或者Request-URI的值无关。
proxy还可以应用RFC 3263的步骤来决定应当向哪里发送这个请求。
（8）增加一个Via头域值 。
proxy必须在请求的拷贝中增加一个Via头域值，并且在其他Via头域值之前增加。proxy需要计算自己的分支参数，并且应当是全局唯一的分支，并且包含必要的magiccookie。
在proxy构造分支参数的值上，有一个附加的约束，用来进行循环的检测。一个要检测循环的proxy应当创建一个由两部分组成的分支参数。第二部分是用来做循环检测的，并且是从螺旋中判定是否存在循环。
（8）设置定时器C。
为了能够处理INVITE请求没有产生终结应答的情况，TU使用一个定时器。

5应答的处理
当proxy收到一个应答的时候，它首先尝试定位一个与这个应答匹配的客户端事务。如果没有匹配，proxy必须作为无状态的proxy来处理这个应答（即使这个应答是信息性质的应答）。如果与应答匹配的客户端事务找到了，那么这个应答将转给这个客户端事务进行处理。
当客户端事务把应答交给proxy层，将会执行下列步骤：
1）、 寻找适当的应答上下文。
2）、 用临时应答来更新定时器C
3）、 从最上边移除Via
4）、 在应答上下文中增加应答
5）、 检查这个应答是否需要立刻发送
6）、 如果需要，从应答上下文中选择最好的终结应答。
7）、 需要合并认证头域值。
8）、 可选的重写Record-Route头域值
9）、 转发应答
10）、 产生合适的CANCEL请求。

（3）从最上边移除Via
如果在这个应答中没有这个Via头域值，那么应答的含义就是说这个应答不应当被这个proxy转发。
（4）在应答上下文中增加应答
收到的终结应答都会保存在应答的上下文中，直到收到一个由服务端事务产生的针对这个上下文的终结应答为止。这个应答是从那个服务端事务中收到最佳终结应答的一个候选。即使这个应答不会被选中作为最佳应答，这个应答的信息也需要用来构造成为最佳应答。
（5）检查这个应答是否需要立刻发送
当终结应答到达服务端事务的时候，下列应答包必须立刻转发。
－ 任何非100（trying）的临时应答
－ 任何2xx应答。
如果收到一个6xx应答，那么就不立刻进行转发，如果是有状态的proxy，那么还需要cancel所有的依赖于这个事务的客户端（在10节中描述的那样），并且不能在上下文中创建新的分支。
在服务端事务上发送了终结应答之后，下列的应答应当立刻被发送：
－ 任何给INVITE请求的2xx应答。
一个有状态的proxy必须不能立刻转发其他的应答。特别是，一个有状态的poxy必须不能转发任何100(Trying)应答。这些应答是作为后续将被转发”最佳”应答的候选，通过上边的”在上下文中增加应答”的步骤增加到应答上下文中。
（6）选择最佳的应答 （略）
（8）Record-Route
如果最终发送的应答中包含Record-Route头域值，并且是这个proxy所原创提供的值，那么在发送这个应答前，proxy可能需要重写这个值。
（9）转发应答
当”合并认证头域”和”Record-Route”步骤完成以后，proxy可以对这个应答做其他的附加处理。但是这个proxy不能增加、修改、删除消息体。并且除非另有指示，除了Via头域值之外，proxy不能删除任何头域值。
proxy必须把应答传递到跟这个应答上下文相关的服务端事务。这会导致应答发送到最上的Via头域值的地方。

6Proxy Route处理的总结
在没有本地策略的情况下，proxy对于包含Route头域的请求处理可以归结于如下的步骤：
1、proxy会检查Request-URI。如果它指向的是本proxy所负责的区域，那么proxy会用位置服务的结果来替换这个URI。否则，proxy不改变这个URI。
2、proxy会检查Route头域的最上URI。如果这个URI指向这个proxy，这个proxy从Route头域中移除（这个路由节点已经到达）。
3、proxy会转发请求到最上的Route头域值所标志的URI，或者Request-URI(如果没有Route头域)。proxy通过RFC3263的步骤来产生地址，端口，通讯协议等等用来转发请求所必须的参数。

如果在请求的路径中，没有严格路由节点，Request-URI会始终标志着请求的目的地。

7无状态的Proxy
当作为无状态的时候，proxy就是一个简单的消息转发者。很多无状态的处理步骤和有状态的时候很类似。不同的地方在下边描述。
一个无状态的proxy并没有事务的概念，或者用于描述有状态proxy行为的应答上下文。相反的是，无状态的proxy处理消息，无论是请求还是应答，都是直接从通讯层处理的。当然，无状态proxy自己也不重发这些消息。他们只是转发他们收到的任何重发的消息（他们本身并没有能力来分辩那些消息是重发的，那些消息是原始消息）。进一步说，当无状态的处理一个请求的时候，这个节点并不产生它自己的100（Trying）或者其他临时应答。