前面我们通过《阐述SIP路由机制的概念》一文,了解了关于SIP路由机制的有关定义和概念。那么接下来,对于这些抽象概念的解析,就让实例来帮助大家理解吧。接下来,我们利用两个SIP路由实例帮助大家把这些概念来融会贯通一下。
SIP路由示例1:
场景:两个UE间有两个Proxy,U1 -> P1 -> P2 -> U2,并且两个Proxy都乐意添加Record-Route头域。
消息流:
【说明】由于我们在此只关心SIP路由机制,因此下面消息中跟路由机制无关的头域都省略了。
U1发出一个INVITE请求给P1(P1是U1的外拨代理服务器):
1.INVITE sip:callee@domain.com SIP/2.0
2.Contact: sip:caller@u1.example.com
P1不负责域domain.com,消息中也没有Route头域,因此通过DNS查询得到负责该域的Proxy的地址并且把消息转发过去。这里P1在转发前就添加了一个Record-Route头域,里面有一个lr参数,说明P1是一个松散路由器,遵循RFC3261中的路由机制。
1.INVITE sip:callee@domain.com SIP/2.0
2.Contact: sip:caller@u1.example.com
3.Record-Route: <sip:p1.example.com;lr>
P2负责域domain.com,因此它通过定位服务得到callee@domain.com
对应的设备地址是callee@u2.domain.com ,在SIP路由机制中,因此用新的URI重写request-URI。消息中没有Route头域,因此它就把该消息转发给request-URI中的URI,转发前它也增加了一个Record-Route头域,并且也有lr参数。
1.INVITE sip:callee@u2.domain.com SIP/2.0
2.Contact: sip:caller@u1.example.com
3.Record-Route: <sip:p2.domain.com;lr>
4.Record-Route: <sip:p1.example.com;lr>
位于u2.domain.com的被叫收到了该INVITE消息,并且返回一个200OK响应。其中就包括了INVITE中的Record-Route头域。
1.SIP/2.0 200 OK
2.Contact: sip:callee@u2.domain.com
3.Record-Route: <sip:p2.domain.com;lr>
4.Record-Route: <sip:p1.example.com;lr>
被叫此时也就有了自己的路由集:
1.(<sip:p2.domain.com;lr>,<sip:p1.example.com;lr>)
并且它本次会话的远端目的地址设置为INVITE中Contact中的URI:caller@u1.example.com,此后被叫在该会话中的请求消息就发到这个URI。同样,被叫在200 OK响应中也携带了自己的联系地址,主叫收到该响应消息后也会把本次会话的远端目的地址设置为:callee@u2.domain.com,此后主机在该会话中的请求消息就发到这个URI。同样,主叫也有了自己的路由集,只是跟被叫的是反序的:
1.(<sip:p1.example.com;lr>,<sip:p2.domain.com;lr>)
通话完毕后,我们架设主叫先挂机,则主叫发出BYE请求:
1.BYE sip:callee@u2.domain.com SIP/2.0
2.Route: <sip:p1.example.com;lr>,<sip:p2.domain.com;lr>
可以看到,BYE的Route头域正是主机的路由集构造来的。由于p1在第一个Route中,因此BYE首先发给P1。
P1收到该消息后,发现request-URI中的URI不属于自己负责的域,而消息有Route头域,并且第一个Route头域中的URI正是自己,因此删除之,并且把消息转发给新的第一个Route头域中的URI,也就是P2:
1.BYE sip:callee@u2.domain.com SIP/2.0
2.Route: <sip:p2.domain.com;lr>
P2收到该消息后,发现request-URI中的URI不属于自己负责的域(P2负责的是domain.com,而不是u2.domain.com),第一个Route头域中的URI正是自己,因此删除之,此时已经没有Route头域了,因此就转发给了request-URI中的URI。
被叫就会收到BYE消息:
1.BYE sip:callee@u2.domain.com SIP/2.0
#P#
SIP路由示例