在前面的講座中我們討論了NAT的類型和解決NAT問題所使用的幾種解決方式，STUN， ICE等部署方式和其局限性。今天，我們會介紹更多市場中主流的一些解決方案介紹UPnP，ALG，Symmetric RTP和Media Proxy。在下一期的講座中我們會全面討論SBC的技術解決方案。
在NAT解決方案中，我們不僅僅需要解決SIP信令的問題，還要解決RTP的問題。為了讓大家能夠繼續跟進我們的講座，筆者多花一點時間回顧一下關於NAT對SIP和RTP的造成的影響（以前的講座中有比較深入的探討）。現在我們舉兩個簡單的例子說明NAT防火牆對SIP相關業務的影響。在以下的RTP 示例中，SIP信令都沒有問題，內網用戶呼叫到外網也沒有問題，但是對端外網用戶可能不能聽到內網用戶的語音，出去的RTP語音可以成功到達目的地終端，但是外網終端則不能進入到內網中。雖然SIP的SDP中已經添加了對RTP語音的描述，但是如果防火牆會過濾這些埠，或者根本沒有開啟這些埠的話，那麼從語音流則會被過濾掉。這就是我們通常所說的單通現象。
在下面的這個RTP示例中，如果是從防火牆外部用戶發起呼叫的話，防火牆會直接過濾了SIP請求，SIP消息會被拒絕。
從以上簡單的示例中，讀者可以看到，很多時候我們面對的現實情況是：
RTP埠是動態變化的，這是一個難題。
防火牆不知道RTP埠變化。
讓防火牆開啟更多埠在很多場景中是非常不現實的。
針對以上的問題，為了解決這些問題，我們依次介紹幾個常見的解決方案。
1、在網絡中使用UPnP的設置方式。UPnP是一種非常簡單的協議，它可以運行在SIP終端設備中，終端設備開啟這個功能以後，它可以直接查詢公網地址和埠，然後讓SIP INVITE重新寫入新的地址，在SDP中使用公網地址。UPnP的好處是目前大部分的廠家都支持此協議，終端用戶或者一般家庭用戶可以通過簡單設置就可以實現簡單的NAT穿透。
2、ALG全稱是Application Layer Gateway。RFC2633對ALG有粗略的定義。ALG可以對SIP相關數據進行轉譯（包括呼入請求，響應；呼出請求響應），隱藏內網必要消息，它收集SIP消息中的信息，主要對SIP 頭的Via，Contact，Route和Record-Route進行處理。它和Media Proxy不同。它具有以下幾個方面的特點：
ALG可以在DMZ中進行設置，由防火牆實現對其控制。
和Media Proxy類似，所有SIP消息和RTP消息可以通過ALG轉發到目的地地址。
如果需要，ALG可以配合NAT修改SIP消息的一些值域。
ALG可以以軟體的形式嵌入到防火牆。
以下示例演示了一個簡單的註冊流程，通過ALG以後，ALG然後修改地址，繼續對註冊伺服器進行註冊。註冊伺服器返回地址以後，ALG再次修改為內網地址。
因為SIP的技術越來越普及，有一些防火牆增加了對SIP的部分支持功能。讓我們首先看一個如果是外網的用戶呼叫內網用戶時的流程，外網用戶呼叫內網時，在內網SIP終端返回給外網用戶時，防火牆設置了一個策略，這裡，內網接收到埠是1344，防火牆則重新映射了一個埠1624，並且修改了SDP信息，然後在SDP中攜帶了新的RTP接收埠1624，發送給外網用戶，通知外網用戶，內網終端的RTP接收埠是1624。
外網終端通過這個指定的埠發送RTP語音流。防火牆知道通過這個埠的映射，然後根據映射規則，映射到內網的1344埠。到這裡，RTP語音流正式開通。雙方通話結束後，防火牆自動刪除這個埠映射策略。
如果是內網用戶呼叫外網用戶，防火牆的映射機制基本上是相同的。這裡，不同的是，內網用戶對外網用戶發起呼叫時，內網終端通知防火牆此終端準備接收RTP的具體埠，防火牆然後根據這個埠映射一個新埠，並且修改SDP的RTP埠，最後發送給外網的終端。外網終端則根據這個埠發送RTP語音，防火牆接收到這個埠的RTP流返回到原來的終端埠。如果通話結束，最後，防火牆刪除映射埠匹配設置。以下是一個完整的呼出的呼叫流程：
通過以上示例我們可以看到，事實上，ALG僅對Via, Conatct 這些值域進行了修改，實現一個轉譯，支持了SDP payload。但是ALG目前不支持對多IP位址廣播，加密的SDP，SIP TLS和IP V6等其他功能。所以，嚴格意義來說，ALG仍然很難滿足SIP多種業務的需求。
3、Symmetric RTP可以幫助解決RTP埠通信不一致的問題。我們首先了解一下它的處理流程。Symmetric RTP 的實現過程需要經過以下幾個步驟：
首先，用戶需要通過STUN 伺服器， 註冊伺服器進行SIP註冊流程，然後需要每30秒鐘重新註冊，這樣做的目的是保持埠處於存活狀態，避免埠不會被防火牆關閉。注意，這裡的SDP埠是1776。
然後，UA 2 收到了防火牆返回的埠消息後，如果UA 2 支持Symmetric NAT，則會獲悉通知UA2 從這個埠（13455）返回語音流，而不是從SDP消息中的埠（1776）。這樣就避免了防火牆過濾RTP埠的問題。這裡的SDP中的埠是不會被認為是真正的RTP埠。
4、Media Proxy的目的是通過一個Proxy的二次轉發機制，重新讓雙方終端通過Media Proxy進行通信。UA 2就可以對UA1 發起呼叫請求。這時的狀態和我們以前介紹的Far End NAT情況類似，這裡，需要Media Proxy處理一些proxy所承擔 的工作：
Media Proxy需要重寫SDP中的RTP/AVP值域，重新把RTP語音流指向媒體伺服器需要的埠地址。
當對發起呼叫方SIP終端發送消息時，Media Proxy同時需要發送重寫的RTP/AVP值域，保證RTP埠能夠發送到正確的RTP埠。
在防火牆的埠策略設置中，所使用的埠需要一直僅對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
總結，在本章節中我們討論了幾個主要的NAT解決方案，ALG，UPnP，Symmetric RTP和Media Proxy。通過我們的討論，我們可以發現，事實上，這些解決方案都有非常強的針對性，同時也具有非常多的局限性。用戶需要做更多的調研，找到適合自己需求的解決方案。在本章節的討論中，我們僅討論了SIP和RTP的互聯互通，基本上都是實現了SIP對NAT的簡單功能實現，這些技術解決方案事實上並沒有真正解決SIP在公網的業務兼容性問題，安全管理問題，公司網絡和運營商網絡之間的問題。對於這些功能的要求就需要在網絡環境中部署SBC。因為SBC的討論話題非常廣，我們在下一節的講座中專門討論SBC的部署。
關注我們的公眾微信號：asterisk-cn 獲得有價值的行業技術分享，訪問論壇：www.issabel.cn/forum 下載開源免費融合通信平臺。