在NAT解決方案中，我們不僅僅需要解決SIP信令的問題，還要解決RTP的問題。為了讓大家能夠繼續(xù)跟進(jìn)我們的講座，筆者多花一點(diǎn)時(shí)間回顧一下關(guān)于NAT對(duì)SIP和RTP的造成的影響（以前的講座中有比較深入的探討）。現(xiàn)在我們舉兩個(gè)簡單的例子說明NAT防火墻對(duì)SIP相關(guān)業(yè)務(wù)的影響。在以下的RTP 示例中，SIP信令都沒有問題，內(nèi)網(wǎng)用戶呼叫到外網(wǎng)也沒有問題，但是對(duì)端外網(wǎng)用戶可能不能聽到內(nèi)網(wǎng)用戶的語音，出去的RTP語音可以成功到達(dá)目的地終端，但是外網(wǎng)終端則不能進(jìn)入到內(nèi)網(wǎng)中。雖然SIP的SDP中已經(jīng)添加了對(duì)RTP語音的描述，但是如果防火墻會(huì)過濾這些端口，或者根本沒有開啟這些端口的話，那么從語音流則會(huì)被過濾掉。這就是我們通常所說的單通現(xiàn)象。
在下面的這個(gè)RTP示例中，如果是從防火墻外部用戶發(fā)起呼叫的話，防火墻會(huì)直接過濾了SIP請求，SIP消息會(huì)被拒絕。
從以上簡單的示例中，讀者可以看到，很多時(shí)候我們面對(duì)的現(xiàn)實(shí)情況是：
RTP端口是動(dòng)態(tài)變化的，這是一個(gè)難題。
防火墻不知道RTP端口變化。
讓防火墻開啟更多端口在很多場景中是非常不現(xiàn)實(shí)的。
針對(duì)以上的問題，為了解決這些問題，我們依次介紹幾個(gè)常見的解決方案。
1、在網(wǎng)絡(luò)中使用UPnP的設(shè)置方式。UPnP是一種非常簡單的協(xié)議，它可以運(yùn)行在SIP終端設(shè)備中，終端設(shè)備開啟這個(gè)功能以后，它可以直接查詢公網(wǎng)地址和端口，然后讓SIP INVITE重新寫入新的地址，在SDP中使用公網(wǎng)地址。UPnP的好處是目前大部分的廠家都支持此協(xié)議，終端用戶或者一般家庭用戶可以通過簡單設(shè)置就可以實(shí)現(xiàn)簡單的NAT穿透。
2、ALG全稱是Application Layer Gateway。RFC2633對(duì)ALG有粗略的定義。ALG可以對(duì)SIP相關(guān)數(shù)據(jù)進(jìn)行轉(zhuǎn)譯（包括呼入請求，響應(yī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消息可以通過ALG轉(zhuǎn)發(fā)到目的地地址。
如果需要，ALG可以配合NAT修改SIP消息的一些值域。
ALG可以以軟件的形式嵌入到防火墻。
以下示例演示了一個(gè)簡單的注冊流程，通過ALG以后，ALG然后修改地址，繼續(xù)對(duì)注冊服務(wù)器進(jìn)行注冊。注冊服務(wù)器返回地址以后，ALG再次修改為內(nèi)網(wǎng)地址。
因?yàn)镾IP的技術(shù)越來越普及，有一些防火墻增加了對(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)終端通過這個(gè)指定的端口發(fā)送RTP語音流。防火墻知道通過這個(gè)端口的映射，然后根據(jù)映射規(guī)則，映射到內(nèi)網(wǎng)的1344端口。到這里，RTP語音流正式開通。雙方通話結(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語音，防火墻接收到這個(gè)端口的RTP流返回到原來的終端端口。如果通話結(jié)束，最后，防火墻刪除映射端口匹配設(shè)置。以下是一個(gè)完整的呼出的呼叫流程：
通過以上示例我們可以看到，事實(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)格意義來說，ALG仍然很難滿足SIP多種業(yè)務(wù)的需求。
3、Symmetric RTP可以幫助解決RTP端口通信不一致的問題。我們首先了解一下它的處理流程。Symmetric RTP 的實(shí)現(xiàn)過程需要經(jīng)過以下幾個(gè)步驟：
首先，用戶需要通過STUN 服務(wù)器， 注冊服務(wù)器進(jìn)行SIP注冊流程，然后需要每30秒鐘重新注冊，這樣做的目的是保持端口處于存活狀態(tài)，避免端口不會(huì)被防火墻關(guān)閉。注意，這里的SDP端口是1776。
然后，UA 2 收到了防火墻返回的端口消息后，如果UA 2 支持Symmetric NAT，則會(huì)獲悉通知UA2 從這個(gè)端口（13455）返回語音流，而不是從SDP消息中的端口（1776）。這樣就避免了防火墻過濾RTP端口的問題。這里的SDP中的端口是不會(huì)被認(rèn)為是真正的RTP端口。
4、Media Proxy的目的是通過一個(gè)Proxy的二次轉(zhuǎn)發(fā)機(jī)制，重新讓雙方終端通過Media Proxy進(jìn)行通信。UA 2就可以對(duì)UA1 發(fā)起呼叫請求。這時(shí)的狀態(tài)和我們以前介紹的Far End NAT情況類似，這里，需要Media Proxy處理一些proxy所承擔(dān) 的工作：
Media Proxy需要重寫SDP中的RTP/AVP值域，重新把RTP語音流指向媒體服務(wù)器需要的端口地址。
當(dāng)對(duì)發(fā)起呼叫方SIP終端發(fā)送消息時(shí)，Media Proxy同時(shí)需要發(fā)送重寫的RTP/AVP值域，保證RTP端口能夠發(fā)送到正確的RTP端口。
在防火墻的端口策略設(shè)置中，所使用的端口需要一直僅對(duì)Media proxy開放。 這樣就可以限定部分端口開放給Media Proxy，無需完全開放所有RTP端口。
5、參考資料：
https://docs.citrix.com/en-us/netscaler/11/solutions/netscaler-support-for-telecom-service-providers/lsn-introduction/lsn-configuring-alg/sip-protocol-alg.html
總結(jié)，在本章節(jié)中我們討論了幾個(gè)主要的NAT解決方案，ALG，UPnP，Symmetric RTP和Media Proxy。通過我們的討論，我們可以發(fā)現(xiàn)，事實(shí)上，這些解決方案都有非常強(qiáng)的針對(duì)性，同時(shí)也具有非常多的局限性。用戶需要做更多的調(diào)研，找到適合自己需求的解決方案。在本章節(jié)的討論中，我們僅討論了SIP和RTP的互聯(lián)互通，基本上都是實(shí)現(xiàn)了SIP對(duì)NAT的簡單功能實(shí)現(xiàn)，這些技術(shù)解決方案事實(shí)上并沒有真正解決SIP在公網(wǎng)的業(yè)務(wù)兼容性問題，安全管理問題，公司網(wǎng)絡(luò)和運(yùn)營商網(wǎng)絡(luò)之間的問題。對(duì)于這些功能的要求就需要在網(wǎng)絡(luò)環(huán)境中部署SBC。因?yàn)镾BC的討論話題非常廣，我們在下一節(jié)的講座中專門討論SBC的部署。
關(guān)注我們的公眾微信號(hào)：asterisk-cn 獲得有價(jià)值的行業(yè)技術(shù)分享，訪問論壇：www.issabel.cn/forum 下載開源免費(fèi)融合通信平臺(tái)。
