SIP route與 record_route /SIP路由機制解析
2009-08-19 19:43
轉自：[url]http://hi.baidu.com/ferrior/blog/item/74714709613285cf3bc7633b.html[/url]
SIP路由機制解析(zz)
2007-03-06 15:46
在前面已經陸續介紹了SIP重要頭域、註冊流程、會話流程等SIP相關知識，現在再來介紹一下SIP中的路由機制。
總的來說，SIP中存在兩種路由場景：
1，請求消息的路由
2，響應消息的路由
其中，響應消息的路由非常簡單，就是完全依靠Via來完成的，具體請見我關於RFC3261中會話流程的分析。
下面我們只談SIP請求消息的路由。
首先我們要搞清楚什麼是嚴格路由和鬆散路由。
嚴格路由（Strict Routing）：
可以理解爲比較“死板”的理由機制，這種路由機制在SIP協議的前身RFC 2534中定義，其機制非常簡單。
要求接收到的消息的request-URI必須是自己的URI，然後它會把第一個Route頭域“彈”出來，並把其中的URI作爲新的request-RUI，然後把該消息路由給該URI。
鬆散路由（Louse Routing，lr）：
該路由機制較爲靈活，也是SIP路由機制的靈魂所在，在SIP根本大典RFC 3261中定義。
下面介紹一下一個鬆散路由的Proxy的路由決策過程：
1，Proxy首先會檢查消息的request-URI是不是自己屬於自己所負責的域。如果是，它就會通過定位服務將該地址“翻譯”成具體的聯繫地址並以此替換掉原來的request-URI；否則，它不會動request-URI。
2，Proxy檢查第一個Route頭域中的URI是不是自己的，如果是，則移除之。
3，前面兩項都是準備工作，下面該進行真正的路由了。如果還有Route頭域，則Proxy會把消息路由給該頭域中的URI，否則就路由給request-URI。至於如何從下一跳URI確定出IP地址，端口以及傳輸協議那是另外一回事了。
對於前面的3條規則，我們可以簡單總結爲一句話：Route的優先級高於request-URI的。
好，瞭解了兩種路由機制，我們再來了解一下Route和Record-Route。
如果說Via是爲了給一個請求消息的響應消息留後路，那麼Record-Route就是爲了給該請求消息之後的請求消息留後路。
【說明】一個SIP消息每經過一個Proxy（包括主叫），都會被加上一個Via頭域，當消息到達被叫後，Via頭域就記錄了請求消息經過的完整路徑。被叫將這些Via頭域原樣copy到響應消息中（包括各Via的參數，以及各Via的順序），然後下發給第一個Via中的URI，每個Proxy轉發響應消息前都會把第一個Via（也就是它自己添加的Via）刪除，然後將消息轉發給新的第一個Via中的URI，直到消息到達主叫。
而在一個請求消息的傳輸過程中，Proxy也可能（純粹自願，如果它希望還能接收到本次會話的後續請求消息的話）會添加一個Record-Route頭域，這樣當消息到達被叫后里面就有會有0個或若干個Record-Route頭域。被叫會將這些Record-Route頭域併入路由集，並併入自己的路由集，隨後被叫在發送請求消息時就會使用該路由集構造一系列Route頭域，以便對消息進行路由。
然後，被叫會像上面對待Via頭域一樣，將Record-Route頭域全部原樣copy到響應消息中返回給主叫。
主叫收到響應消息後也會將這些Record-Route頭域併入路由集，只是它會將其反序。該會話中的後續請求消息的Route頭域就會通過路由集構造。
【注意】Record-Route頭域不用來路由，而只是起到傳遞信息的作用。
Record-Route頭域不是路由集的唯一來源，路由集還可以通過手工配置等方式得到。
只是描述還是比較抽象，下面就以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，因此它通過定位服務得到[email][email protected][/email] 對應的設備地址是[email][email protected][/email] ，因此用新的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: <sip:p2.domain.com;lr>
Record-Route: <sip:p1.example.com;lr>
被叫此時也就有了自己的路由集：
(<sip:p2.domain.com;lr>,<sip:p1.example.com;lr>)
並且它本次會話的遠端目的地址設置爲INVITE中Contact中的URI：[email][email protected][/email]，此後被叫在該會話中的請求消息就發到這個URI。同樣，被叫在200 OK響應中也攜帶了自己的聯繫地址，主叫收到該響應消息後也會把本次會話的遠端目的地址設置爲：[email][email protected][/email]，此後主機在該會話中的請求消息就發到這個URI。
同樣，主叫也有了自己的路由集，只是跟被叫的是反序的：
(<sip:p1.example.com;lr>,<sip:p2.domain.com;lr>)
通話完畢後，我們架設主叫先掛機，則主叫發出BYE請求：
BYE sip:[email protected] SIP/2.0
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：
BYE sip:[email protected] SIP/2.0
Route: <sip:p2.domain.com;lr>
P2收到該消息後，發現request-URI中的URI不屬於自己負責的域（P2負責的是domain.com，而不是u2.domain.com），第一個Route頭域中的URI正是自己，因此刪除之，此時已經沒有Route頭域了，因此就轉發給了request-URI中的URI。
被叫就會收到BYE消息：
BYE sip:[email protected] SIP/2.0
路由示例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: <sip:p4.domain.com;lr>
Record-Route: <sip:p3.middle.com>
Record-Route: <sip:p2.example.com;lr>
Record-Route: <sip:p1.example.com;lr>
這中間的其他消息我們就不過問了，直接看一下被叫最後發出的BYE消息大概是什麼樣子：
BYE sip:[email protected] SIP/2.0
Route: <sip:p4.domain.com;lr>
Route: <sip:p3.middle.com>
Route: <sip:p2.example.com;lr>
Route: <sip:p1.example.com;lr>
因爲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: <sip:p2.example.com;lr>
Route: <sip:p1.example.com;lr>
Route: <sip:[email protected]>
P3收到該消息後，直接把消息作出如下變換並且發給P2：
BYE sip:p2.example.com;lr SIP/2.0
Route: <sip:p1.example.com;lr>
Route: <sip:[email protected]>
P2收到該消息後，發現消息中的request-URI是自己的，因此在進一步處理先首先對消息做如下變換：
BYE sip:[email protected] SIP/2.0
Route: <sip:p1.example.com;lr>
然後，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。
SIP路由機制解析(zz)
2007-03-06 15:46
在前面已經陸續介紹了SIP重要頭域、註冊流程、會話流程等SIP相關知識，現在再來介紹一下SIP中的路由機制。
總的來說，SIP中存在兩種路由場景：
1，請求消息的路由
2，響應消息的路由
其中，響應消息的路由非常簡單，就是完全依靠Via來完成的，具體請見我關於RFC3261中會話流程的分析。
下面我們只談SIP請求消息的路由。
首先我們要搞清楚什麼是嚴格路由和鬆散路由。
嚴格路由（Strict Routing）：
可以理解爲比較“死板”的理由機制，這種路由機制在SIP協議的前身RFC 2534中定義，其機制非常簡單。
要求接收到的消息的request-URI必須是自己的URI，然後它會把第一個Route頭域“彈”出來，並把其中的URI作爲新的request-RUI，然後把該消息路由給該URI。
鬆散路由（Louse Routing，lr）：
該路由機制較爲靈活，也是SIP路由機制的靈魂所在，在SIP根本大典RFC 3261中定義。
下面介紹一下一個鬆散路由的Proxy的路由決策過程：
1，Proxy首先會檢查消息的request-URI是不是自己屬於自己所負責的域。如果是，它就會通過定位服務將該地址“翻譯”成具體的聯繫地址並以此替換掉原來的request-URI；否則，它不會動request-URI。
2，Proxy檢查第一個Route頭域中的URI是不是自己的，如果是，則移除之。
3，前面兩項都是準備工作，下面該進行真正的路由了。如果還有Route頭域，則Proxy會把消息路由給該頭域中的URI，否則就路由給request-URI。至於如何從下一跳URI確定出IP地址，端口以及傳輸協議那是另外一回事了。
對於前面的3條規則，我們可以簡單總結爲一句話：Route的優先級高於request-URI的。
好，瞭解了兩種路由機制，我們再來了解一下Route和Record-Route。
如果說Via是爲了給一個請求消息的響應消息留後路，那麼Record-Route就是爲了給該請求消息之後的請求消息留後路。
【說明】一個SIP消息每經過一個Proxy（包括主叫），都會被加上一個Via頭域，當消息到達被叫後，Via頭域就記錄了請求消息經過的完整路徑。被叫將這些Via頭域原樣copy到響應消息中（包括各Via的參數，以及各Via的順序），然後下發給第一個Via中的URI，每個Proxy轉發響應消息前都會把第一個Via（也就是它自己添加的Via）刪除，然後將消息轉發給新的第一個Via中的URI，直到消息到達主叫。
而在一個請求消息的傳輸過程中，Proxy也可能（純粹自願，如果它希望還能接收到本次會話的後續請求消息的話）會添加一個Record-Route頭域，這樣當消息到達被叫后里面就有會有0個或若干個Record-Route頭域。被叫會將這些Record-Route頭域併入路由集，並併入自己的路由集，隨後被叫在發送請求消息時就會使用該路由集構造一系列Route頭域，以便對消息進行路由。
然後，被叫會像上面對待Via頭域一樣，將Record-Route頭域全部原樣copy到響應消息中返回給主叫。
主叫收到響應消息後也會將這些Record-Route頭域併入路由集，只是它會將其反序。該會話中的後續請求消息的Route頭域就會通過路由集構造。
【注意】Record-Route頭域不用來路由，而只是起到傳遞信息的作用。
Record-Route頭域不是路由集的唯一來源，路由集還可以通過手工配置等方式得到。
只是描述還是比較抽象，下面就以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，因此它通過定位服務得到[email][email protected][/email] 對應的設備地址是[email][email protected][/email] ，因此用新的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: <sip:p2.domain.com;lr>
Record-Route: <sip:p1.example.com;lr>
被叫此時也就有了自己的路由集：
(<sip:p2.domain.com;lr>,<sip:p1.example.com;lr>)
並且它本次會話的遠端目的地址設置爲INVITE中Contact中的URI：[email][email protected][/email]，此後被叫在該會話中的請求消息就發到這個URI。同樣，被叫在200 OK響應中也攜帶了自己的聯繫地址，主叫收到該響應消息後也會把本次會話的遠端目的地址設置爲：[email][email protected][/email]，此後主機在該會話中的請求消息就發到這個URI。
同樣，主叫也有了自己的路由集，只是跟被叫的是反序的：
(<sip:p1.example.com;lr>,<sip:p2.domain.com;lr>)
通話完畢後，我們架設主叫先掛機，則主叫發出BYE請求：
BYE sip:[email protected] SIP/2.0
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：
BYE sip:[email protected] SIP/2.0
Route: <sip:p2.domain.com;lr>
P2收到該消息後，發現request-URI中的URI不屬於自己負責的域（P2負責的是domain.com，而不是u2.domain.com），第一個Route頭域中的URI正是自己，因此刪除之，此時已經沒有Route頭域了，因此就轉發給了request-URI中的URI。
被叫就會收到BYE消息：
BYE sip:[email protected] SIP/2.0
路由示例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: <sip:p4.domain.com;lr>
Record-Route: <sip:p3.middle.com>
Record-Route: <sip:p2.example.com;lr>
Record-Route: <sip:p1.example.com;lr>
這中間的其他消息我們就不過問了，直接看一下被叫最後發出的BYE消息大概是什麼樣子：
BYE sip:[email protected] SIP/2.0
Route: <sip:p4.domain.com;lr>
Route: <sip:p3.middle.com>
Route: <sip:p2.example.com;lr>
Route: <sip:p1.example.com;lr>
因爲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: <sip:p2.example.com;lr>
Route: <sip:p1.example.com;lr>
Route: <sip:[email protected]>
P3收到該消息後，直接把消息作出如下變換並且發給P2：
BYE sip:p2.example.com;lr SIP/2.0
Route: <sip:p1.example.com;lr>
Route: <sip:[email protected]>
P2收到該消息後，發現消息中的request-URI是自己的，因此在進一步處理先首先對消息做如下變換：
BYE sip:[email protected] SIP/2.0
Route: <sip:p1.example.com;lr>
然後，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。