路由有关的SIP消息头的简单小结

一、SIP协议中定义的路由相关字段（Via、Route、Record-Route）

1. Via：当UAC发起一个SIP Request消息时，消息经过的每一跳（包含发起方）都会在SIP消息中增加一个Via字段，内容为自己的地址信息，表示此消息通过此地址发往下一跳。

为什么要增加Via字段来记录Request消息经过的地址呢？实际上这个地址信息将被作为Request消息对应的Response消息的路由，Response将根据Via字段中记录的地址逐级返回，直到回到Request的发起方。

2. Route：Route和Via字段正好相反，它被用来作为Request消息的路由。当一个Proxy Server收到一个Request消息时，会检查Route字段的第一个地址是否等于自己，如果是，它将从Route字段中删去自己的地址信息，并将消息转发到Route字段中指定的下个地址；如果Route字段为空，则转发到Request URI指定的地址。

3. Record-Route：Record-Route字段实际上用于帮助UA建立路由集Route Set，当UA发送Request时会用路由集Route Set来设置上面提到的Route字段。当一个Request消息经过Proxy Server时，如果该Proxy Server希望通知UA相关的后续Request请求消息都能通过它来转发，此时它就会在消息中添加Record-Route字段，内容为自己的地址信息。当UAS发送Resposne消息时，它将复制Request中的Record-Route字段，而UAC在Response消息中检测到Record-Route字段时，将Response返回的路由集Record Set反序，然后，用该字段的路由信息更新自己的Route Set。这样后续所有请求就可以按照之前的路径从主叫端被路由到被叫端。

1、SIP请求消息（INVITE）中的Request-URI是否可以和To中的不一样？
2、如果不一样，路由是根据哪个来设定？
先回答第二个问题：SIP消息的路由如何决定?

从Record-Route中获得信息，填入Route中，顺序相反（按stack理解，实现原路返回）。根据Contact信息，设置Request-URI。

通常UAC发出的第一个INVITE的Request-URI和To是一样的，在RFC3261中用了should。中间经过的服务器，将Request-URI修改为真正的目的地，例如呼转的情况下。Request-URI可以修改，可以和To不一致。对于session的第一个INVITE消息，没有Route字段，也就是由Request-URI指出下一跳。

路由并不是由To来确定，每个SIP消息中都包含路由关系，单从消息本身可以判断发往哪个地址，有以下几个优先顺序：
1、Route字段强制要求
2、对于请求消息：Request-URI；对于应答消息，Via，并优先maddr参数中的地址。
回头看第一个问题：在SIP消息传递过程中，中间的AS，IMS，SS，Proxy，如何对SIP消息进行处理？
它们可根据对业务的理解，对真实的目的地重新处理。在RFC3261的16.5 Determining Request Targets明确给出：
2. Update the Request-URI。
The Request-URI in the copy's start line MUST be replaced with the URI for this target. If the URI contains any parameters not allowed in a Request-URI, they MUST be removed. This is the essence of a proxy's role. This is the mechanism through which a proxy routes a request toward its destination.

只是描述还是比较抽象，下面就以RFC 3261中的两个实例来解释一下。

路由示例1：
场景：
两个UE间有两个Proxy，U1 -> P1 -> P2 -> U2，并且两个Proxy都乐意添加Record-Route头域。
消息流：
【说明】由于我们在此只关心SIP路由机制，因此下面消息中跟路由机制无关的头域都省略了。
U1发出一个INVITE请求给P1（P1是U1的外拨代理服务器）：
   INVITE sip:[email protected] SIP/2.0
   Contact: sip:[email protected]
P1不负责域domain.com，消息中也没有Route头域，因此通过 DNS查询 得到负责该域的Proxy的地址并且把消息转发过去。这里P1在转发前就添加了一个Record-Route头域，里面有一个lr参数，说明P1是一个松散路由器，遵循RFC3261中的路由机制。
   INVITE sip:[email protected] SIP/2.0
   Contact: sip:[email protected]
   Record-Route: <sip:p1.example.com;lr>
