SIP網(wǎng)絡(luò)環(huán)境中，特別是涉及了多個(gè)應(yīng)用節(jié)點(diǎn)或多個(gè)網(wǎng)絡(luò)要素環(huán)境的SIP呼叫中，因?yàn)樯婕暗木W(wǎng)絡(luò)節(jié)點(diǎn)比較復(fù)雜，所以SIP路由所涉及的路徑就比較多，例如注冊(cè)服務(wù)，定位服務(wù)等，另外，因?yàn)槟壳暗腟IP網(wǎng)絡(luò)環(huán)境中，很多SIP呼叫業(yè)務(wù)又涉及了SBC，使用SBC作為一個(gè)SIP安全的保護(hù)機(jī)制，因此，在SIP路由或呼叫中增加了SBC處理的場(chǎng)景。因此，很多SIP網(wǎng)絡(luò)用戶就對(duì)這些相關(guān)的問(wèn)題感到非常困惑。今天，筆者針對(duì)SBC和SIP路由以及所涉及的相關(guān)業(yè)務(wù)問(wèn)題進(jìn)行淺析和說(shuō)明，希望讀者能夠?qū)�SBC，SIP路由以及路由策略有一個(gè)大概的理解。

　　筆者首先說(shuō)明，因?yàn)槠�幅有限，筆者很難在比較短的篇幅涵蓋所有細(xì)節(jié)。另外，很多基本概念在以前的歷史文檔中也早已有完整深入的介紹，所以，筆者在這里可能簡(jiǎn)單重復(fù)介紹一些基本的概念，或者不再介紹一些基本的概念，讀者可以查閱歷史文檔學(xué)習(xí)或者補(bǔ)充相關(guān)知識(shí)。最后，因?yàn)樯婕暗骄唧w的業(yè)務(wù)應(yīng)用，筆者只能比較寬泛地討論一些經(jīng)常使用的或者相對(duì)規(guī)范的應(yīng)用場(chǎng)景，特別具體場(chǎng)景這里不再做更多討論。

　　針對(duì)本文章所需要涉及到的內(nèi)容，筆者首先討論一些基本的針對(duì)SIP路由的相關(guān)的概念和處理流程，另外因?yàn)镾IP業(yè)務(wù)服務(wù)器可能需要經(jīng)過(guò)SBC的調(diào)度處理，筆者將針對(duì)SIP路由經(jīng)過(guò)SBC以后的一些流程進(jìn)行討論。

　　在SIP技術(shù)中，非常重要的一個(gè)概念就是注冊(cè)（Registrar）。注冊(cè)本身就是一種服務(wù)的處理流程，他一般是一個(gè)數(shù)據(jù)庫(kù)存儲(chǔ)Registrar地址，終端用戶通過(guò)地址查找來(lái)實(shí)現(xiàn)其可達(dá)性的狀態(tài)查詢。如何發(fā)現(xiàn)注冊(cè)地址，讀者可以參考RFC10.2.6的規(guī)范細(xì)節(jié)。筆者也發(fā)布過(guò)歷史文檔，此文檔中比較詳細(xì)說(shuō)明了注冊(cè)和定位的處理流程，讀者可以參考此文檔做進(jìn)一步學(xué)習(xí)：

　　深入理解SIP服務(wù)器的注冊(cè)和定位服務(wù)流程

　　在實(shí)際SIP網(wǎng)絡(luò)或者IP網(wǎng)絡(luò)的應(yīng)用場(chǎng)景中，特別是現(xiàn)在的移動(dòng)端的使用中，IP地址可能會(huì)經(jīng)常發(fā)生變化，而且一個(gè)SIP終端賬號(hào)有幾種表現(xiàn)形式（一個(gè)分機(jī)同時(shí)有物理終端，PC端分機(jī)或者APP分機(jī)）。這些IP地址一般又是臨時(shí)地址，這樣的話，服務(wù)器端對(duì)終端狀態(tài)的管理存在很多挑戰(zhàn)。因此，在SIP應(yīng)用場(chǎng)景中，SIP協(xié)議使用了一個(gè)永久地址來(lái)匹配一個(gè)SIP賬號(hào)信息，這個(gè)地址就是AOR地址（address of record）。這里，筆者提醒讀者，在一般的企業(yè)通信或者IPPBX的討論中，我們經(jīng)常使用的是SIP分機(jī)的說(shuō)法。那種說(shuō)法或者稱謂僅在一個(gè)比較小型的內(nèi)網(wǎng)環(huán)境的說(shuō)法，我們有時(shí)為了簡(jiǎn)單方便也使用這樣的稱謂，但是SIP呼叫流程決不僅僅是一個(gè)分機(jī)的概念，希望一些初級(jí)用戶不要對(duì)這些概念迷惑。進(jìn)一步講，即使是一個(gè)IPPBX表示也集成了以下示例的所有功能模塊，在邏輯上都是獨(dú)立的，僅表現(xiàn)為一個(gè)一體服務(wù)器形式而已。如果是大型的服務(wù)器或者其他分布式部署的服務(wù)器，這些服務(wù)器端都各自有自己表示的邏輯功能，包括圖例中使用的注冊(cè)服務(wù)器，定位服務(wù)器，路由服務(wù)器和域名解析等等。

