本文通過實例講解了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#