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