此圖片和以下圖片資源均來(lái)自于互聯(lián)網(wǎng)資源

　　另外，在實(shí)際應(yīng)用環(huán)境中，我們還有一個(gè)contact地址。這兩個(gè)基本的地址就可以綁定大部分的呼叫業(yè)務(wù)流程。針對(duì)這兩個(gè)容易混淆的地址，讀者可以簡(jiǎn)單理解為：AOR是告知服務(wù)器端SIP終端是誰(shuí)（唯一的），Contact告訴服務(wù)器SIP終端此時(shí)此刻在哪里(綁定多個(gè)contacts)。呼叫SIP終端時(shí)，應(yīng)該首先檢查AOR地址，然后逐一檢查contact地址狀態(tài)，最后呼叫到有效contact地址。

　　在以上圖例中，兩個(gè)SIP終端注冊(cè)都分別經(jīng)過(guò)了4個(gè)處理流程（M1/M2，M3/M4）。

　　在以上討論中，除了進(jìn)行注冊(cè)以外，SIP終端雙方如果需要呼叫對(duì)方的話，仍然需要借助于第三方的其他服務(wù)功能實(shí)現(xiàn)路由等處理流程。Proxy或者代理服務(wù)器就是其中一個(gè)必要的邏輯實(shí)體。一般來(lái)說(shuō)，代理服務(wù)器負(fù)責(zé)處理域名檢查，然后做相應(yīng)的路由處理轉(zhuǎn)發(fā)。代理服務(wù)器首先必須檢查請(qǐng)求中的SIP Request-URI，因?yàn)榇藚��?shù)中可能包含必要的路由的頭域參數(shù)，例如Route/Route-Record，代理服務(wù)器根據(jù)這些路由頭進(jìn)行下一步的路由轉(zhuǎn)發(fā)處理。當(dāng)我們討論proxy時(shí)，另外一個(gè)比較重要的概念就是B2BUA，如果讀者對(duì)Proxy或者B2BUA迷惑的話，可以參考筆者歷史文檔：

　　B2BUA/SBC/Proxy的SIP消息重構(gòu)和RFC7092詳解

　　筆者這里不再做更多重復(fù)介紹，請(qǐng)讀者仔細(xì)閱讀以上鏈接文檔。代理服務(wù)器獲得了Route頭以后，它就會(huì)根據(jù)代理服務(wù)器的列表強(qiáng)制執(zhí)行這些路由轉(zhuǎn)發(fā)處理。Route-Record則是被proxy記錄在請(qǐng)求中并且強(qiáng)制將來(lái)的請(qǐng)求通過(guò)此代理服務(wù)器。當(dāng)然，這些通過(guò)代理服務(wù)器的路由還要結(jié)合本地的策略處理，這些策略處理很大程度上會(huì)影響這些記錄值。以上圖例是一個(gè)非常典型的也是一個(gè)基本的SIP呼叫拓?fù)涫纠龍D。在SIP終端呼叫過(guò)程中，雙方經(jīng)過(guò)了（P1，P3，P2，流程為U1 -> P1 -> P3->P2 -> U2和其相反流程）三個(gè)代理服務(wù)器的處理�，F(xiàn)在，我們根據(jù)以上處理流程來(lái)分析一下代理的record-routing細(xì)節(jié)。

　　首先，UA1呼叫了一個(gè)P1外呼的代理服務(wù)器，其請(qǐng)求如下（M5）：

　　INVITE sip：callee@office.com SIP/2.0

　　Contact： sip：caller@u1.example.com

