別妄想世界永恒不變。——塞萬(wàn)提斯：《堂吉訶德》
在企業(yè)電話(huà)系統調整過(guò)程中，我們經(jīng)常聽(tīng)到用戶(hù)抱怨的問(wèn)題就是NAT問(wèn)題或者網(wǎng)絡(luò )環(huán)境發(fā)生變化導致電話(huà)終端呼叫頻繁出現故障。雖然這些問(wèn)題通過(guò)一些小技巧或者配置設置暫時(shí)解決了某個(gè)問(wèn)題，但是很多用戶(hù)仍然缺乏比較專(zhuān)業(yè)的解決辦法來(lái)應對不斷出現的新的問(wèn)題。為了解決用戶(hù)終端問(wèn)題，服務(wù)器端部署的需求和運營(yíng)商網(wǎng)絡(luò )兼容性等問(wèn)題，用戶(hù)可能采取了很多臨時(shí)性的解決辦法來(lái)解決這些問(wèn)題。這些客戶(hù)可能也沒(méi)有真正理解其問(wèn)題的根源。為了讓企業(yè)通信用戶(hù)讀者能夠完整了解各種SIP網(wǎng)絡(luò )中NAT以及其他處理方式和其優(yōu)缺點(diǎn)，包括企業(yè)通信系統擴展時(shí)應該關(guān)注的SBC部署等核心網(wǎng)元解決方案，筆者從NAT問(wèn)題產(chǎn)生以及相關(guān)背景知識，NAT方案的選擇，STUN， TUNE， ICE，SBC部署以及未來(lái)IMS網(wǎng)絡(luò )中SBC的遷移，NFV國內IMS網(wǎng)絡(luò )虛擬化中vIMS中的SBC的部署等多個(gè)方面對所涉及的解決方案做深入解讀，幫助讀者進(jìn)一步提高對未來(lái)語(yǔ)音網(wǎng)絡(luò )或者SIP、IMS網(wǎng)絡(luò )深入了解。
1-NAT基本概念/防火墻/UDP打洞/NAT類(lèi)型詳解
為了讓讀者了解完整的關(guān)于SIP和NAT以及后續SBC部署等相關(guān)的技術(shù)背景知識，我們實(shí)現需要為大家構建一個(gè)完整的知識體系。在本章節，筆者將重點(diǎn)討論以下幾個(gè)方面的內容，它們包括：防火墻，關(guān)于NAT的相關(guān)基礎概念，UDP 打洞介紹，NAT的類(lèi)型。這些基礎知識是討論關(guān)于SIP以及SBC部署必要的基礎內容。
VOIP的運行需要對接很多公網(wǎng)資源，例如，對接運營(yíng)商的SIP中繼，對接第三方的其他支持服務(wù)器，對接分公司業(yè)務(wù)等等數據。但是，無(wú)論怎么對接，用戶(hù)都需要一個(gè)標準的網(wǎng)絡(luò )架構來(lái)實(shí)現內網(wǎng)分機和外網(wǎng)的互聯(lián)互通。因為，網(wǎng)絡(luò )地址資源的限制，所以，內網(wǎng)和外網(wǎng)的互聯(lián)互通就需要一個(gè)內網(wǎng)地址轉換的機制，通過(guò)一個(gè)外網(wǎng)轉換到多個(gè)內網(wǎng)的地址。這里，就涉及到了路由器防火墻和應用業(yè)務(wù)的端口管理問(wèn)題，其中有一些應用可能還不是問(wèn)題，但是對SIP的語(yǔ)音通信來(lái)講，這仍然是一個(gè)非常具有挑戰性的難題。為了幫助讀者盡快了解這些相關(guān)的技術(shù)細節，我們盡可能在有限的篇幅中對NAT提供多角度，多維度的討論，幫助用戶(hù)盡快了解這些必要的技術(shù)。
1.1
請讀者注意，這里我們討論所有的相關(guān)細節時(shí)不會(huì )介紹太多和本話(huà)題不相關(guān)的技術(shù)內容，所以，筆者建議用戶(hù)首先了解一般的網(wǎng)絡(luò )環(huán)境和知識點(diǎn)，以免引起造成困擾。在討論NAT之前，我們首先解釋一下關(guān)于為什么防火墻的對NAT處理有影響。以下圖例解釋了一個(gè)簡(jiǎn)單的防火墻的工作拓撲圖：
此圖例以及以下圖例均來(lái)自于互聯(lián)網(wǎng)資源
這里，防火墻置于企業(yè)網(wǎng)絡(luò )邊界的地方，防火墻的工作就是保護公司內網(wǎng)的安全。關(guān)于防火墻的具體功能和配置，我們這里不再介紹。但是，為了配合SIP的相關(guān)話(huà)題，我們這里再次強調一下關(guān)于防火墻的使用環(huán)境的問(wèn)題，一般意義上，防火墻應該是：
- 防火墻對網(wǎng)絡(luò )數據進(jìn)行策略管理，數據流量管理。
- 防火墻對某些設備進(jìn)行權限的設置管理。
- 防火墻一般允許內網(wǎng)用戶(hù)訪(fǎng)問(wèn)外網(wǎng)，同時(shí)允許內網(wǎng)訪(fǎng)問(wèn)外網(wǎng)時(shí)返回的數據進(jìn)入到內網(wǎng)。
- 防火墻通常允許HTTP，SMTP這些一般的工作應用業(yè)務(wù)進(jìn)行數據傳輸。
- 防火墻通常對SIP不太友好，可能過(guò)濾SIP端口，RTP 端口。
- 防火墻只能對外網(wǎng)進(jìn)行保護，但是不能對內網(wǎng)軟件病毒或者其他內網(wǎng)設備發(fā)起的攻擊進(jìn)行保護。所以，盡量避免在內部電腦上安裝其他的未授權的第三方軟件。
1.2
大家知道，如果我們給公司公網(wǎng)申請一個(gè)固定IP地址的話(huà)是需要付費的，IP地址是一個(gè)緊缺資源，IPv4的地址資源已經(jīng)非常緊缺。通常情況下，一個(gè)可以上網(wǎng)的網(wǎng)絡(luò )環(huán)境至少需要一個(gè)公網(wǎng)的地址，這個(gè)公網(wǎng)地址對應內部網(wǎng)絡(luò )地址(Class A, Class B 和Class C)進(jìn)行轉換。RFC 6314 和RFC 4787對NAT做了規范。
為了實(shí)現一個(gè)公網(wǎng)地址對應多個(gè)內網(wǎng)地址來(lái)實(shí)現正常的網(wǎng)絡(luò )訪(fǎng)問(wèn)，我們必須使用一個(gè)NAT的機制，我們簡(jiǎn)單稱(chēng)之為網(wǎng)絡(luò )地址轉換(1:N)，通過(guò)NAT可以實(shí)現公網(wǎng)地址轉換為內網(wǎng)地址的作用。關(guān)于更多的NAT介紹，讀者可以參考網(wǎng)絡(luò )上的學(xué)習資料學(xué)習，這里不做過(guò)多討論。根據德國研究人員Florian Wohlfart對一般小型企業(yè)和家庭用戶(hù)對NAT的測試，根據網(wǎng)絡(luò )的不同，NAT過(guò)濾的比例也完全不同，所以NAT確實(shí)影響了數據的正常互通。
以下是一個(gè)內網(wǎng)終端訪(fǎng)問(wèn)外網(wǎng)的IP狀態(tài)，讀者通過(guò)以下圖例可以看到，內網(wǎng)地址在通過(guò)防火墻到公網(wǎng)，然后到達另外一個(gè)公網(wǎng)地址時(shí)，自己的內網(wǎng)IP地址已經(jīng)給替換成了公網(wǎng)的IP地址。在公網(wǎng)出局之前，內網(wǎng)地址會(huì )被過(guò)濾掉。
對端網(wǎng)絡(luò )響應的消息將會(huì )返回到防火墻，然后通過(guò)路由器策略返回到請求的終端IP地址。
上面，我們看到的是終端和服務(wù)器端的互通，現在我們看看兩個(gè)帶NAT的終端直接互通的實(shí)現方式。在以下的示例中，兩個(gè)帶NAT的終端都需要注冊到公網(wǎng)以外的服務(wù)器，然后實(shí)現正常的通信流程。
如果兩個(gè)終端需要直接互通的話(huà)，可以對服務(wù)器發(fā)出請求，然后服務(wù)器對其注冊策略進(jìn)行調整，讓兩個(gè)終端可以自己直接協(xié)商，兩個(gè)終端設備打洞以后實(shí)現雙方的直接互通。下面，我們介紹幾個(gè)不同NAT的流程處理方式：
同一NAT Hole Punching的一個(gè)具體流程：
不同NAT環(huán)境下 Hole Punching的處理流程：
多層NAT處理流程和一層NAT的處理機制基本上相同，但是多了一層協(xié)商的機制。網(wǎng)絡(luò )環(huán)境也變得更加復雜。
我們一直討論在不停解釋協(xié)商的概念，大家知道，UDP是一種不可靠的傳輸方式，需要端口一直處于存活狀態(tài)。如果打開(kāi)的洞在很久時(shí)間內沒(méi)有數據交換，可能這個(gè)洞就會(huì )關(guān)閉。所以在UDP的打洞時(shí)也使用了定時(shí)器的開(kāi)關(guān)來(lái)保證一定時(shí)間內這個(gè)洞是開(kāi)放的狀態(tài)。但是，不幸的是，很多NAT設備的設置和定時(shí)器的設置可能都不完全相同，一些設備的NAT的定時(shí)器設置一般為20秒，如果為了保證會(huì )話(huà)一直存活的話(huà)，可能需要調整定時(shí)器的時(shí)間長(cháng)度，在網(wǎng)絡(luò )中不停發(fā)送keep-live的數據包，可能在很短早期需要再次重新發(fā)送這些數據包，讓打開(kāi)的這個(gè)洞一直參與存活狀態(tài)。但是，更為不幸的是，這樣的做法同樣生成很多的無(wú)效數據，耗費了很多網(wǎng)絡(luò )資源。
上面我們討論了關(guān)于UDP打洞的幾個(gè)方式和UDP打洞的定時(shí)器設置問(wèn)題。既然有關(guān)于UDP的打洞的方式可能就會(huì )有基于TCP的打洞方式。關(guān)于TCP的方式，因為篇幅的關(guān)系，而且在我們的SIP案例中的使用量不多，所以，我們這里不再繼續展開(kāi)討論。讀者可以參考Bryan Ford 發(fā)表的文章做進(jìn)一步的研究，他的文章也討論了關(guān)于基于UDP打洞和TCP打洞的測試方式和測試流程。
根據Bryan發(fā)表的文章，在實(shí)際生產(chǎn)環(huán)境中，用戶(hù)對各種路由器的使用比例做了一個(gè)統計，以下是統計結果：
在使用點(diǎn)對點(diǎn)處理打洞的方法上，業(yè)內有很多公司也使用了UDP Hole Punching 來(lái)保證用戶(hù)的連接效果。Tribler的測試結果可以作為一個(gè)參考，根據它們官方數據，成功率都在85%以上。Tribler使用的具體測試方法和工具，請讀者查閱參考資料鏈接。
下面，我們結合一些我們經(jīng)常使用的場(chǎng)景來(lái)形象化地解釋一下打洞的實(shí)現方式。這些場(chǎng)景可能是：點(diǎn)對點(diǎn)的通信，或者服務(wù)器端的的Bypass功能。以下圖例是經(jīng)過(guò)雙方協(xié)商以后，實(shí)現雙方互通的流程。
如果終端都在同一NAT的內網(wǎng)環(huán)境中，系統也可以實(shí)現互通連接。這里，我們拿一個(gè)目前最為典型的云托管的FreePBX舉例。如果兩個(gè)終端都在同一內網(wǎng)，而且帶NAT環(huán)境。首先，兩個(gè)終端都需要實(shí)現SIP信令的連接，確保連接成功。
在這種情況下，IPPBX可以支持內網(wǎng)之間的互通，兩個(gè)同一內網(wǎng)的終端就可以實(shí)現語(yǔ)音或視頻的通話(huà)。這樣相對節省了很多網(wǎng)絡(luò )的資源。但是，也存在很多缺點(diǎn)，例如，影響計費功能，影響系統錄音功能。關(guān)于IPPBX終端直接互通的功能的設置和影響，我們在以前的Asterisk功能設置的講座中已經(jīng)提及，這里不再繼續討論。
在現實(shí)的網(wǎng)絡(luò )環(huán)境中，我們的網(wǎng)絡(luò )架構也遠遠不是我們介紹的那樣簡(jiǎn)單。很多網(wǎng)絡(luò )已經(jīng)涉及了多個(gè)NAT的環(huán)境，多個(gè)網(wǎng)絡(luò )地址，而且不同的防火墻對SIP的過(guò)濾也有所不同。
在實(shí)際運行環(huán)境中，比較典型的實(shí)例就是關(guān)聯(lián)了SIP內網(wǎng)地址，如果內網(wǎng)的終端SIP消息在出局時(shí)，防火墻經(jīng)過(guò)了NAT以后，相關(guān)的內網(wǎng)SIP 頭消息都會(huì )被丟棄或者修改（Via，Contact，SDP中的c），發(fā)送出去的只有公網(wǎng)IP地址的消息。如果外網(wǎng)終端返回響應的消息時(shí)，路由器就可能丟棄這些無(wú)效的消息，或者無(wú)法做出路由策略的判斷，返回的消息也不知道如何路由到內網(wǎng)相應的終端。
1.3
剛才，我們介紹了NAT對SIP的影響，現在，我們介紹一下NAT的四種類(lèi)型和各自的不同。完整的NAT類(lèi)型的定義可以參考維基百科的定義。
根據以下圖例我們可以看到，不同的NAT類(lèi)型，對IP地址和端口的定義是完全不一樣的，通過(guò)不同的IP地址和端口的組合限制來(lái)確定NAT的類(lèi)別。
以上圖例來(lái)自思科網(wǎng)絡(luò )資料
簡(jiǎn)單來(lái)說(shuō)，以上四種類(lèi)型的定義為：
- Full Cone來(lái)自網(wǎng)絡(luò )所有的請求都轉發(fā)到一個(gè)內網(wǎng)地址，IP地址，端口都不受到限制。
- Restricted Cone則限定某些外網(wǎng)的IP可以可以轉發(fā)到相應的一個(gè)內網(wǎng)地址，端口可以變動(dòng)。
- Port Restricted Cone則要求具體的IP地址和端口都限定。
- Symmetric Cone則可以同時(shí)支持多個(gè)IP地址/端口的版本，端口和IP地址必須是一組的限定。
從幾個(gè)類(lèi)型的定義看，NAT類(lèi)型對網(wǎng)絡(luò )的要求是完全不同的，Full Cone是最為寬松的，而Symmetric是最為嚴格的。我們這里根據不同的顏色和字體表示對NAT轉換的寬松程度。當然，越來(lái)越寬松勢必帶來(lái)很多的網(wǎng)絡(luò )安全隱患問(wèn)題和其他的問(wèn)題。
運營(yíng)商或者網(wǎng)絡(luò )本身也有對NAT的很多方面的限制。幾年前，德國研究人員在德國和美國針對中小型企業(yè)和家庭網(wǎng)絡(luò )調查得出的各種NAT的比例：
Tribler 公司對用戶(hù)做的NAT環(huán)境的調查結果，幾種NAT對用戶(hù)網(wǎng)絡(luò )的影響：
基于全球的NAT分布狀態(tài)：
因為NAT連接超時(shí)的頻率：
盡管NAT問(wèn)題非常復雜，很多商業(yè)公司提供了NAT測試的工具，用戶(hù)可以下載測試。Nattest 公司提供關(guān)于NAT檢測的一些解決方案，這家公司也提供檢測NAT的工具檢測超時(shí)，端口存活等狀態(tài)數據。
客戶(hù)端對服務(wù)器端發(fā)送請求，服務(wù)器端返回響應消息。這樣的交互大約要互相發(fā)送100多次，才能獲取到真實(shí)的數據。
以下是檢測存活時(shí)間流程。
以下是檢測關(guān)閉的測試流程。
1.4
在上一個(gè)部分我們介紹了NAT的幾種類(lèi)型，現在我們主要針對SIP終端結合NAT做一個(gè)簡(jiǎn)單的介紹。以下圖例簡(jiǎn)單解釋了SIP失敗的原因，用戶(hù)可以查閱RFC6314對NAT做更多了解。
以下圖例表示了UA呼叫外網(wǎng)的NAT類(lèi)型，full cone 對所有外網(wǎng)開(kāi)放。
以下圖例限定僅對IP地址開(kāi)發(fā)，即使用戶(hù)使用不同的端口。
以下圖例限定了用戶(hù)使用的端口和IP地址。
以下圖例說(shuō)明用戶(hù)同時(shí)限定了在同一會(huì )話(huà)時(shí)IP地址和端口的匹配。
總結，在本章節中我們介紹了關(guān)于防火墻的基本概念，另外，我們也討論了NAT的形成和一些關(guān)于NAT的打洞的技術(shù)討論，以及市場(chǎng)上各種NAT所在比例，我們還通過(guò)各種圖例結合SIP場(chǎng)景介紹了NAT的幾種類(lèi)型。通過(guò)以上對NAT的完整介紹，筆者希望用戶(hù)對NAT有一個(gè)完整的概念。在接下來(lái)的章節中，我們將介紹如何通過(guò)各種解決方案來(lái)解決NAT的問(wèn)題。
NAT方案的選擇/STUN/TUNE/ICE討論
前面的講座中我們討論了關(guān)于NAT的基本概念，NAT的類(lèi)型和NAT在語(yǔ)音解決方案中的問(wèn)題。今天，我們探討一下幾個(gè)NAT的解決方案和各自的問(wèn)題，包括：NAT 方案的選擇，STUN， TUNE， ICE。在接下來(lái)的章節中繼續介紹 ALG， PNnP， MediaProxy，Symmetric RTP和SBC。
1. NAT解決方案的選擇
目前，根據對NAT支持的不同，處理機制的不同，業(yè)內把解決NAT的方法一般有分為以下幾種：
這些方案都有其各自的特點(diǎn)。根據國外有關(guān)市場(chǎng)研究人員的報告指出，不同企業(yè)類(lèi)型的要求不同，部署成本，安全因素，維護成本等因素的影響，所以它們對解決方案的要求也可能有所不同，以下是調查結果發(fā)布狀態(tài)：
- 一般家庭用戶(hù)選擇簡(jiǎn)單的NAT解決方案，例如UPnp，STUN，TURN， ICE
- 小型企業(yè)用戶(hù)大部分用戶(hù)可能選擇STUN，TURN， ICE 或者SBC，也可能選擇UPnP的方案。
- 一般中型企業(yè)則選擇SBC，STUN， TURN和企業(yè)級的SBC加防火墻的方案。
- 比較大的企業(yè)則會(huì )選擇防火墻，SBC的解決方案。
當然，任何選擇都是基于其成本做出的決定。對于VOIP的解決方案，安全是一個(gè)公司的非常重要的考慮因素，用戶(hù)也要根據不同的安全要求對解決方案進(jìn)行比較全面的分析，以下圖例數據表示各種解決方案對安全的考慮和其可控性的考慮。
從以上數據我們可以看到，如果用戶(hù)需要更加安全的部署方式，需要對其訪(fǎng)問(wèn)有非常大的靈活性和可靠性，最好的方式還是選擇SBC。
2.關(guān)于STUN和TURN的討論
在實(shí)際生產(chǎn)環(huán)境中，我們客戶(hù)通常使用的設備所支持的STUN和TURN都可能有所不同，所以這樣就會(huì )導致一個(gè)解決方案兼容性的問(wèn)題。例如，可能有的物理話(huà)機支持STUN和TURN，但是不支持ICE，有的軟電話(huà)可能支持的舊版本的STUN，不支持新標準的STUN。
下面，我們介紹一下關(guān)于STUN的流程機制。這里我們要注意，一般我們舉例時(shí)使用的是RFC5389來(lái)解釋的，相對比較舊的STUN版本是RFC3489（classic STUN）。在RFC5389的規定中，STUN定義為輕量級的工具，它不是一個(gè)完整的NAT穿透解決方案（RFC3489定義為完整的解決方案），它僅是一個(gè)解決穿透能力的工具。另外，RFC3489的規定有幾個(gè)方面的不足，很難滿(mǎn)足真正的NAT解決方案。根據RFC5389的解釋?zhuān)琑FC3489的不足主要表現在：
- 在實(shí)際部署環(huán)境中，IP和端口有時(shí)可以作為Peer來(lái)進(jìn)行通信，有時(shí)則不能。Classic STUN沒(méi)有提供準確的方法來(lái)處理這些問(wèn)題。
- Classic STUN的算法對多層NAT可能發(fā)生錯誤。
- Classic STUN存在安全漏洞，可能有時(shí)駭客會(huì )利用某些端口重新映射時(shí)進(jìn)行地址或者端口修改。
目前，根據RFC5389對STUN所執行的功能包括：
- 用于ICE連接支持(MMUSIC-ICE)
- 用于客戶(hù)端的初始化連接（SIP-OUTBOUND）
- NAT行為發(fā)現(BEHAVE-TURN)。
STUN 簡(jiǎn)單來(lái)說(shuō)，內網(wǎng)SIP終端通過(guò)STUN對STUN發(fā)出請求，STUN回復一個(gè)響應，STUN服務(wù)器告訴使用指定的外網(wǎng)端口和IP地址。STUN使用UDP，默認端口是3478。它在響應的消息中包含了MAPPED-ADDRESS，RESPONSE-ORIGIN，OTHER-ADDRESS和XOR-MAPPED-ADDRESS這四個(gè)參數。通常來(lái)說(shuō)，為了支持NAT的映射和過(guò)濾行為機制，STUN服務(wù)器必須支持兩個(gè)公網(wǎng)IP地址和兩個(gè)不同的端口，分別稱(chēng)之為主信息地址和可選消息地址。讓我們看看具體的實(shí)現方式。
具體的流程包括：第一步客戶(hù)端A 通過(guò)設置的STUN地址查詢(xún)STUN外網(wǎng)地址和端口。第二步，客戶(hù)端A對客戶(hù)端B發(fā)生信令消息，通知客戶(hù)端B的外網(wǎng)地址和端口，可以對其發(fā)送媒體。客戶(hù)端B然后對NAT路由器發(fā)送媒體，NAT路由器然后轉發(fā)到客戶(hù)端 A。以下圖例是一個(gè)簡(jiǎn)單的STUN流程圖（缺少對Symmetric 的支持，需要TURN支持）：
在上面的流程中，NAT是如何被檢測的？RFC 5780 規定了三個(gè)階段的NAT檢測方式：
NAT檢測的具體步驟：
研究人員Baruch 更加詳細地描述了這個(gè)test的流程，用戶(hù)可以查閱此研究人員的文檔做進(jìn)一步了解。具體Test的邏輯順序請讀者參考 RFC5780的4.5 部分。如果讀者需要了解更多的相關(guān)定義，請參RFC 5780 相關(guān)協(xié)議：
現在讓我們看看在SIP中NAT請求和響應的示例。
STUN 返回的IP和port number， SIP然后在SIP header 使用這個(gè)新的地址。
大家需要注意一下SIP頭中的rport 1024, 當在NAT后的終端收到消息時(shí)，這個(gè)rport 端口會(huì )覆蓋原來(lái)的端口49300端口。這里，實(shí)際上，rport是做路由使用的。關(guān)于rport 端口的修改問(wèn)題，讀者查閱RFC3581 的Server Behavior中rport的修改規則。用戶(hù)必須注意，在有一些網(wǎng)絡(luò )環(huán)境中，系統管理機制可能對收到的消息和返回的消息地址端口非常敏感，如果是這樣的話(huà)，RFC3581 標準建議開(kāi)啟TLS服務(wù)。另外，用戶(hù)也應該注意到，如果修改rport了，這里可能涉及到了一個(gè)安全的問(wèn)題，攻擊者在路由路徑中插入了一個(gè)中轉服務(wù)器的話(huà)，可能導致安全問(wèn)題。
盡管STUN可以解決很多類(lèi)型的NAT問(wèn)題，但是它仍然具有很多局限性，具體表現在：
- STUN不支持Symmetric NAT類(lèi)型，因為每一個(gè)新創(chuàng )建的IP：port 的會(huì )話(huà)的映射可能導致以前STUN檢測到的數據失效。
- 如果防火墻設置了對UDP丟棄數據包的參數，也會(huì )導致STUN失敗。
- 因為UDP不是一個(gè)長(cháng)連接的方式，防火墻可能關(guān)閉一些存活動(dòng)端口，這樣可能導致會(huì )話(huà)失敗。
- 終端客戶(hù)的網(wǎng)絡(luò )環(huán)境可能導致STUN失敗，因為有的終端可以抵達服務(wù)商的服務(wù)器地址，有的SIP終端可能可能不會(huì )抵達STUN服務(wù)器地址（例如，很多國內用戶(hù)使用國外的STUN地址），這樣的話(huà)，SIP之間可能存在多層的NAT問(wèn)題。整個(gè)網(wǎng)絡(luò )環(huán)境會(huì )變得更加復雜。
3.關(guān)于TURN的討論
既然TUN存在那么多的問(wèn)題，但是如何解決這些問(wèn)題是技術(shù)研究人員必須面對的困難。俗話(huà)說(shuō)，辦法總比問(wèn)題多。TURN是一個(gè)補充STUN不足的好辦法。TURN的英文全稱(chēng)如下：
Traversal Using Relays around NAT (TURN)
Relay Extensions to Session Traversal Utilities for NAT (STUN)
從英文全稱(chēng)就可以看出，它僅是STUN的一種拓展，使用了中繼穿透NAT的方式。根據RFC5766的描述，TURN的設計目的是ICE的一部分，但是可以獨立使用。
在很多應用場(chǎng)景中，位于NAT后面的終端可能不能與外網(wǎng)的終端進(jìn)行點(diǎn)對點(diǎn)的通信，如果需要雙方通信的話(huà)，只能借助于一個(gè)外網(wǎng)的中轉服務(wù)點(diǎn)來(lái)實(shí)現互通。TURN的作用就是幫助雙方繞過(guò)阻擋的網(wǎng)絡(luò )點(diǎn)，使用中繼的方式，支持終端控制中繼操作從而實(shí)現雙方的數據交換，也可以支持終端對多點(diǎn)終端互通。
TURN和STUN相比，因為T(mén)URN本身的拓展，所以它也支持更多的功能，以下是對于TURN的一個(gè)總結：
- 除了本身工作方式類(lèi)似以外，TURN可以支持SIP消息和媒體的轉發(fā)，工作角色可以是一個(gè)代理的形式。
- TURN可以支持UDP和TCP，TCP可以支持長(cháng)連接，從而保證防火墻對會(huì )話(huà)的連接不會(huì )斷開(kāi)。但是，這里要注意，根據RFC5766的規定，如果是TRUN server 到Peer則都使用UDP。大概20%以上的會(huì )話(huà)需要使用TURN。
3.TURN可以支持Symmetric NAT, 但是STUN則不能支持。我們前面已經(jīng)提及。
4.TURN必須支持公網(wǎng)IP地址。
5.TURN的本身要求服務(wù)提供商的TURN服務(wù)器部署成本相對比較高。因為，TURN需要考慮大量會(huì )話(huà)，大量轉發(fā)數據，同時(shí)還要獲取Relays 路徑中的交換數據。
以上我們討論的是關(guān)于整個(gè)TURN的使用場(chǎng)景的各種因素，但是還有很多細節性的問(wèn)題可能在實(shí)際應用中也可能出現，例如，以下圖例是一個(gè)開(kāi)發(fā)人員在測試WebRTC中關(guān)于使用P2P和SFU時(shí)的數據，使用P2P或SFU測試的結果是完全不同的。以下是其中一個(gè)數據。
TURN服務(wù)器的性能表現因為地理位置部署原因，配置原因或者其他的原因造成的對語(yǔ)音時(shí)延也完全不同，以下示例來(lái)自于 Dag-Inge Aas， 在開(kāi)發(fā)WebRTC時(shí)對于TURN服務(wù)器時(shí)延的實(shí)驗數據，各個(gè)服務(wù)器的帶寬不同，處理能力不同導致的各種不同的結果。
如果用戶(hù)選擇TURN的話(huà)，可以參考Twillio的幾個(gè)標準來(lái)做出決定：是否全球部署，是否靠近用戶(hù)，是否支持拓展，是否優(yōu)化時(shí)延。
前面我們詳細討論了STUN和TURN的使用場(chǎng)景和各種影響。讀者可能會(huì )看到，以上兩種方式仍然存在一些問(wèn)題。ICE的出現改善了兩種NAT解決方法的很多問(wèn)題。ICE英文全名是Interactive Connectivity Establishment。RFC5245(更新的RFC6336)對ICE做了規定。一般簡(jiǎn)單的定義是：ICE=STUN+TURN+協(xié)商機制+協(xié)商路徑。以下圖例中表示了ICE的架構。
以下是一個(gè)Candidate的消息架構體，關(guān)于結構體中每個(gè)參數的含義，請參閱RFC3245的第三部分（Terminology)。
ICE執行的幾個(gè)步驟：
- 發(fā)現收集申請終端信息。收集到終端可通信的地址，終端申請者的類(lèi)型（host, Reflexive和Relay candidate)。
- 根據優(yōu)先級對candidate 進(jìn)行處理，大部分情況下，首先使用Relay candidate。
- 解析candidate信息，發(fā)送到對端candidate。
- 對candidate進(jìn)行配對處理，保證雙方匹配。
- 檢查配對的candidated的連接性。
- 計算ICE是否可以連接成功，如果成功，則發(fā)送確認消息。
- 然后進(jìn)行語(yǔ)音流的通信。
以下幾個(gè)步驟比較詳細地介紹了關(guān)于SIP ICE的協(xié)商過(guò)程：
通過(guò)priority oder，結合兩個(gè)pair check the ICE開(kāi)始測試。如果雙方測試成功，則進(jìn)行下一步的信令交互，例如SIP 2 發(fā)送180消息，發(fā)送200 OK消息。如果開(kāi)始發(fā)送到消息和收到的消息不一致，則需要SIP Phone 1 重新發(fā)送Re-INVITE消息，然后進(jìn)行測試驗證，最后收到200 OK消息。
ICE 測試成功以后，則雙方開(kāi)始發(fā)送RTP語(yǔ)音。
關(guān)于ICE的支持問(wèn)題，在我們很多常見(jiàn)的環(huán)境中，有的終端可以支持ICE，但是有一些終端可能不支持。用戶(hù)可以檢查各種軟電話(huà)的ICE配置功能。以下SIP消息中表示終端支持ICE:sip.ice。
如果對端終端不支持ICE的話(huà)，終端只能有兩種選擇：1）繼續連接，但是不使用ICE，ICE支持一個(gè)自動(dòng)檢測返回的機制，通知對端不支持ICE。2）或者繼續執行一個(gè)可選授權支持的方式使用ICE，根據RFC5768對Mandating Support的規定, SIP終端可以在INVITE請求的Require中添加一個(gè)ice option。
另外，用戶(hù)可能有時(shí)看到這樣的例子，在終端的SIP INVITE頭中沒(méi)有sip.ice, 但是在SDP中確實(shí)有ICE candidate的信息，這也是互相不兼容導致的結果，但是最終這是一種不支持ICE的標識。
因為SIP技術(shù)本身的快速發(fā)展，其實(shí)ICE的版本也在不斷更新。這里，我們簡(jiǎn)單介紹兩個(gè)ICE的“升級”版本。這里，我稱(chēng)之為升級版本僅是對ICE的一種優(yōu)化，它們并不是在ICE本身的升級或者更新：
ICE-lite主要功能是簡(jiǎn)化了ICE的復雜性，例如，我們看到的SBC。
Trickle ICE主要目的是縮短了ICE的協(xié)商處理時(shí)間，避免重新分配已被轉發(fā)的candidate，如果需要則開(kāi)啟。不像ICE的標準處理流程，標準的ICE需要收集candidate的信息狀態(tài)信息，它則一開(kāi)始就和host candidate檢查連接狀態(tài)，同時(shí)并行處理其他的交換機制。所以，Trickle ICE相對降低了處理流程花費的時(shí)間。
5.關(guān)于Near-NAT和Far-NAT討論
很多時(shí)候，大家可能會(huì )看到關(guān)于Near End NAT 和Far End NAT的解釋說(shuō)明。從字面意思也可以基本理解這兩個(gè)概念的基本區別。
Near End NAT是在本地NAT處理機制中通過(guò)本地ALG或者本地SBC修改了SIP 頭消息，出局時(shí)SIP頭消息變成了公網(wǎng)的IP地址，然后運營(yíng)商SBC增加一個(gè)Via到SIP 頭，最后呼叫到對端終端。下面圖例中的五個(gè)處理流程解釋了Near End NAT的完整過(guò)程。
Far End NAT是本地網(wǎng)絡(luò )對SIP頭消息不做任何處理，運營(yíng)商端SBC修改SIP頭消息，添加Via，然后呼叫遠端終端。同時(shí)，運營(yíng)商SBC會(huì )對內網(wǎng)SIP終端發(fā)送一個(gè)SIP OPTION 或者NOTIFY消息，保證終端SIP防火墻的端口不被關(guān)閉，通信端口一直處于存活狀態(tài)。
從以上介紹中，我們可以看到，兩者之間的區別就在于在說(shuō)明地方修改的SIP頭的IP地址，而且Far End NAT的處理方式會(huì )引起路由器需要不斷地接收從運營(yíng)商SBC發(fā)送到大量的NOTIFY消息，這樣可能會(huì )導致公司內網(wǎng)的不穩定。關(guān)于A(yíng)LG和SBC的解決方案介紹我們會(huì )在下一個(gè)講座中專(zhuān)門(mén)介紹這些內容。
總結，在本章節中，我們首先討論了關(guān)于STUN，TURN和ICE的原理和使用場(chǎng)景。同時(shí)，我們也介紹了它們之間的不同和各種在實(shí)際場(chǎng)景中所支持的功能和其局限性。另外，我們重點(diǎn)介紹了ICE的幾個(gè)協(xié)商流程，最后對兩個(gè)通常使用的NAT概念做了描述和介紹。ICE本身集合了STUN，TURN的各自的優(yōu)勢，在解決NAT方面可能是目前一種最佳的利器，但是因為網(wǎng)絡(luò )環(huán)境不斷變化，終端客戶(hù)的設備類(lèi)型也不斷升級，所以ICE的技術(shù)應用仍然在不斷升級來(lái)支持更多的要求。用戶(hù)需要根據自身特點(diǎn)，網(wǎng)絡(luò )資源，本身成本等不同方式來(lái)解決NAT問(wèn)題。
關(guān)于ICE的詳解，讀者可以參考以下鏈接：
關(guān)于UPnP/ALG/Symmetric RTP和Media Proxy介紹
在前面的講座中我們討論了NAT的類(lèi)型和解決NAT問(wèn)題所使用的幾種解決方式，STUN， ICE等部署方式和其局限性。今天，我們會(huì )介紹更多市場(chǎng)中主流的一些解決方案介紹UPnP，ALG，Symmetric RTP和Media Proxy。
在NAT解決方案中，我們不僅僅需要解決SIP信令的問(wèn)題，還要解決RTP的問(wèn)題。為了讓大家能夠繼續跟進(jìn)我們的講座，筆者多花一點(diǎn)時(shí)間回顧一下關(guān)于NAT對SIP和RTP的造成的影響（以前的講座中有比較深入的探討）。現在我們舉兩個(gè)簡(jiǎn)單的例子說(shuō)明NAT防火墻對SIP相關(guān)業(yè)務(wù)的影響。在以下的RTP 示例中，SIP信令都沒(méi)有問(wèn)題，內網(wǎng)用戶(hù)呼叫到外網(wǎng)也沒(méi)有問(wèn)題，但是對端外網(wǎng)用戶(hù)可能不能聽(tīng)到內網(wǎng)用戶(hù)的語(yǔ)音，出去的RTP語(yǔ)音可以成功到達目的地終端，但是外網(wǎng)終端則不能進(jìn)入到內網(wǎng)中。雖然SIP的SDP中已經(jīng)添加了對RTP語(yǔ)音的描述，但是如果防火墻會(huì )過(guò)濾這些端口，或者根本沒(méi)有開(kāi)啟這些端口的話(huà)，那么此語(yǔ)音流則會(huì )被過(guò)濾掉。這就是我們通常所說(shuō)的呼叫單通現象。
在下面的這個(gè)RTP示例中，如果是從防火墻外部用戶(hù)發(fā)起呼叫的話(huà)，防火墻會(huì )直接過(guò)濾了SIP請求，SIP消息會(huì )被拒絕。
從以上簡(jiǎn)單的示例中，讀者可以看到，很多時(shí)候我們面對的現實(shí)情況是：
- RTP端口是動(dòng)態(tài)變化的，這是一個(gè)難題。
- 防火墻不知道RTP端口變化。
- 讓防火墻開(kāi)啟更多端口在很多場(chǎng)景中是非常不現實(shí)的。
針對以上的問(wèn)題，為了解決這些問(wèn)題，我們依次介紹幾個(gè)比較簡(jiǎn)單的常見(jiàn)的解決方案。
1.1
在網(wǎng)絡(luò )中使用UPnP的設置方式。UPnP是一種非常簡(jiǎn)單的協(xié)議，它可以運行在SIP終端設備中，終端設備開(kāi)啟這個(gè)功能以后，它可以直接查詢(xún)公網(wǎng)地址和端口，然后讓SIP INVITE重新寫(xiě)入新的地址，在SDP中使用公網(wǎng)地址。UPnP的好處是目前大部分的廠(chǎng)家都支持此協(xié)議，終端用戶(hù)或者一般家庭用戶(hù)可以通過(guò)簡(jiǎn)單設置就可以實(shí)現簡(jiǎn)單的NAT穿透。
1.2
ALG全稱(chēng)是Application Layer Gateway。RFC2633對ALG有粗略的定義。ALG可以對SIP相關(guān)數據進(jìn)行轉譯（包括呼入請求，響應；呼出請求響應），隱藏內網(wǎng)必要消息，它收集SIP消息中的信息，主要對SIP 頭的Via，Contact，Route和Record-Route進(jìn)行處理。它和Media Proxy不同。它具有以下幾個(gè)方面的特點(diǎn)：
- ALG可以在DMZ中進(jìn)行設置，由防火墻實(shí)現對其控制。
- 和Media Proxy類(lèi)似，所有SIP消息和RTP消息可以通過(guò)ALG轉發(fā)到目的地地址。
- 如果需要，ALG可以配合NAT修改SIP消息的一些值域。
- ALG可以以軟件的形式嵌入到防火墻。
以下示例演示了一個(gè)簡(jiǎn)單的注冊流程，通過(guò)ALG以后，ALG然后修改地址，繼續對注冊服務(wù)器進(jìn)行注冊。注冊服務(wù)器返回地址以后，ALG再次修改為內網(wǎng)地址。
因為SIP的技術(shù)越來(lái)越普及，有一些防火墻增加了對SIP的部分支持功能。讓我們首先看一個(gè)如果是外網(wǎng)的用戶(hù)呼叫內網(wǎng)用戶(hù)時(shí)的流程，外網(wǎng)用戶(hù)呼叫內網(wǎng)時(shí)，在內網(wǎng)SIP終端返回給外網(wǎng)用戶(hù)時(shí)，防火墻設置了一個(gè)策略。這里，內網(wǎng)接收到端口是1344，防火墻則重新映射了一個(gè)端口1624，并且修改了SDP信息，然后在SDP中攜帶了新的RTP接收端口1624，發(fā)送給外網(wǎng)用戶(hù)，通知外網(wǎng)用戶(hù)，內網(wǎng)終端的RTP接收端口是1624。
外網(wǎng)終端通過(guò)這個(gè)指定的端口發(fā)送RTP語(yǔ)音流。防火墻知道通過(guò)這個(gè)端口的映射，然后根據映射規則，映射到內網(wǎng)的1344端口。到這里，RTP語(yǔ)音流正式開(kāi)通。雙方通話(huà)結束后，防火墻自動(dòng)刪除這個(gè)端口映射策略。
如果是內網(wǎng)用戶(hù)呼叫外網(wǎng)用戶(hù)，防火墻的映射機制基本上是相同的。這里，不同的是，內網(wǎng)用戶(hù)對外網(wǎng)用戶(hù)發(fā)起呼叫時(shí)，內網(wǎng)終端通知防火墻此終端準備接收RTP的具體端口，防火墻然后根據這個(gè)端口映射一個(gè)新端口，并且修改SDP的RTP端口，最后發(fā)送給外網(wǎng)的終端。外網(wǎng)終端則根據這個(gè)端口發(fā)送RTP語(yǔ)音，防火墻接收到這個(gè)端口的RTP流返回到原來(lái)的終端端口。如果通話(huà)結束，最后，防火墻刪除映射端口匹配設置。以下是一個(gè)完整的呼出的呼叫流程：
通過(guò)以上示例我們可以看到，事實(shí)上，ALG僅對Via, Conatct 這些值域進(jìn)行了修改，實(shí)現一個(gè)轉譯，支持了SDP payload。但是ALG目前不支持對多IP地址廣播，加密的SDP，SIP TLS和IP V6等其他功能。所以，從嚴格意義來(lái)說(shuō)，ALG仍然很難滿(mǎn)足SIP多種業(yè)務(wù)的需求。
1.3
Symmetric RTP可以幫助解決RTP端口通信不一致的問(wèn)題。我們首先了解一下它的處理流程。Symmetric RTP 的實(shí)現過(guò)程需要經(jīng)過(guò)以下幾個(gè)步驟：
首先，用戶(hù)需要通過(guò)STUN 服務(wù)器， 注冊服務(wù)器進(jìn)行SIP注冊流程，然后需要每30秒鐘重新注冊，這樣做的目的是保持端口處于存活狀態(tài)，避免端口不會(huì )被防火墻關(guān)閉。注意，這里的SDP端口是1776。
然后，UA 2收到了防火墻返回的端口消息后，如果UA 2支持Symmetric NAT，則會(huì )獲悉通知UA2 從這個(gè)端口（13455）返回語(yǔ)音流，而不是從SDP消息中的端口（1776）。這樣就避免了防火墻過(guò)濾RTP端口的問(wèn)題。這里的SDP中的端口是不會(huì )被認為是真正的RTP端口。
1.4
Media Proxy的目的是通過(guò)一個(gè)Proxy 代理的二次轉發(fā)機制，重新讓雙方終端通過(guò)Media Proxy進(jìn)行通信。UA 2就可以對UA1發(fā)起呼叫請求。這時(shí)的狀態(tài)和我們以前介紹的Far End NAT情況類(lèi)似，這里，需要Media Proxy處理一些proxy所承擔的工作包括：
Media Proxy需要重寫(xiě)SDP中的RTP/AVP值域，重新把RTP語(yǔ)音流指向媒體服務(wù)器需要的端口地址。
當對發(fā)起呼叫方SIP終端發(fā)送消息時(shí)，Media Proxy同時(shí)需要發(fā)送重寫(xiě)的RTP/AVP值域，保證RTP端口能夠發(fā)送到正確的RTP端口。
在防火墻的端口策略設置中，所使用的端口需要一直僅對Media proxy開(kāi)放。這樣就可以限定部分端口開(kāi)放給Media Proxy，無(wú)需完全開(kāi)放所有RTP端口。
1.5
總結，在本章節中我們討論了幾個(gè)主要的NAT解決方案，ALG，UPnP，Symmetric RTP和Media Proxy。通過(guò)我們的討論，我們可以發(fā)現，事實(shí)上，這些解決方案都針對某個(gè)特定問(wèn)題，它們都具有非常強的針對性，同時(shí)也具有非常多的局限性。用戶(hù)需要根據自己具體的問(wèn)題做更多的調研，找到適合自己需求的解決方案。在本章節的討論中，我們僅討論了SIP和RTP的互聯(lián)互通，基本上都是實(shí)現了SIP對NAT的簡(jiǎn)單功能實(shí)現，這些技術(shù)解決方案事實(shí)上并沒(méi)有真正解決SIP在公網(wǎng)的業(yè)務(wù)兼容性問(wèn)題，安全管理問(wèn)題，公司網(wǎng)絡(luò )和運營(yíng)商網(wǎng)絡(luò )之間的問(wèn)題。對于這些功能的要求就需要在網(wǎng)絡(luò )環(huán)境中部署SBC。因為SBC的討論話(huà)題非常廣，我們在下一節的講座中專(zhuān)門(mén)討論SBC的部署。
SBC在未來(lái)SIP/IMS網(wǎng)絡(luò )中的部署
在前面的關(guān)于SIP和NAT問(wèn)題的講座中，我們花費了大量篇幅把整個(gè)關(guān)于SIP和NAT的各種問(wèn)題做了比較全面和深入的探討，同時(shí)，我們也介紹了各種針對NAT的解決方案，但是那些方案僅解決了SIP在互聯(lián)網(wǎng)環(huán)境下的局部問(wèn)題，也沒(méi)有考慮到整個(gè)企業(yè)IPPBX環(huán)境所要求的其他業(yè)務(wù)能力的支持。盡管那些解決方案在某些特定的環(huán)境中實(shí)現了某些用戶(hù)的要求，但是它們本身還是具有一定的局限性和針對性。SBC則比較好地解決了我們討論的問(wèn)題。但是目前在市場(chǎng)上很少看到對SBC技術(shù)的全面介紹和剖析，很多公司的SBC介紹也僅局限于市場(chǎng)需求，使用了太多市場(chǎng)語(yǔ)言把SBC，很多描述可能有一些含糊不清。另外，一些相關(guān)的技術(shù)問(wèn)題也缺乏更多詳細說(shuō)明，用戶(hù)在了解和學(xué)習這些相關(guān)知識時(shí)會(huì )產(chǎn)生很多困擾。
筆者雖然在差不多10年前開(kāi)始接觸SBC，這期間也多多少少接觸了一些客戶(hù)，基本上了解一些客戶(hù)對SBC的需求和目前存在的潛在問(wèn)題。為了結合我們的SIP系列講座，筆者今天對SBC做一個(gè)比較全面的剖析，盡可能覆蓋大部分用戶(hù)所關(guān)心的問(wèn)題，這樣可以幫助SBC用戶(hù)能夠比較全面地對SBC有一個(gè)概括。我們討論的范圍從SBC使用背景和由來(lái)，市場(chǎng)需求，使用場(chǎng)景和存在的問(wèn)題以及面對未來(lái)IMS網(wǎng)絡(luò )和云部署環(huán)境進(jìn)行一個(gè)基本梳理。筆者不會(huì )在這里討論過(guò)多某個(gè)SBC廠(chǎng)家的產(chǎn)品技術(shù)細節，如果特別需要可能會(huì )適當加入一點(diǎn)廠(chǎng)家的SBC內容，幫助用戶(hù)理解SBC，否則讀者可能產(chǎn)生歧義。
筆者主要從幾個(gè)方面來(lái)剖析SBC的全貌，這些內容包括：SBC的基本概念，SBC產(chǎn)生的背景原因，SBC的市場(chǎng)情況，SBC的核心功能，SBC運營(yíng)商和企業(yè)客戶(hù)的使用場(chǎng)景，SBC的功能介紹，SBC錄音時(shí)的性能問(wèn)題，SBC部署時(shí)的問(wèn)題，SBC對SIP的流程的影響，SBC在IMS網(wǎng)絡(luò )中的角色，SBC虛擬化的可能性和基于開(kāi)源解決方案等方面的內容做一個(gè)全面的剖析（盡可能全面），幫助用戶(hù)全面了解SBC技術(shù)。
首先讓我們介紹一下SBC產(chǎn)生的背景。任何技術(shù)的產(chǎn)生都是基于一定的背景，只有客戶(hù)端需求越來(lái)越急迫的時(shí)候，一些對行業(yè)敏感的廠(chǎng)家就可能抓住機會(huì )來(lái)開(kāi)發(fā)這樣的產(chǎn)品滿(mǎn)足消費者。舉個(gè)例子，故事的大概過(guò)程是這樣的。當年美國早期的淘金熱時(shí)，Lee牛仔褲的暢銷(xiāo)就是因為L(cháng)ee的老板抓住了商機。當時(shí)西部淘金時(shí)礦工抱怨說(shuō)為什么沒(méi)有一條結實(shí)一點(diǎn)的褲子，同時(shí)褲兜的地方老是開(kāi)裂，Lee當年正好從事布匹的批發(fā)業(yè)務(wù)，他琢磨了半天，把當時(shí)做帆船的帆布經(jīng)過(guò)改造，結合褲子上打鉚釘的創(chuàng )意生產(chǎn)出了非常結實(shí)的牛仔褲。然后，Lee就開(kāi)始在全世界大賣(mài)。這樣的例子數不勝數。VoIP的發(fā)展也是這樣，隨著(zhù)VoIP的不斷發(fā)展，服務(wù)提供商不只提供一個(gè)簡(jiǎn)單的語(yǔ)音通話(huà)的功能，在實(shí)際的VoIP運營(yíng)環(huán)境中，SBC設備沒(méi)有真正部署或應用之前，市場(chǎng)上沒(méi)有專(zhuān)門(mén)的設備為服務(wù)提供商和服務(wù)提供商自己實(shí)現完整的對接解決方案，同時(shí)也沒(méi)有一套完整的解決方案來(lái)實(shí)現運營(yíng)商和終端客戶(hù)之間的對接支持。為了滿(mǎn)足運營(yíng)商服務(wù)的要求，很多廠(chǎng)家開(kāi)始研發(fā)SBC為一個(gè)運營(yíng)商邊界網(wǎng)絡(luò )的設備來(lái)支持運營(yíng)商的需求。在典型的應用環(huán)境中，SBC作為運營(yíng)商VoIP網(wǎng)絡(luò )邊界的互聯(lián)設備，這樣運營(yíng)商之間可以實(shí)現通信和策略控制。在介紹SBC的細節之前，讓我們首先明確幾個(gè)基本的概念：
- SBC的全稱(chēng)是Session Border Controller。簡(jiǎn)單來(lái)說(shuō)，SBC是部署在網(wǎng)絡(luò )邊界，用來(lái)控制SIP會(huì )話(huà)的設備或軟件。Session 表示會(huì )話(huà)，Border 表示網(wǎng)絡(luò )邊界，Controller 表示控制器。注意，這里的控制器很多用戶(hù)理解為是物理設備，事實(shí)上，也有很多廠(chǎng)家推出了基于軟件的E-SBC。
- 除了我們討論的SIP相關(guān)的技術(shù)范疇之內，目前沒(méi)有關(guān)于SBC非常明確的定義規定。
- 根據RFC5853的定義，SBC被定義為一個(gè)B2BUAs，它可以實(shí)現對某些SIP 頭消息和SDP媒體描述進(jìn)行修改。
在下面的圖例中，橙色部分就是經(jīng)過(guò)SBC處理以后的相關(guān)參數。注意，不同廠(chǎng)家的SBC或不同的業(yè)務(wù)需求對參數修改可能有所不同。這里的案例僅做示例來(lái)幫助用戶(hù)了解SBC的流程。
很多時(shí)候，一些客戶(hù)使用常用的概念來(lái)表示SBC的部署邊界。SBC在不同場(chǎng)景使用時(shí)的幾個(gè)主要概念：Peering SBC支持服務(wù)提供商對服務(wù)提供商的對接，Access SBC提供運營(yíng)商和企業(yè)用戶(hù)SBC的對接，Enterprise SBC提供企業(yè)之間的對接。
1.市場(chǎng)發(fā)展的要求
綜合前面討論的幾個(gè)NAT解決方案的介紹，無(wú)論從技術(shù)層面還是未來(lái)網(wǎng)絡(luò )的拓展性方面，前面我們討論的那些解決方案很難說(shuō)是一個(gè)比較完美的解決方案。這些解決方案可能存在以下幾個(gè)方面的問(wèn)題和挑戰：
- 不同客戶(hù)的不同需求，幾種NAT類(lèi)型的解決方案面對的是不同的客戶(hù)問(wèn)題，不同的網(wǎng)絡(luò )環(huán)境，不同的客戶(hù)要求，所以，這些解決方案很難構成一個(gè)完整的解決方案去支持大部分的客戶(hù)要求。
- 對服務(wù)提供商技術(shù)的挑戰，幾種解決方案對不同的公司有不同的要求，他們要求部署集成商提供專(zhuān)業(yè)的的技術(shù)水平，足夠的網(wǎng)絡(luò )帶寬，良好的網(wǎng)絡(luò )穩定性和兼容性。
- 終端用戶(hù)的多樣性，終端用戶(hù)很難控制對端網(wǎng)絡(luò )，對網(wǎng)絡(luò )服務(wù)，語(yǔ)音質(zhì)量，安全機制失了可控性，例如使用第三方的STUN/TURN服務(wù)。
- 缺乏統一管理的平臺機制，對網(wǎng)絡(luò )設置和安全機制的設置缺乏一個(gè)統一的管理機制。
- 終端對STUN，TURN和防火墻問(wèn)題，對不同終端所要求的支持能力也可能完全不同。
- 未來(lái)的可拓展性，以上幾種NAT解決方案缺乏對目前最新的SIP業(yè)務(wù)需求完整支持，例如IMS，電話(huà)轉接業(yè)務(wù)，錄音等要求。
- 對服務(wù)提供商的標準不同，缺乏對各種SIP服務(wù)提供商的兼容性測試標準，這樣失去了對業(yè)務(wù)能力的保證。
- 對融合通信的支持問(wèn)題，它們也缺乏融合通信的業(yè)務(wù)能力的支持包括未來(lái)業(yè)務(wù)的升級和拓展。
- 對多租戶(hù)IPPBX或者托管IPPBX部署支持的接入能力支持缺乏完整的商業(yè)解決方案支持。
通過(guò)以上各種問(wèn)題的總結，我們可以看到，SBC可能是目前SIP業(yè)務(wù)最佳的一種解決方案，這也是為什么最近幾年SBC逐漸受到重視的原因。
2.市場(chǎng)調查
根據美國專(zhuān)注融合通信市場(chǎng)研究的Infonetrics所做的調查,到2018年, 預計SBC的市場(chǎng)需求是365 million 美金，大家可以看到這是一個(gè)非常龐大的市場(chǎng)。2013年是250 million 美金，到2018年則增長(cháng)到了365 million 美金。SBC需求的增長(cháng)速度非常驚人。
在此報告中同時(shí)列出了幾個(gè)主要的SBC廠(chǎng)家：
在未來(lái)的5G/IMS網(wǎng)絡(luò )中，SBC也扮演著(zhù)非常重要的角色。我們在本章節的后續部分會(huì )介紹SBC在IMS網(wǎng)絡(luò )中所扮演的角色。
另外，微軟Teams 和Zoom Phone system 都明確提出了和SBC集成的解決方案：
微軟teams 市場(chǎng)份額不斷增加的同時(shí)，也要求用戶(hù)需要SBC才能和teams對接，這樣的話(huà)，SBC需求也水漲船高。因為IMS網(wǎng)絡(luò )部署的加快，國內在SBC需求方面也正在增加，以下是一個(gè)運營(yíng)商網(wǎng)絡(luò )對總部用戶(hù)網(wǎng)絡(luò )遷移建議的示例，包括了SBC對接，TG和IMS網(wǎng)絡(luò )接入的支持：
目前基于云平臺或者各種云SIP業(yè)務(wù)場(chǎng)景的部署支持中，SBC可能是唯一一種可以滿(mǎn)足不同用戶(hù)部署的解決方案。通過(guò)SBC對接部署，企業(yè)IPPBX可以實(shí)現SIP、IMS，PSTN的不同支持，同時(shí)，通過(guò)SBC路由設置實(shí)現不同業(yè)務(wù)呼叫控制功能。
3.SBC在運營(yíng)商和企業(yè)用戶(hù)的部署場(chǎng)景
大部分情況下，在介紹SBC的功能時(shí)，很多廠(chǎng)家的功能介紹比較含糊，這樣會(huì )導致用戶(hù)對產(chǎn)品的認識缺乏明確的概念，客戶(hù)可能喪失了部署SBC的信心。事實(shí)上，根據SBC使用的場(chǎng)景不同，SBC的功能有一定差別的。一般情況下，SBC 針對服務(wù)提供商和終端客戶(hù)兩種不同的場(chǎng)景需求。現在我們分別介紹一些功能要求。
以下圖例標識了運營(yíng)商和運營(yíng)商對接的方式：
目前，綜合各種SBC的功能需求，筆者把SBC的功能歸納為十大主要功能。根據服務(wù)提供商和企業(yè)終端客戶(hù)的需求不同，我們分別予以介紹。這里，筆者僅對不同服務(wù)根據業(yè)務(wù)的側重點(diǎn)不同進(jìn)行的簡(jiǎn)單分類(lèi)，以方便用戶(hù)掌握，不等于說(shuō)運營(yíng)商SBC和企業(yè)SBC功能上有什么特別的不同。SBC可以對服務(wù)提供商提供的支持包括：
- IP地址隱藏
- 權限訪(fǎng)問(wèn)控制，控制用戶(hù)訪(fǎng)問(wèn)權限，控制呼叫數量。
- 安全策略設置
- QoS 保障
- 計費功能
- 服務(wù)提供商之間應該可以提供更大的拓展能力
SBC可以對本地企業(yè)IPPBX的功能包括：
- 自動(dòng)切換服務(wù)線(xiàn)路，如果服務(wù)提供商的工作中繼出現問(wèn)題，SBC可以自動(dòng)切換到服務(wù)提供商的備份服務(wù)器。
- 提供對本地IPPBX進(jìn)行標準化處理，例如修改SIP SDP信息，編碼轉換，SIP-SS7的映射功能。
- 提供QoS保障。
- 可以提供協(xié)議的轉換功能，例如內網(wǎng)使用TCP連接，連接服務(wù)提供商時(shí)則使用UDP連接。
- 防止非法侵入和網(wǎng)絡(luò )詐騙電話(huà)。來(lái)自Acme Packet的Kaplan總結了以下幾種關(guān)于VOIP的攻擊方式：
NAT支持，遠端終端通過(guò)外網(wǎng)實(shí)現對內網(wǎng)IPPBX注冊。
筆者根據不同的場(chǎng)景提供幾個(gè)不同的解決方案圖例：遠端用戶(hù)注冊到企業(yè)內網(wǎng)SBC解決方案。托管IPPBX通過(guò)SBC對接的解決方案和企業(yè)SIP trunk的解決方案。
托管IPPBX通過(guò)SBC對接的案例。
典型的企業(yè)用戶(hù)IPPBX/呼叫中心對接SBC的案例：
當然，以上每一種功能都不一定是SBC用戶(hù)必須使用的功能，根據融合通信行業(yè)著(zhù)名市場(chǎng)分析公司IHS Markit的報告，它把SBC的幾個(gè)主要核心功能概括為：編碼轉換，協(xié)議轉換，NAT，拓撲隱藏，權限控制和安全控制。
另外，隨著(zhù)IMS網(wǎng)絡(luò )的進(jìn)一步普及，SBC需要支持IMS網(wǎng)絡(luò )環(huán)境中，SBC需要支持sigaling plane（P-CSCF，I-BCF）和media plane（IMS-AGW，TrGW）。很多運營(yíng)商已經(jīng)對SBC在IMS網(wǎng)絡(luò )的應用提出了非常緊迫的要求。因此，為了滿(mǎn)足未來(lái)IMS的網(wǎng)絡(luò )要求，SBC的功能不得不進(jìn)行升級。在3GPP環(huán)境中，SBC必須實(shí)現可拓展性，虛擬化和分布式部署。
SBC在IMS網(wǎng)絡(luò )中的功能模塊：
在IMS架構中需要合并UNI邊界部分和NNI的部分功能來(lái)實(shí)現SBC控制器功能。在UNI邊界中的SBC控制部分：
在NNI邊界部分的SBC控制部分，這里僅涉及了R7的訪(fǎng)問(wèn)。
目前，市場(chǎng)上比較領(lǐng)先的SBC設備一般集成IMS支持能力，也支持了以上幾個(gè)主要的核心模塊成為一個(gè)設備解決方案。
IMS網(wǎng)絡(luò )非常復雜，筆者水平有限，加之篇幅問(wèn)題，不能完整介紹整個(gè)IMS的架構。具體關(guān)于IMS網(wǎng)絡(luò )的介紹，請讀者查閱網(wǎng)絡(luò )文檔獲得更加詳細的介紹。
在國內，我們的IMS網(wǎng)絡(luò )發(fā)展一直在逐漸推進(jìn)中。中國電信2010年開(kāi)始引入 IMS，中國移動(dòng)2009年就開(kāi)始引入IMS網(wǎng)絡(luò )，中國聯(lián)通2012年就引入了IMS網(wǎng)絡(luò )，其他的行業(yè)用戶(hù)包括國家電網(wǎng)2013年也引入了IMS網(wǎng)絡(luò )。這些IMS網(wǎng)絡(luò )的都已經(jīng)開(kāi)始遍布全國。當然，在針對IMS部署中，很多用戶(hù)仍然對IMS網(wǎng)絡(luò )和SIP軟交換網(wǎng)絡(luò )之間的區別有一些疑問(wèn)，筆者提供了一個(gè)關(guān)于IMS網(wǎng)絡(luò )和軟交換網(wǎng)絡(luò )區別的對比列表，讀者可以參考從中獲得比較詳細的了解。
在國內IMS網(wǎng)絡(luò )的逐步推廣過(guò)程中，運營(yíng)商網(wǎng)絡(luò )的架構也隨著(zhù)傳統PSTN網(wǎng)絡(luò )退網(wǎng)，IMS網(wǎng)絡(luò )升級進(jìn)行了割接改造。以下是一個(gè)省級用戶(hù)割接中的遷移路徑，從傳統的軟交換逐步遷移到了以IMS網(wǎng)絡(luò )為主，通過(guò)SBC對接終端接口的方式。因此，我們可以預見(jiàn)，未來(lái)的語(yǔ)音網(wǎng)絡(luò )環(huán)境中SBC將作為一個(gè)非常核心的邊緣設備來(lái)支撐IMS網(wǎng)絡(luò )的運行。
4.SBC十大功能詳解
通過(guò)以上的篇幅，我們介紹了SBC的一些基本的功能和概念，筆者對SBC所支持功能歸納為十個(gè)具體的功能，它們分別是：
- DoS預防：防止外網(wǎng)用戶(hù)對內外IPPBX進(jìn)行網(wǎng)絡(luò )攻擊，SBC可以提前設置一些策略來(lái)預防攻擊。
- DoS保護，如果有DoS攻擊的話(huà)，SBC的處理能力可以支持DoS攻擊，設置黑名單，設置嘗試注冊次數都是比較好的手段。
- 權限控制：SBC可以控制用戶(hù)認證身份，可以控制計費能力，可以控制呼叫能力權限。
- QoS保障，通過(guò)SBC設置可以提供對QoS的語(yǔ)音保障。
- 標準化重構，這里的標準化重構的含義是對用戶(hù)提供的媒體能力，業(yè)務(wù)能力提供相應的轉化，并且能夠靈活地對對端進(jìn)行支持，例如支持編碼轉換，SDP 消息體修改，SIP-SS7消息映射。
- 檢測功能，SBC可以檢測網(wǎng)絡(luò )狀態(tài)，SIP信令狀態(tài)，語(yǔ)音質(zhì)量等相關(guān)信息。
- VPN分離，SBC可以針對不同用戶(hù)設置不同的VPN隧道功能。
- 拓撲隱藏，SBC提供了內網(wǎng)IPPBX對外網(wǎng)不可見(jiàn)的能力，SBC提供修改后的IP地址相關(guān)信息，這樣，外網(wǎng)用戶(hù)不會(huì )看到內網(wǎng)PBX信息。但是，讀者要注意，根據 RFC 5853中3.1.2的說(shuō)明，SBC不能很好地配合Authenticated Identity Management 工作。
- 系統資源優(yōu)化，SBC可以提供SIP注冊能力的均衡負載，SIP trunk的均衡負載，監控系統閥值，提供SIP/PSTN的逃生處理，保障系統達到最佳資源狀態(tài)。
- 防止非法入侵，SBC提供了對用戶(hù)的認證和簽權功能，同時(shí)提供了對信令語(yǔ)音的加密功能，SBC可以保障非法用戶(hù)的入侵。
5.部署SBC需要關(guān)注的問(wèn)題
盡管筆者花了很多時(shí)間介紹SBC的“好”， 但是在用戶(hù)部署環(huán)境中仍然有一些問(wèn)題需要用戶(hù)考慮：
- 性能處理的問(wèn)題，因為本身架構的問(wèn)題，SBC是一個(gè)B2BUA，簡(jiǎn)單來(lái)說(shuō)，就是SIP路徑上的一個(gè)中間人。這樣會(huì )導致很多問(wèn)題出現，例如標準重構時(shí)需要處理大量的SDP消息，同時(shí)可能需要進(jìn)行編碼轉換（關(guān)于編碼轉換的問(wèn)題筆者以前專(zhuān)門(mén)做過(guò)介紹），可能還要接收和發(fā)送大量的注冊消息，這些功能需要消耗大量的CPU資源和網(wǎng)絡(luò )接口資源，可能導致SBC穩定性降低。
- 需要擴展逃生功能支持傳統的PSTN，單純的SBC設備為了支持SIP的服務(wù)，為了保證企業(yè)電話(huà)系統100%正常工作，需要增加多個(gè)trunk智能支持，也同時(shí)需要傳統PSTN的接入。
- 國家法律的要求錄音功能，大家知道，中國已經(jīng)在最近幾年開(kāi)始要求一些敏感部門(mén)對電話(huà)進(jìn)行錄音。其實(shí)，美國在1994年就已經(jīng)制定了關(guān)于通信設備支持電話(huà)偵聽(tīng)的法案（ CALEA）。在RFC 3924中也相應地規定了錄音的要求。如果SBC不能支持錄音的話(huà)，SBC的功能需求就大打折扣，很多項目中，客戶(hù)也不敢使用不支持錄音的SBC。但是，如果支持錄音的話(huà)，SBC性能會(huì )受到很大影響，Menghui YANG 幾年前發(fā)表了VoIP網(wǎng)絡(luò )電話(huà)呼叫偵聽(tīng)對SBC性能的影響，以下是研究報告關(guān)于錄音和不錄音狀態(tài)下，SBC的并發(fā)處理數據。通過(guò)此報告數據可以看出，錄音或不錄音狀態(tài)下，對SBC的并發(fā)處理能力有很大差別。
- SIP REFER消息支持問(wèn)題或呼叫業(yè)務(wù)轉接支持也是一個(gè)值得重視的問(wèn)題，有時(shí)，如果本地用戶(hù)需要執行轉接功能的話(huà)，運營(yíng)商有兩種處理方式，第一種運營(yíng)商可能支持REFER，一般可能執行重新計費。當然，這里不排除利用轉電話(huà)接功能實(shí)現長(cháng)途呼叫功能，繞過(guò)運營(yíng)商本地計費，事實(shí)上，這也是一種詐騙的方式。所以，運營(yíng)商執行重新計費。第二種方式就是返回一個(gè)405 Method not Allowed消息，不支持本地用戶(hù)的呼轉服務(wù)。
以下圖例說(shuō)明了在內網(wǎng)沒(méi)有SBC的狀況下，運營(yíng)商會(huì )直接返回一個(gè)405消息，轉接服務(wù)被拒絕。
如果終端客戶(hù)部署了SBC后，前面我們已經(jīng)介紹過(guò)，SBC是一個(gè)B2BUA，可以修改SIP消息，重新發(fā)送一個(gè)帶本地ID的Re-INVITE消息，運營(yíng)商仍然看作是同一個(gè)呼叫，這樣運營(yíng)商會(huì )接受這個(gè)轉接呼叫服務(wù)。
再次說(shuō)明，因為REFER存在著(zhù)一個(gè)潛在的不安全因素，所以運營(yíng)商一般會(huì )拒絕這個(gè)請求。關(guān)于REFER安全的討論，大家可以查閱RFC3515的Authorization Consideration for REFER。
- 關(guān)于號碼歸屬地的問(wèn)題。號碼歸屬地可能導致計費錯誤，大部分情況這種可能性不會(huì )發(fā)生，但是有的運營(yíng)商會(huì )根據SIP頭帶的號碼來(lái)做一個(gè)簡(jiǎn)單的判斷，判斷號碼屬性。在用戶(hù)多個(gè)分公司部署的環(huán)境下，如果沒(méi)有嚴格設置號碼路由，很可能出現分公司內網(wǎng)用戶(hù)呼叫外地用戶(hù)就變成長(cháng)途呼叫的可能。例如，如果在深圳的分公司通過(guò)北京總部的PBX出局呼叫北京或者河北的用戶(hù)，運營(yíng)商很可能根據SIP帶的號碼歸屬地，認為這是來(lái)自深圳的呼叫，從而以長(cháng)途計費。如果通過(guò)SBC重新修改成一個(gè)標識為本地PBX出局的號碼身份，則運營(yíng)商就會(huì )認為這是本地客戶(hù)電話(huà)系統的呼叫，而不是一個(gè)來(lái)自外地的呼叫。SBC同時(shí)也可以根據路由的要求，添加一個(gè)號碼歸屬地前綴，表示國家或者地區的屬性。SBC也可以實(shí)現對tgrp的支持，通過(guò)添加tgrp標簽，運營(yíng)商也可以正確識別客戶(hù)的SIP身份。
- SBC結合IPPBX的兼容性測試問(wèn)題，網(wǎng)絡(luò )有很多的討論，筆者推薦根據Avaya的兼容性測試流程來(lái)進(jìn)行測試。具體的測試項目包括：通過(guò)SBC IPPBX用戶(hù)的呼出呼入測試，直接點(diǎn)對點(diǎn)的IP呼叫測試，DTMF測試-使用RFC2833進(jìn)行IVR測試，語(yǔ)音等待測試流程測試，呼叫專(zhuān)接，電話(huà)會(huì )議，長(cháng)時(shí)間呼叫摘機測試，錄音測試和T38傳真收發(fā)測試。如果讀者真正想進(jìn)行完整權威的對接測試，筆者建議參考SIPconnect 社區的測試標準來(lái)進(jìn)行對接測試。
用戶(hù)根據架構圖實(shí)現兼容性測試，具體測試要求查閱參考資料的鏈接。以下是SIPConnect-2.0 的測試流程圖：
- SBC對WebRTC的支持問(wèn)題。WebRTC技術(shù)是最近幾年發(fā)展非常火的技術(shù)，在和SIP結合時(shí)，很多公司也建議使用SBC來(lái)解決編碼轉換的問(wèn)題和語(yǔ)音加密的問(wèn)題。這里需要注意，一些SBC編碼轉換功能可能還不能完全支持VP8 或最新的VP9。
6.SBC虛擬化的可行性研究
實(shí)際上，隨著(zhù)IMS 用戶(hù)的不斷增加，運營(yíng)商對SBC的維護部署也有了新的要求，例如使用基于云的計算平臺，使用虛擬化的解決方案都是可行的。首先了解一下傳統的SBC架構，它是一種一體機設備的解決方案，包括DSP，Cryto 處理加密，TCAM處理媒體，CPU的核心要件。
國外一些公司已經(jīng)開(kāi)始著(zhù)手進(jìn)行SBC虛擬化解決方案的可行性研究，一些公司的虛擬化SBC解決方案已開(kāi)始測試。他們的研究是基于目前比較成熟的云平臺來(lái)實(shí)現。研究人員認為基本的云計算技術(shù)架構已經(jīng)可以滿(mǎn)足SBC的虛擬化部署，其主要根據是：
- Intel CPU的發(fā)展可以支持多核處理，支持虛擬化。
- Linux X86 結合強大的CPU 實(shí)現并行處理的能力不斷強化，為SBC容量擴展提供了硬件支持。
- 開(kāi)發(fā)自有的軟件DSP負責編碼轉換，這里，研究人員也考慮了DSP的成本問(wèn)題，不過(guò)，無(wú)論軟硬件的DSP，成本一般都比較高。
- CPU可以被充分利用，DSP只做編碼處理。
- 亞馬遜的AWS對信令處理的性能比較滿(mǎn)意，媒體處理能力也相對比較好。
- 分布式部署，信令和媒體獨立處理，提高了擴容的可能性。
以上關(guān)于SBC虛擬化可行性的研究討論都是基于云平臺技術(shù)本身，當然也有賴(lài)于開(kāi)發(fā)人員的技術(shù)實(shí)力。比較受關(guān)注的微軟收購了metaswitch以后再基于metaswitch 5G網(wǎng)絡(luò )呼叫中的虛擬IMS網(wǎng)絡(luò )的實(shí)現方式。微軟通過(guò)收購metaswitch，打通了Teams 服務(wù)業(yè)務(wù)，實(shí)現了針對企業(yè)和個(gè)人Teams，PSTN的全覆蓋。微軟已經(jīng)成為傳統語(yǔ)音業(yè)務(wù)運營(yíng)商最大競爭對手。
目前國內運營(yíng)商對IMS網(wǎng)絡(luò )虛擬化或者運營(yíng)商網(wǎng)絡(luò )虛擬化都進(jìn)行了很多技術(shù)方面的研究和探討，包括了NFV等方面的深入研究。以下是國內核心網(wǎng)絡(luò )發(fā)展的基本歷程：
在運營(yíng)商網(wǎng)絡(luò )向NFV 網(wǎng)絡(luò )虛擬化遷移的過(guò)程中，其實(shí)我們最關(guān)心的是在IMS網(wǎng)絡(luò )中的遷移。通過(guò)IMS網(wǎng)絡(luò )向vIMS網(wǎng)絡(luò )遷移的路徑中，我們仍然需要高度關(guān)注基于軟件的SBC的部署。
為了支持vIMS網(wǎng)絡(luò )中軟件SBC的支持，我們需要虛擬化，基于軟件的SBC實(shí)現SBC功能支持。
7.SBC對SIP網(wǎng)絡(luò )流程帶來(lái)的挑戰
我們在前面的很多章節中討論了很多使用SBC的好處，但是SBC在實(shí)際網(wǎng)絡(luò )環(huán)境的使用中，用戶(hù)仍然需要面對很多不可知的挑戰：
- SBC可能會(huì )破壞整個(gè)端對端SIP的邏輯流程的自然屬性。如果部署相對封閉的VoIP解決方案，SBC可能是一個(gè)需要考慮的問(wèn)題。
- SBC可能會(huì )破壞整個(gè)端對端SIP的呼叫流程，這樣會(huì )導致UAS對SIP呼叫流程的監控和狀態(tài)失去作用，并且增加了技術(shù)排查難度，可能增加其他設備或軟件來(lái)彌補SBC帶來(lái)的問(wèn)題。
- SBC不僅對信令進(jìn)行二次處理，也對媒體進(jìn)行二次處理，例如編碼轉換的流程。這樣的話(huà)，會(huì )給雙方的語(yǔ)音呼叫帶來(lái)進(jìn)一步的延遲，增加了運營(yíng)商的帶寬成本。但是，我們經(jīng)常遇到的是，運營(yíng)商提供的是相對占用帶寬比較低的G.729, 這樣就需要終端客戶(hù)自己進(jìn)行編碼處理，這樣就會(huì )導致本地IPPBX，網(wǎng)關(guān)或SBC必須做編碼轉換，同樣增加本地用戶(hù)的部署成本。
- 加密以后的SIP和SBC結合會(huì )帶來(lái)更加復雜的問(wèn)題。記得一位麻省理工多媒體實(shí)驗室的學(xué)者說(shuō)過(guò)這樣一句話(huà)- “Your advantages are your disadvantages”。任何事情都帶有兩面性。具有諷刺意味的是，大家知道我們使用SBC是為了更加安全，如果IPPBX和終端之間已經(jīng)使用了加密機制的話(huà)，SBC是最有可能出現問(wèn)題的一個(gè)中間環(huán)節。根據RFC 5853 3.1.2 部分的說(shuō)明，假設SIP終端都已經(jīng)設置了加密的方式和IPPBX進(jìn)行通信驗證，SBC則需要獲得SIP頭內容和SDP的體，這里就要求SBC需要首先讀取對發(fā)送到呼叫方的加密消息，并且SBC還要需要獲得被呼叫方的確認和信任。訪(fǎng)問(wèn)被呼叫方的私鑰可能還要涉及其他的服務(wù)認證設置。這樣的流程就完全可能導致終端的協(xié)商失敗。如果SBC移除加密機制，重新設置加密機制的話(huà)，那么SBC就會(huì )打破SIP終端之間的加密認證機制。這里再次提醒用戶(hù)，根據 RFC 5853中3.1.2的說(shuō)明，SBC不能很好地配合Authenticated Identity Management工作，具體說(shuō)明讀者可查閱RFC5853。
- SBC支持媒體流量管理帶來(lái)的問(wèn)題。大家知道，SBC不僅僅對信令做出處理，同時(shí)也負責媒體的管理也包括媒體流量的管理。有時(shí)，SBC可以檢測丟失Bye消息的媒體會(huì )話(huà)，丟失Bye消息可能就意味著(zhù)這個(gè)呼叫在中間某個(gè)環(huán)節已經(jīng)出現異常或者死掉，SBC必須通過(guò)檢測媒體狀態(tài)，然后返回信令掛機消息。有時(shí)，運營(yíng)商會(huì )根據數據流量來(lái)計費，如果在媒體路徑上部署了SBC的話(huà)，媒體經(jīng)過(guò)SBC的轉發(fā)處理，可能導致媒體數據丟失的問(wèn)題，同時(shí)增加了SBC的負載。另外，和我們上面介紹的一樣，如果終端客戶(hù)雙方進(jìn)行了加密處理，SBC沒(méi)有獲得雙方的許可，那么RTP加密認證又是一個(gè)問(wèn)題。
- SBC對標準化重構的支持問(wèn)題。雖然SBC支持標準化重構。很多情況下，終端之間完全可能出現支持能力不同的問(wèn)題，雙方所各自支持的功能可能不完全匹配，這時(shí)運營(yíng)商需要SBC重新進(jìn)行標準化重構的機制，這樣就可以滿(mǎn)足雙方的通話(huà)要求。如果在大并發(fā)處理的環(huán)境中出現大量類(lèi)似的不同功能的標準化重構的話(huà)，SBC就需要支持大量的配置機制，并且能夠保證并行處理大量的流程處理。例如，同時(shí)處理IPv4 和IPv6 轉換，也可能同時(shí)處理G.711到G.729的轉換，還有可能同時(shí)處理VP8 到G.711的轉換或者TCP到UDP的轉換。這個(gè)問(wèn)題需要SBC用戶(hù)盡可能做一些進(jìn)一步的研究，選擇真正有處理能力，能夠完全支持復雜環(huán)境的SBC產(chǎn)品。
- SBC備份的問(wèn)題。如果一個(gè)單點(diǎn)SBC出現故障需要備份的話(huà)，主從服務(wù)器之間需要非常緊密的配合才能實(shí)現媒體和信令的成功切換，否則極有可能出現大批用戶(hù)突然失去連接的問(wèn)題。
- SBC未來(lái)的功能支持，這個(gè)內容對于筆者來(lái)說(shuō)太大，筆者僅根據RFC5853的一些建議對此做一個(gè)簡(jiǎn)單總結。SBC在未來(lái)的設計中應該支持一個(gè)對SIP更加友好的拓撲隱藏方式，應該支持一個(gè)對SIP更加友好的媒體流量管理方式，應該支持一個(gè)對SIP更加友好的標準化重構方式。
8.SBC開(kāi)源解決方案
Kamalio，OpenSIPs結合Asterisk或者FreeSWITCH是一種相對比較“經(jīng)濟”的部分SBC解決方案。關(guān)于使用以上開(kāi)源解決方案實(shí)現SBC的功能，筆者在幾年前也做過(guò)類(lèi)似的探討，這里不會(huì )再次做過(guò)多詳細的介紹，網(wǎng)絡(luò )上有很多類(lèi)似的文檔可以參考。但是，客觀(guān)地說(shuō)，如果通過(guò)以上類(lèi)似的非常龐大的軟交換平臺開(kāi)發(fā)成為一個(gè)SBC的話(huà)，它距離真正的生產(chǎn)環(huán)境和商業(yè)使用還有很長(cháng)的距離，需要開(kāi)發(fā)人員投入很大的精力去完善。這里，筆者有幾個(gè)方面的建議用戶(hù)可以考慮：
使用以上開(kāi)源平臺，是否有足夠的人力去開(kāi)發(fā)維護。
目前網(wǎng)絡(luò )上看到的SBC解決方案僅實(shí)現了SBC的部分功能，大部分僅實(shí)現了拓撲隱藏，防攻擊，NAT基本功能，如果嚴格地說(shuō)，還不能算一個(gè)完整的SBC解決方案。另外，很多公開(kāi)的開(kāi)源的SBC設置文檔也缺乏對底層的優(yōu)化，如果需要真正部署在用戶(hù)環(huán)境，仍然需要優(yōu)化。
Kamalio/OpenSIPs 可以實(shí)現媒體的處理，但是需要第三方媒體服務(wù)器參與才能支持一個(gè)比較完整的SBC功能。
編碼轉換需要開(kāi)發(fā)人員進(jìn)一步投入才能完成，目前，還沒(méi)有真正的開(kāi)源的媒體轉換的功能能夠支持大量的媒體轉換，過(guò)多可能還是有賴(lài)于A(yíng)sterisk或者FreeSWITCH實(shí)現媒體轉換的功能。
Asterisk或者FreeSWITCH平臺的SIP和媒體耦合度太緊密，媒體和信令獨立或分離的可能性不大，這樣的話(huà)就可能導致SBC缺乏真正的可拓展性。當然，用戶(hù)確實(shí)有非常強大的技術(shù)研發(fā)隊伍也可以進(jìn)一步優(yōu)化。
Kamailio/OpenSIPs對SIP RFC的兼容性支持相當強大靈活，但是需要非常高的技術(shù)要求。
個(gè)人覺(jué)得，目前比較可行的企業(yè)級SBC開(kāi)源解決方案是Kamailio做信令服務(wù)器，FreeSWITCH作為一個(gè)媒體服務(wù)器，負責錄音和編碼轉換。編碼轉換可以使用基于硬件的編碼轉換卡來(lái)獲得編碼能力的支持，并且編碼處理能力也可以做分布式部署拓展發(fā)布。關(guān)于此開(kāi)源解決方案具體的部署方式，用戶(hù)可以訪(fǎng)問(wèn)Kamailio或FreeSWITCH官方網(wǎng)站獲得詳細配置文件。
使用OpenSIPS作為SBC來(lái)使用，OpenSIPS本身支持B2BUA模塊，也可以實(shí)現SBC的功能，而且結合編碼轉換卡可以實(shí)現編碼轉換的功能，但是仍然缺乏媒體服務(wù)器的支持，還是需要依賴(lài)第三方的媒體服務(wù)器實(shí)現媒體的控制。
在本章節中，我們簡(jiǎn)單回顧了以前章節的一些NAT解決方案的內容和存在的問(wèn)題，然后介紹了SBC的產(chǎn)生背景，SBC的用戶(hù)場(chǎng)景和SBC的主要功能，同時(shí)，我們也探討了SBC在部署時(shí)需要用戶(hù)注意到問(wèn)題，還有目前SBC對SIP的影響，最后我們分別介紹了SBC的虛擬化可行性研究探討和基于開(kāi)源解決方案的簡(jiǎn)單論述。通過(guò)以上大篇幅的介紹，我們希望給用戶(hù)一個(gè)比較完整的SBC解決方案的剖析，然后用戶(hù)要根據自己的使用場(chǎng)景，部署成本，可維護性，拓展性做一個(gè)正確的評價(jià)。
總結
在本文章討論中，筆者通過(guò)基本的NAT問(wèn)題討論，NAT處理方式包括具體的NAT方案的選擇，STUN， TUNE， ICE各種處理方式的概念和基本原理，和讀者分享了這些處理發(fā)生的優(yōu)缺點(diǎn)，也分享了關(guān)于一些小技巧的處理設置發(fā)生。另外，筆者重點(diǎn)介紹了目前在SIP網(wǎng)絡(luò )中最核心的網(wǎng)元產(chǎn)品-SBC，并且從各種角度說(shuō)明了SBC部署和其他解決方案的不同之處以及其先進(jìn)性，另外，筆者討論了關(guān)于SBC目前市場(chǎng)需求和支持的各種靈活的處理功能，分享了一些關(guān)于SBC部署的成功案例。最后，針對SBC部署和國內運營(yíng)商IMS網(wǎng)絡(luò )虛擬化等最新技術(shù)發(fā)展潮流來(lái)看SBC的未來(lái)發(fā)展模式和云SBC的形態(tài)。
在本文章中涵蓋的內容比較多，筆者僅從自我認識的角度和個(gè)有限的個(gè)人知識為大家介紹了在SIP網(wǎng)絡(luò )部署中各種NAT問(wèn)題解決的優(yōu)缺點(diǎn)和SBC的必要性。因為用戶(hù)部署環(huán)境中可能涉及更多的具體問(wèn)題，例如，業(yè)務(wù)場(chǎng)景和部署需求，公司資源等問(wèn)題，本文章不能作為一個(gè)非常權威的商業(yè)指導，僅做個(gè)人建議參考。另外，文章中難免有理解錯誤或者其他錯誤，敬請諒解！
參考資料：
- www.dinstar.com
- www.asterisk.org.cn
- https://tools.ietf.org/html/rfc6314
- https://tools.ietf.org/html/rfc4787
- http://www.brynosaurus.com/pub/net/p2pnat.pdf
- http://conferences.sigcomm.org/co-next/2013/workshops/HotMiddlebox/program/p43.pdf
- https://www.tribler.org/NATMeasurements/
- http://www.ds.ewi.tudelft.nl/reports/2010/PDS-2010-007.pdf
- http://manoftoday.wdfiles.com/local--files/nat/SIPNATtraversal.pdf
- https://medium.com/the-making-of-appear-in/webrtc-and-turn-latency-around-the-world-4d172dd59e8e
- https://bloggeek.me/turn-public-ip-address/
- https://mp.weixin.qq.com/s?__biz=MzA4NjU0NTIwNQ==&mid=2656443981&idx=1&sn=8cf8ac5c32845ddeb97f4094802cd3ed&chksm=8465b817b31231015de6fa7966e1cea18b68b5b92f8d0e73b5955d001b718ce0aeffdd27f8af&token=1678925094&lang=zh_CN#rd
- https://tools.ietf.org/html/rfc5853
- http://kb.asipto.com/freeswitch:kamailio-3.1.x-freeswitch-1.0.6d-sbc
- https://www.opensips.org/Documentation/Tutorials-SangomaVoiceTranscoding
- https://www.nanog.org/meetings/nanog34/presentations/kaplan.pdf
- https://datatracker.ietf.org/doc/rfc3924/
- https://www.sipforum.org/download/sipconnect-technical-recommendation-version-2-0/?wpdmdl=2818
部署VoIP呼叫實(shí)現網(wǎng)絡(luò )偵聽(tīng)對SBC性能影響：Implementation and Performance for Lawful Intercept of VoIP calls based on SIP Session Border Controller
https://mp.weixin.qq.com/s?__biz=MzA4NjU0NTIwNQ==&mid=2656444105&idx=1&sn=d4e71928e557fca9da5474eb139b5237&chksm=8465b893b3123185f46c489fd2bf83863a730588d425153926c08305789f457e45b25963b0d2&token=1678925094&lang=zh_CN#rd
https://mp.weixin.qq.com/s?__biz=MzA4NjU0NTIwNQ==&mid=2656443981&idx=1&sn=8cf8ac5c32845ddeb97f4094802cd3ed&chksm=8465b817b31231015de6fa7966e1cea18b68b5b92f8d0e73b5955d001b718ce0aeffdd27f8af&token=1678925094&lang=zh_CN#rd
https://docs.microsoft.com/en-us/microsoftteams/direct-routing-call-notifications
