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