　　這里，P1代理服務(wù)器沒(méi)有對(duì)office.com 負(fù)責(zé)處理，它沒(méi)有P1代理服務(wù)器和此域名沒(méi)有任何綁定關(guān)系，因此，它交給domin解析服務(wù)器進(jìn)行解析查詢，然后把消息繼續(xù)路由到P3，并且增加了一個(gè)Route-Record，表示通過(guò)了P1代理服務(wù)器。這里，contact地址發(fā)送了變化，并且增加了一個(gè)路由記錄。

　　INVITE sip：callee@office.com SIP/2.0

　　Contact： sip：caller@u1.example.com

　　Record-Route：

　　P3收到以上路由的請(qǐng)求以后，仍然沒(méi)有查詢到相應(yīng)的office.com地址，它繼續(xù)向下一個(gè)代理進(jìn)行轉(zhuǎn)發(fā)路由，轉(zhuǎn)發(fā)到P2代理服務(wù)器。Record-Route： 在這里的最頂部記錄中（M7）。

　　INVITE sip：callee@office.com SIP/2.0

　　Contact： sip：caller@u1.example.com

　　Record-Route： // 注意，最新代理記錄總是在最頂部

　　Record-Route：

　　在P2收到P3路由過(guò)來(lái)的請(qǐng)求以后，P2檢查定位服務(wù)器，對(duì)其身份進(jìn)行查詢定位。它發(fā)現(xiàn)了這個(gè)domain office.com 以后，P2代理服務(wù)器執(zhí)行了兩個(gè)任務(wù)，首先重寫了Request-URI值，另外，它增加了一個(gè)最新的Record-Route值，記錄了office.com domain（M8）。到此為止，SIP終端雙方的呼叫明確了呼叫的最終目的地地址。

　　INVITE sip：callee@u2.office.com SIP/2.0 // 重寫了請(qǐng)求URL

　　Contact： sip：caller@u1.example.com

　　Record-Route： // 在頂部增加了最新Record-Route

　　Record-Route：

　　Record-Route：

　　這里讀者一定要注意，因?yàn)镽oute 頭，代理服務(wù)器可以使用請(qǐng)求的URL（Request-URI）來(lái)決定最終的呼叫用戶地址，因此，代理服務(wù)器使用地址u2.office.com對(duì)被呼叫方callee進(jìn)行呼叫。U2被呼叫后，返回一個(gè)響應(yīng)消息（M9）流程。因?yàn)槠�幅所限，其他呼叫掛機(jī)和發(fā)送BYE消息或者ACK的流程這里不再做太多討論，筆者可參考?xì)v史文檔學(xué)習(xí)。

　　在前面的討論中，兩個(gè)SIP終端分別發(fā)布在不同的網(wǎng)絡(luò)空間（leftspace和rightspace），這兩個(gè)SIP終端之間的呼叫需要借助于proxy（P1）來(lái)重寫Record-Route完成（U1->P1->U2）。P1相當(dāng)于一個(gè)網(wǎng)關(guān)來(lái)實(shí)現(xiàn)SIP終端之間的呼叫路由處理。U1發(fā)送的請(qǐng)求：

　　INVITE sip：callee@gateway.leftprivatespace.

　　com SIP/2.0

　　Contact：

　　P1然后通過(guò)定位服務(wù)，查詢domain地址，對(duì)U2發(fā)送請(qǐng)求消息：

　　INVITE sip：callee@rightprivatespace.com

　　SIP/2.0

　　Contact：

　　Record-Route：

　　com；lr>

　　然后U2對(duì)P1發(fā)送 200 OK：

　　SIP/2.0 200 OK

　　Contact：

　　Record-Route：

　　com；lr>

　　P1然后重寫其Record-Route地址，支持U1所需要的地址參數(shù)，發(fā)送到U1：

　　SIP/2.0 200 OK

　　Contact：

　　com>

　　Record-Route：

　　com；lr>

　　如果U1稍晚對(duì)U2發(fā)送BYE請(qǐng)求時(shí)，首先發(fā)送到P1：

　　BYE sip：callee@u2.rightprivatespace.com

　　SIP/2.0

　　Route：

　　然后P1返回到U2：

　　BYE sip：callee@u2.rightprivatespace.com

　　SIP/2.0

　　以上是一個(gè)簡(jiǎn)單的針對(duì)不同網(wǎng)絡(luò)空間，兩個(gè)SIP終端通過(guò)proxy進(jìn)行的一個(gè)關(guān)于Record-Route重寫的處理流程。在實(shí)際使用過(guò)程中，讀者可能會(huì)有遇到VIA的處理，關(guān)于VIA和Record-Route處理，建議讀者閱讀筆者的歷史文檔：