P2负责域domain.com，它通过定位服务Registor得到[email protected]对应的设备地址是[email protected]，因此用新的URI重写request-URI。消息中没有Route头域，因此它就把该消息转发给request-URI中的URI，转发前它也增加了 一个Record-Route头域，并且也有lr参数。
   INVITE sip:[email protected] SIP/2.0
   Contact: sip:[email protected]
   Record-Route: <sip:p2.domain.com;lr>
   Record-Route: <sip:p1.example.com;lr>
位于u2.domain.com的被叫收到了该INVITE消息，并且返回一个200 OK响应。其中就包括了INVITE中的Record-Route头域。
   SIP/2.0 200 OK
   Contact: sip:[email protected]
   Record-Route:
   Record-Route:
被叫此时也就有了自己的路由集：
   (,)
并且它（被叫）本次会话的远端目的地址设置为INVITE中Contact中的URI： [email protected]，此后被叫在该会话中的请求消息就发到这个URI。同样，被叫在200 OK响应中也携带了自己的联系地址Contact，主叫收到该响应消息后也会把本次会话的远端目的地址设置为： [email protected]，此后主叫在该会话中的请求消息就发到这个URI。
同样，主叫也有了自己的路由集，只是跟被叫的是反序的：
   (,)
通话完毕后，我们假设主叫先挂机，则主叫发出BYE请求：
   BYE sip:[email protected] SIP/2.0
   Route: ,
可以看到，BYE的Route头域正是主叫的路由集构造来的。
由于p1在第一个Route中，因此BYE首先发给P1。
P1收到该消息后，发现request-URI中的URI不属于自己负责的域，而消息有Route头域，并且第一个Route头域中的URI正是自己，因此删除之，并且把消息转发给新的第一个Route头域中的URI，也就是P2：
   BYE sip:[email protected] SIP/2.0
   Route:

P2收到该消息后，发现request-URI中的URI不属于自己负责的域（P2负责的是domain.com，而不是u2.domain.com）， 第一个Route头域中的URI正是自己，因此删除之，此时已经没有Route头域了，因此就转发给了request-URI中的URI。被叫就会收到BYE消息。

路由示例2：

如果说上面的示例主要关注的是路由流程，那么本示例关注的则是严格路由与松散路由的区别。
场景：
U1->P1->P2->P3->P4->U2
其中，P3是严格路由的，其余Proxy都是松散路由的，并且4个Proxy都很乐意增加Record-Route头域。
消息流：
我们直接给出了到达被叫的INVITE消息：
   INVITE sip:[email protected] SIP/2.0
   Contact: sip:[email protected]
   Record-Route:
   Record-Route:
   Record-Route:
   Record-Route:
这中间的其他消息我们就不过问了，直接看一下被叫最后发出的BYE消息大概是什么样子：
   BYE sip:[email protected] SIP/2.0
   Route:
   Route:
   Route:
   Route:
因为P4在第一个Route里，因此被叫将BYE消息发给了P4。
P4收到该消息后，发现自己不负责域u1.example.com，但是第一个Route头域中的URI正是自己，因此删除之。P4还发现新的第一个 Route头域中的URI是一个严格路由器，因此它把request-URI中的URI添加到最后一个Route的位置，并且将第一个Route“弹出” 并且覆盖原来的request-URI。然后将消息转发给当前的request-URI，也就是P3。
   BYE sip:p3.middle.com SIP/2.0
   Route:
   Route:
   Route:
P3收到该消息后，直接把消息作出如下变换并且发给P2：
   BYE sip:p2.example.com;lr SIP/2.0
   Route:
   Route:
P2收到该消息后，发现消息中的request-URI是自己的，因此在进一步处理先首先对消息做如下变换：
   BYE sip:[email protected] SIP/2.0
   Route:
然后，P2发现自己不负责域u1.example.com，第一个Route中的URI也不是自己的，因此将消息转发给该URI，也就是P1。
P1收到该消息后，发现自己不负责域u1.example.com，但是第一个Route头域中的URI正是自己，因此删除之。消息变成下面的样子：
   BYE sip:[email protected] SIP/2.0
既然Route头域已经是空，因此P1把消息发给u1.example.com。