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

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

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

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

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

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

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

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

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

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

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

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

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

　　INVITE sip：callee@office.com SIP/2.0

　　Contact： sip：caller@u1.example.com

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

　　INVITE sip：callee@office.com SIP/2.0

　　Contact： sip：caller@u1.example.com

　　Record-Route：

　　P3收到以上路由的請求以后，仍然沒有查詢到相應(yīng)的office.com地址，它繼續(xù)向下一個代理進行轉(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路由過來的請求以后，P2檢查定位服務(wù)器，對其身份進行查詢定位。它發(fā)現(xiàn)了這個domain office.com 以后，P2代理服務(wù)器執(zhí)行了兩個任務(wù)，首先重寫了Request-URI值，另外，它增加了一個最新的Record-Route值，記錄了office.com domain（M8）。到此為止，SIP終端雙方的呼叫明確了呼叫的最終目的地地址。

　　INVITE sip：callee@u2.office.com SIP/2.0 // 重寫了請求URL

　　Contact： sip：caller@u1.example.com

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

　　Record-Route：

　　Record-Route：

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

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

　　INVITE sip：callee@gateway.leftprivatespace.

　　com SIP/2.0

　　Contact：

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

　　INVITE sip：callee@rightprivatespace.com

　　SIP/2.0

　　Contact：

　　Record-Route：

　　com；lr>

　　然后U2對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稍晚對U2發(fā)送BYE請求時，首先發(fā)送到P1：

　　BYE sip：callee@u2.rightprivatespace.com

　　SIP/2.0

　　Route：

　　然后P1返回到U2：

　　BYE sip：callee@u2.rightprivatespace.com

　　SIP/2.0

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

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

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

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

IPv4到IPv6轉(zhuǎn)換

TCP到UDP轉(zhuǎn)換

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

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

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

　　Route： // P1的IPv4地址

　　From： Joe ；tag=1234

　　To： Ken

　　Contact：

　　然后，P1收到呼叫請求以后，通過修改Route-Record地址，增加另外一個IPv6的地址繼續(xù)進行路由轉(zhuǎn)發(fā)。P1然后通過IPv6地址對U2繼續(xù)進行呼叫（兩個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 // 通過P1的 路由set

　　sip：192.0.2.254：5060：lr

　　然后，U2就知道，它可以通過路由set中的IPv6地址發(fā)送此地址一個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一個200 OK：

　　SIP/2.0 200 OK

　　Record-Route：

　　Record-Route：

　　From： Joe

　　com>；tag=1234

　　To： Ken

　　Contact：

　　這時，在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

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

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

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

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

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

　　Route：

　　From： Joe

　　com>；tag=1234

　　To： Ken

　　Contact：

　　com；transport=tcp>

　　P1收到請求以后，然后通過UDP對U1發(fā)送到呼叫請求：

　　INVITE sip： ken@atlanta.network.

　　com；transport=udp SIP/2.0

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

　　From： Joe

　　com>；tag=1234

　　To： Ken

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

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

　　Record-Route：

　　com；transport=udp>

　　Record-Route：

　　com；transport=sctp>. // 增加對sctp支持

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

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

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

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

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

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

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

　　在SIP呼叫請求發(fā)起以后攜帶兩個頭消息參數(shù)（To和Request-URI）來確認呼叫目的地。一種方式是通過SIP URL/SIPS URL，另外一種是通過Tel URL的方式來標識呼叫目的地號碼。

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

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

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

　　所有ACK請求流程中都使用了Record-Route。

　　所有ACK請求流程中，其中一個代理服務(wù)器沒有插入Record-Route

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

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

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

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

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

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

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

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

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

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

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

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

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

　　主機名稱，支持下一跳以主機名稱的格式出現(xiàn)，避免如果下一跳使用IP地址，地址發(fā)送變動后出現(xiàn)的連接問題。SBC將會使用DNS來對主機名稱進行支持。

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

• 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

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

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

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

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

　　通過SBC生成對外呼叫測試（freesbc）

　　9、總結(jié)

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

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

　　參考資料：

　　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