　　SIP系列講座-關(guān)于VIA和Record-Route header

　　這里需要特別注意，在關(guān)于Record-Route時(shí)，如果網(wǎng)絡(luò)環(huán)境在多宿主機(jī)環(huán)境或者傳輸協(xié)議需要切換或者IPv4-IPv6的環(huán)境中，這種處理方式不是一個(gè)處理Record-Route記錄的最佳辦法。大部分情況下，通過(guò)Proxy以后，IP地址的匹配是沒(méi)有什么問(wèn)題的，但是，有時(shí)Proxy需要一定的策略修改，修改時(shí)就會(huì)生成問(wèn)題。

UA多網(wǎng)口地址處理

IPv4到IPv6轉(zhuǎn)換

TCP到UDP轉(zhuǎn)換

　　這樣處理的結(jié)果可能是，呼叫方看到的route set和被呼叫方看到的route set是不同的，并且還有可能帶來(lái)其他的影響。關(guān)于針對(duì)重寫Record-Route所引起的爭(zhēng)議問(wèn)題讀者可以查閱RFC5658。針對(duì)重寫Record-Route引起的問(wèn)題，RFC5658規(guī)范推薦使用Double Record-Routing來(lái)解決以上這些問(wèn)題。以下示例圖例描述了在多宿主網(wǎng)絡(luò)和傳輸協(xié)議切換時(shí)使用Double Record-Routing的解決方案：

　　根據(jù)以上圖例的流程，首先，呼叫方對(duì)P1發(fā)出一個(gè)INVITE呼叫。這里的P1帶有兩個(gè)IP地址，一個(gè)是IPv4地址和另外一個(gè)IPv6地址。

　　INVITE sip：joe@howell.network.com SIP/2.0

　　Route： // P1的IPv4地址

　　From： Joe ；tag=1234

　　To： Ken

　　Contact：

　　然后，P1收到呼叫請(qǐng)求以后，通過(guò)修改Route-Record地址，增加另外一個(gè)IPv6的地址繼續(xù)進(jìn)行路由轉(zhuǎn)發(fā)。P1然后通過(guò)IPv6地址對(duì)U2繼續(xù)進(jìn)行呼叫（兩個(gè)Route-Record）：

　　INVITE sip： joe@howell.network.com SIP/2.0

　　Record-Route：   // P1的ipv6地址

　　Record-Route： // P1的IPv4地址

　　From： Joe

　　com>；tag=1234

　　To： Ken

　　Contact：

　　在U2客戶端的狀態(tài)消息中，最終被呼叫方看到的是這樣的結(jié)果：

　　Local URI = sip：ken@atlanta.network.com

　　Remote URI = sip：joe@howell.network.com

　　Remote target = sip：joe@192.0.2.1

　　Route Set = sip：[2001：db8：：1]；lr // 通過(guò)P1的 路由set

　　sip：192.0.2.254：5060：lr

　　然后，U2就知道，它可以通過(guò)路由set中的IPv6地址發(fā)送此地址一個(gè)200 OK。

　　SIP/2.0 200 OK

　　Record-Route：

　　Record-Route：

　　From： Joe

　　com>；tag=1234

　　To： Ken

　　com>；tag=4567

　　Contact：

　　P1收到此200 OK以后，繼續(xù)返回給U1一個(gè)200 OK：

　　SIP/2.0 200 OK

　　Record-Route：

　　Record-Route：

　　From： Joe

　　com>；tag=1234

　　To： Ken

　　Contact：

　　這時(shí)，在U1端看到的dialog狀態(tài)中的Route-Record地址是：

　　Local URI = sip：joe@howell.network.com

　　Remote URI = sip：ken@atlanta.network.com

　　Remote target = sip：ken@[2001：db8：：33]

　　Route Set = sip：192.0.2.254：5060：lr

　　sip：[2001：db8：：1]；lr

　　通過(guò)雙Route-Record記錄以后，雙方看到的最終結(jié)果是一致的。通過(guò)double Route-Record就實(shí)現(xiàn)了雙方地址的統(tǒng)一，也不會(huì)產(chǎn)生地址不一致的錯(cuò)誤。其他處理流程和呼叫請(qǐng)求的處理方式是相同的，這里不再累述。

　　4、傳輸協(xié)議切換引起的Record-Route重寫

　　在前面的討論中，我們也簡(jiǎn)單涉及了如果傳輸協(xié)議切換可能導(dǎo)致的Record-Route重寫問(wèn)題。在本章節(jié)，我們重點(diǎn)詳解關(guān)于TCP環(huán)境和UDP環(huán)境下的Record-Route修改問(wèn)題。這里，U1使用的是TCP傳輸，U2則使用的是UDP傳輸，proxy P1作為一個(gè)協(xié)議轉(zhuǎn)換網(wǎng)關(guān)進(jìn)行它們之間的通信轉(zhuǎn)發(fā)處理。

　　以上圖例中，我們可以看到，一般情況下，U1使用TCP發(fā)送到P1，然后P1經(jīng)過(guò)傳輸協(xié)議轉(zhuǎn)換以后，通過(guò)UDP把U1的呼叫請(qǐng)求發(fā)送到U2。這里的使用場(chǎng)景是一個(gè)比較簡(jiǎn)單化的場(chǎng)景，在這種比較簡(jiǎn)單化的場(chǎng)景中，如果沒(méi)有涉及傳輸協(xié)議其他參數(shù)的使用的話，這種場(chǎng)景可能可以正常工作。但是，如果有大量的類似U1的SIP終端通過(guò)P1時(shí)，并且因?yàn)椴煌�的需求，TCP傳輸要求支持其他參數(shù)支持時(shí)，或者在U2 端的UDP需要增加參數(shù)支持時(shí)，這樣的簡(jiǎn)單場(chǎng)景就不能適應(yīng)傳輸協(xié)議的支持。U1通過(guò)TCP發(fā)送呼叫請(qǐng)求到P1的消息示例：

　　INVITE sip：ken@atlanta.network.com SIP/2.0

　　Route：

　　From： Joe

　　com>；tag=1234

　　To： Ken

　　Contact：

　　com；transport=tcp>

　　P1收到請(qǐng)求以后，然后通過(guò)UDP對(duì)U1發(fā)送到呼叫請(qǐng)求：

　　INVITE sip： ken@atlanta.network.

　　com；transport=udp SIP/2.0

　　Record-Route： (注意，這里沒(méi)有使用任何傳輸協(xié)議參數(shù)）

　　From： Joe

　　com>；tag=1234

　　To： Ken

　　Contact： < sip：joe@u1.howell.network.com；transport=tcp>

　　但是，在實(shí)際生產(chǎn)環(huán)境中，一些代理服務(wù)器存在一些兼容性問(wèn)題，或者不能支持要求的傳輸，也可能某些代理強(qiáng)制使用TCP來(lái)避免UDP擁塞，這就會(huì)導(dǎo)致傳輸協(xié)議切換時(shí)Record-Route存在無(wú)效解析問(wèn)題。因此，使用double Record-Route增加一些兼容性支持仍然是解決這些問(wèn)題的比較好的辦法。

　　Record-Route：

　　com；transport=udp>

　　Record-Route：

　　com；transport=sctp>. // 增加對(duì)sctp支持

　　另外，除了我們討論的這種簡(jiǎn)單場(chǎng)景中關(guān)于傳輸協(xié)議的切換以外，很多SIP網(wǎng)絡(luò)環(huán)境中涉及了NAT問(wèn)題。在NAT處理中，傳輸協(xié)議也需要增加相應(yīng)的傳輸參數(shù)，這就要求Record-Route做相應(yīng)的修改和Via修改，包括端口修改等參數(shù)設(shè)置。

　　5、SBC環(huán)境中關(guān)于撥號(hào)和路由SIP呼叫/ACK處理

　　以上介紹了關(guān)于SIP路由中經(jīng)過(guò)比較重要的概念和相關(guān)補(bǔ)充說(shuō)明。接下來(lái)我們針對(duì)具體的SIP服務(wù)器的業(yè)務(wù)系統(tǒng)-SBC呼叫進(jìn)行討論。根據(jù)RFC3261的規(guī)范說(shuō)明，SIP服務(wù)器端收到SIP終端的呼叫請(qǐng)求以后，可以根據(jù)其服務(wù)器端定義的呼叫路由規(guī)則來(lái)針對(duì)呼叫請(qǐng)求進(jìn)行路由處理。具體的處理規(guī)則可以是：

• 是否對(duì)此呼叫請(qǐng)求執(zhí)行代理或者重定位轉(zhuǎn)發(fā)處理
• 可以轉(zhuǎn)發(fā)到每個(gè)URL地址
• 是否可以執(zhí)行分叉呼叫
• 是否執(zhí)行遞歸查詢
• 是否執(zhí)行并行處理或者按續(xù)查詢處理

　　以上是SIP服務(wù)器端根據(jù)其各種決定因素對(duì)呼叫請(qǐng)求進(jìn)行路由的幾個(gè)規(guī)則。但是，在實(shí)際的業(yè)務(wù)處理過(guò)程中，特別是SIP網(wǎng)絡(luò)邊界控制器的呼叫處理中還有更多具體的呼叫路由策略。此部分內(nèi)容和后續(xù)章節(jié)都將基于SBC的功能對(duì)SIP呼叫進(jìn)行討論。再次說(shuō)明，如果讀者對(duì)SBC或者會(huì)話邊界控制器不是非常了解的話，讀者可閱讀筆者歷史文檔關(guān)于SBC和業(yè)務(wù)功能的具體詳解說(shuō)明，這里不再過(guò)多強(qiáng)調(diào)其具體概念和場(chǎng)景說(shuō)明：

• 邊界會(huì)話控制器-SBC部署協(xié)議-RFC5853
• 圖解邊界會(huì)話控制器（SBC）的20個(gè)最常用功能
• SBC十大使用場(chǎng)景-如何實(shí)現(xiàn)SIP-SBC冗余解決方案
• 必知的十大會(huì)話邊界控制器-SBC經(jīng)典使用場(chǎng)景
• 圖解會(huì)話邊界控制器（SBC）十八個(gè)必知高級(jí)功能
• 如何搭建一個(gè)完整免費(fèi)的邊界會(huì)話控制器(SBC)測(cè)試場(chǎng)景
• SIP系列講座-邊界會(huì)話控制器-SBC全面剖析

　　呼叫任何電話或者SIP終端都需要首先通過(guò)撥號(hào)盤輸入電話號(hào)碼，號(hào)碼規(guī)范和位數(shù)需要遵從ITU-T E.164，最大支持15位數(shù)號(hào)碼。

　　在SIP呼叫請(qǐng)求發(fā)起以后攜帶兩個(gè)頭消息參數(shù)（To和Request-URI）來(lái)確認(rèn)呼叫目的地。一種方式是通過(guò)SIP URL/SIPS URL，另外一種是通過(guò)Tel URL的方式來(lái)標(biāo)識(shí)呼叫目的地號(hào)碼。

　　如果終端用戶通過(guò)IP網(wǎng)絡(luò)進(jìn)行呼叫時(shí)，雙方終端至少需要兩個(gè)不同的企業(yè)通信實(shí)體系統(tǒng)。在各自的企業(yè)通信平臺(tái)的邊界處，企業(yè)通信系統(tǒng)支持了SBC來(lái)實(shí)現(xiàn)SIP網(wǎng)絡(luò)的安全控制。根據(jù)筆者前面章節(jié)的描述，在SIP呼叫路由過(guò)程中，Via和Record-Route都需要按照呼叫路由規(guī)則進(jìn)行處理。

　　在請(qǐng)求路由過(guò)程中支持了strict routing（嚴(yán)格路由）和 loose routing（松散路由）兩種路由方式。strict routing由RFC2543定義，而loose routing 則由RFC3261定義。嚴(yán)格路由使用Request-URI作為下一跳的URL，而松散路由除了使用Request-URI作為目的地URL以外，代理服務(wù)器將使用最頂部的Route header作為下一跳的目的地地址。這兩種請(qǐng)求路由的區(qū)別會(huì)引起路由頭的處理不同，因此，如果經(jīng)過(guò)多個(gè)代理服務(wù)器時(shí)，它們分別支持不同的路由方式，讀者排查問(wèn)題時(shí)需要特別注意這些差別。

　　除了在請(qǐng)求呼叫中使用Record-Route，在不同的代理服務(wù)器或者SBC增加路由記錄以外，這個(gè)Record-Route也會(huì)影響ACK的處理流程，同時(shí)可能影響SBC的處理：

　　所有ACK請(qǐng)求流程中都使用了Record-Route。

　　所有ACK請(qǐng)求流程中，其中一個(gè)代理服務(wù)器沒(méi)有插入Record-Route

　　雙方終端直接通過(guò)SBC進(jìn)行通信。U1通過(guò)業(yè)務(wù)服務(wù)器，SBC呼叫對(duì)端SBC，業(yè)務(wù)服務(wù)器和U2終端。

　　6、SBC環(huán)境中呼叫路由類型討論

　　當(dāng)SIP呼叫INVITE進(jìn)入到SBC以后，SBC可以根據(jù)不同的呼叫路由類型做不同的呼叫路由。具體的呼叫路由類型包括：

　　DID匹配系統(tǒng)內(nèi)部分機(jī)或者其他終端，例如，通過(guò)Request-URI的號(hào)碼9865556003路由到系統(tǒng)分機(jī) (56003）。當(dāng)然，此目的地路由還可以是其他SIP 終端，SBC或者SIP trunk，甚至于TDM 接口。

　　基于URL或者domain或者email格式的呼叫，一般情況下，這種路由根據(jù)SIP的domain做其他基于消息的路由切換。

　　基于呼叫源目的地的路由。此路由模式根據(jù)呼叫發(fā)起方的地址做呼叫路由。這樣可以保證呼叫方能夠正確路由到相關(guān)的目的地分機(jī)，例如呼叫中心的一些VIP服務(wù)呼叫。

　　基于中繼組的呼叫路由。這種情況通常是SBC可以同時(shí)支持TDM trunk和SIP trunk時(shí)SBC設(shè)置的路由組策略。在某些特定的需求或者使用場(chǎng)景中，SBC可能使用TDM/PSTN作為一個(gè)備用線路或者在本地落地，因此呼叫進(jìn)入到SBC以后就需要做相應(yīng)的呼叫分類管理。

　　基于運(yùn)營(yíng)商的呼叫路由。這種路由更多適用于當(dāng)運(yùn)營(yíng)商提供了某些呼叫服務(wù)，例如toll-free號(hào)碼或者運(yùn)營(yíng)商的其他服務(wù)號(hào)碼。SBC需要根據(jù)其運(yùn)營(yíng)商的號(hào)碼特性做相應(yīng)的呼叫路由。RFC4694對(duì)其Tel URL號(hào)碼有完整的規(guī)范說(shuō)明，如果運(yùn)營(yíng)商的服務(wù)遵從其規(guī)范的話，可能某些地區(qū)有一些免費(fèi)的服務(wù)，SBC可通過(guò)這些免費(fèi)的數(shù)據(jù)服務(wù)來(lái)查詢更多的綁定業(yè)務(wù)。

　　除了以上幾種比較常見的呼叫路由服務(wù)以外，不同的SBC廠家針對(duì)呼叫路由還有很多不同的處理方式，包括一些非常靈活的自定義腳本的處理方式支持大并發(fā)部署中的各種路由管理。這種方式可以滿足以上路由處理以外，同時(shí)可以根據(jù)路由腳本實(shí)現(xiàn)更加強(qiáng)大的路由策略。具體的實(shí)現(xiàn)方式包括動(dòng)態(tài)路由，靜態(tài)路由，標(biāo)識(shí)路由和第三方簽權(quán)認(rèn)證路由方式。通過(guò)腳本路由的方式，可以實(shí)現(xiàn)針對(duì)某些特定SIP頭或者URL進(jìn)行修改，可以增加黑白名單管理，可以實(shí)現(xiàn)負(fù)載均衡等非常常見的SBC呼入管理策略。

　　www.freesbc.cn SBC/SIP INVITE 腳本路由策略

　　7、SBC環(huán)境中的下一跳處理機(jī)制

　　SBC對(duì)SIP呼叫請(qǐng)求進(jìn)行了路由處理以后，需要針對(duì)下一個(gè)hop做處理來(lái)決定下一跳的狀態(tài)和有效性。SBC可以使用以下幾個(gè)參數(shù)來(lái)決定下一跳處理：

　　IP地址，支持下一跳的IP地址，這里的IP地址可以是IPv4或者IPv6地址，傳輸方式可以是TCP，UDP或者TLS。

　　主機(jī)名稱，支持下一跳以主機(jī)名稱的格式出現(xiàn)，避免如果下一跳使用IP地址，地址發(fā)送變動(dòng)后出現(xiàn)的連接問(wèn)題。SBC將會(huì)使用DNS來(lái)對(duì)主機(jī)名稱進(jìn)行支持。

　　服務(wù)domain/服務(wù)器組， SBC可以通過(guò)DNS SRV對(duì)IP地址，協(xié)議，端口，傳輸方式進(jìn)行組合實(shí)現(xiàn)對(duì)下一跳的支持。因?yàn)�，一些SBC不僅僅支持SIP協(xié)議，也可能同時(shí)支持H323協(xié)議，協(xié)議可以利用不同的端口組合和地址組合實(shí)現(xiàn)對(duì)下一跳的支持，例如以下組合方式：

• SIP+D2U—SIP over UDP
• SIP+D2T—SIP over TCP
• SIP+D2S—SIP over Stream Control Transmission Protocol (SCTP)
• SIPS+D2T—Secure SIP over Transport Layer Security (TLS)
• SIPS+D2S—Secure SIP over SCTP

　　除了通過(guò)各種組合形式對(duì)下一跳支持以外，SBC必須有能力檢測(cè)到下一跳的有效性狀態(tài)。SBC不斷對(duì)對(duì)端發(fā)送option消息來(lái)檢查其有效性。如果發(fā)生故障時(shí)，需要SIP重傳的話，根據(jù)定時(shí)器的設(shè)置對(duì)對(duì)端進(jìn)行重傳。以下是一個(gè)通過(guò)UDP重傳的處理流程：

　　一般SBC可以使用兩種方式對(duì)下一跳進(jìn)行整體檢測(cè)。比較典型的下一跳的檢測(cè)方式是通過(guò)SBC發(fā)送option消息，執(zhí)行ping 命令。另外一種就是使用ICMP方式進(jìn)行檢測(cè)。很多時(shí)候，ICMP的方式可能被過(guò)濾，因此，大部分情況下，一般建議還是使用SIP option的方式來(lái)發(fā)送檢測(cè)消息。通過(guò)SBC，準(zhǔn)確性地對(duì)下一跳發(fā)送檢測(cè)消息來(lái)驗(yàn)證其活動(dòng)狀態(tài)。當(dāng)然，有的服務(wù)器為了減少數(shù)據(jù)交互，可能關(guān)閉其option檢測(cè)。

　　8、SBC環(huán)境中的呼叫跟蹤

　　除了以上關(guān)于下一跳的討論以為，在SIP網(wǎng)絡(luò)環(huán)境中，我們經(jīng)常會(huì)需要排查一些端對(duì)端的呼叫，跟蹤各種呼叫流程。因?yàn)樯婕傲颂�多的呼叫路徑和必要的參�?shù)設(shè)置支持，并且涉及了不同的撥號(hào)規(guī)則路由規(guī)則和號(hào)碼變換等問(wèn)題，筆者不能完全介紹這些手段和工具，讀者只能根據(jù)具體的環(huán)境進(jìn)行排查。比較欣慰的是，一些SBC廠家的產(chǎn)品本身帶了一些呼叫測(cè)試的工具，因?yàn)镾BC是一個(gè)B2BUA，因此，SBC測(cè)試工具可以測(cè)試外網(wǎng)終端，也可以測(cè)試內(nèi)網(wǎng)IPPBX服務(wù)器端。

　　通過(guò)SBC生成對(duì)外呼叫測(cè)試（freesbc）

　　9、總結(jié)

　　在以上的內(nèi)容討論中，筆者首先介紹了關(guān)于SIP呼叫中所需要了解到基本概念做了一些分享，同時(shí)結(jié)合歷史文檔，幫助讀者能夠全面掌握SIP呼叫過(guò)程中的基本的流程。然后，筆者主要針對(duì)SIP呼叫路徑中不同的代理服務(wù)器之間通信和一些頭消息的處理。最后，筆者結(jié)合目前使用比較普遍的SBC和SIP企業(yè)通信服務(wù)器之間的處理，重點(diǎn)介紹了關(guān)于SBC路由時(shí)的一些影響要素和相關(guān)的問(wèn)題。

　　需要說(shuō)明的是，以為篇幅關(guān)系，以及SBC和SIP服務(wù)器之間的業(yè)務(wù)復(fù)雜度的關(guān)系，很多功能包括路由功能，一些業(yè)務(wù)媒體服務(wù)器也可以實(shí)現(xiàn)SBC所具備的一些功能，因此，筆者沒(méi)有花費(fèi)太多時(shí)間做過(guò)多介紹。

　　參考資料：

　　https://www.rfc-editor.org/rfc/rfc5658

　　https://www.rfc-editor.org/rfc/rfc4694

　　www.asterisk.org.cn

　　www.freesbc.cn

　　https://docs.telcobridges.com/tbwiki/Toolpack：Tsbc_Call_Routes_Settings_3.1