術語和基礎知識
防火牆
一個防火牆限制私人內網和公衆因特網之間的通訊，典型地防火牆就是丟棄那些它認爲未經許可的數據包。在數據包穿越一個防火牆時，它檢查但是不修改包裏的 IP地址和TCP/ UDP 端口信息。
網絡地址轉換(NAT)
當數據包穿過NAT時，NAT不僅檢查同時也修改數據的包頭信息，並且允許更多的在NAT後的主機分享少數公網IP地址(通常只有1個)。
NAT的類型和說明
NAT通常有2種主要類型
- Basic Nat
一個Basic NAT映射一個內在的私有IP地址到一個公網IP地址，但當數據包穿過NAT時，不更換它的TCP/UDP端口號。Basic Nat通常是隻用在一些具備公共IP地址池的NAT上，通過它可以地址綁定，即代表一臺內部主機。 - Network Address/Port Translator (NAPT)
但是最通常的，當數據包穿過NAT時，一個NAPT檢查並修改它的TCP/UDP端口，那麼就可以允許多臺內網主機同時共享一個單獨的公網IP地址了。
關於 NAT 的分類和術語，[NAT-TRAD] 和 [NAT-TERM]中有更多的信息。那些將來分類的NAPT的附加術語在較近的工作[STUN]中被定義。當一個內網的主機經過一個NAT和外部進行TCP或者UDP連接的期間，NAPT分配一個公網IP 住址和端口，以便來自外部終端響應的數據包能被NAPT接收，解釋，並轉發給內網的主機。這個結果是由 NAPT 建立一個(私有IP地址，私有端口)和(公網IP地址，公網端口)之間的端口綁定實現的。在這個期間NAPT將爲綁定的端口執行地址翻譯。一個關於P2P應用的問題是，當一個內部主機從一個私有IP，私有端口同時與外網上的多臺不同的主機建立多個連接時，NAT是如何運作的。
Cone NAT
建立一個端口，把一個(私有IP，私有端口)和(公用IP，公用端口)綁定後，對於以後來自同一私有IP和端口號的應用連接，cone NAT將重複使用這個綁定的端口，只要有一個連接會話，這個綁定端口就會保持激活狀態。
例如，下面圖表中，推想一下客戶端A通過一個cone NAT同時建立2個外部會話，從同樣的內部網絡終端(10.0.0.1:1234)到2個不同的外部服務器，S1和S2。cone NAT只會分配一個公用的終端，155.99.25.11:62000，都會到兩個會話，並在地址轉換期間確保客戶端端口的一致。Basic NAT和防火牆不修改通過的數據包中的端口號，這些類型可以被認爲是一種特殊的Cone Nat。
Symmetric NAT
對稱的NAT(Symmetric NAT)，與Cone NAT有明顯差別，在所有會話期間中不會保持綁定(私有IP，私有端口)和(公共IP，公共端口)的端口不變。相反，它會爲每個新對話重新分配一個新的公共端口。
舉例來說，設想客戶A從同樣端口上要發起兩個外部對話，一個和S1連接，另一個和S2連接。Symmetric NAT可能會爲第一個會話分配一個公共的端點 155.99.25.11:62000，而爲第二個會話分配一個不同的公共端點155.99.25.11:62001。爲了地址轉換，NAT可以區分這兩個會話傳輸的目的，因爲和這些會話有關的外部端點(就是S1、S2)是不同的，甚至在通過地址轉換時丟失了客戶端的目的標示。(即丟了S1、S2的IP地址NAT也知道如何區分，我是這麼理解的，可能有誤)。
Cone NAT和Symmetric NAT之間的比較與TCP/UDP之間的比較有些類似。(TCP需要綁定，UDP不需要，Cone NAT需要綁定，Symmetric NAT不需要)
按照NAT從已知的公共IP，公共端口接收的數據限制，Cone NAT可以更進一步的進行分類。這種分類通常都是UDP連接的，因爲NAT和防火牆會拒絕任何無條件的TCP連接，除非明確地以別的方式配置。
Full Cone NAT
在給一個新的外部會話建立了一個公共/私有的端口綁定後，一個full cone NAT就可以通過這個公共端口從公網上的任何外部端點接收數據通訊了。Full cone NAT也常常叫做"混合"NAT。
Restricted Cone NAT
當網絡主機發一個或者幾個數據包給外部主機後，一個受限的cone NAT(Restricted Cone NAT)纔會接受來自這個外部(源)IP地址的數據包。受限的cone NAT有效的運用了防火牆的原理，拒絕沒有要求的數據，只接收已知道的外部IP地址傳來的數據。(偏開原文，大意就是網絡主機需要發一個請求給外部IP地址要求要數據，NAT纔會接收這個外部IP地址傳來的數據，不然不接收。)
Port-Restricted Cone NAT
一個端口受限的cone NAT(Port-Restricted Cone NAT)，也是這樣，只接收那些網絡主機曾經發給一個外部IP地址和端口相匹配的數據。一個Port-Restricted cone NAT可以和對稱 NAT一樣(symmetric NAT)，保護內部節點不接收未被請求的數據包，但是保持一個私有端口在連接過程中不變。(即不僅請求的IP和外部發來數據的IP是一樣的，PORT也要是一樣，這樣才接收數據。對稱NAT也有這個效果，但這種cone NAT保持端口不變，而對稱NAT要變端口號的)。由此可見，Symmetric Cone條件最嚴格，Partial/Restricted Cone次之，Full Cone條件最寬鬆。
Firewall的基本策略：
Firewall會判斷所有的包是來自內部（Inside）還是外部(Outside)。
允許所有來自inside的包發出去。
允許來自Outside的包發進來，但這個連接必須是由Inside發起的。
禁止所有連接由Outside發起的包發進來。
firewall會允許幾個信任的outside主機，他們可以發起建立連接，併發包進來。
所有NAT和Firewall都是對於TCP/IP層以下進行處理和過濾的，而SIP應用的地址是在應用層。所以必須採用其他的途徑來解決這一問題。
解決方案
針對不同的NAT類型，可以有不同的解決方案。
1．客戶端解決方案
客戶端解決方案主要包括：STUN(simpletraversalof UDP through NAT)、TURN（Traversal Using Relay NAT）、ICE（Interactive Connectivity Establishment）。
STUN是一個輕量級的協議，允許應用程序探測當前在它們與公網之間是否存在NAT、防火牆以及它們的類型，並且具備能夠探測到NAT所分配的公網地址和端口的能力。STUN協議中定義了兩個實體：STUNClient和STUNServer。STUNClient嵌入在終端系統的應用程序中，比如SIP UA，它向STUN Server發送請求；STUN Server接收請求併產生STUN響應，它是無狀態的。SIP終端在建立呼叫之前，通過向處在公網上的STUN服務器發送STUN請求，得到信令和媒體流在NAT上的映射地址，並且將這些地址填寫到SIP消息中的Via、Contact字段以及SDP中的媒體流傳輸地址，替代原有的私有地址。但是，STUN只能工作在全通NAT、地址限制NAT以及端口限制NAT的網絡環境下，在對稱性NAT的情況下，SIP UA通過STUN請求得到的映射地址是無效的。
TURN協議在語法和操作上均與STUN相似，其優點是提供了對對稱性NAT的穿越。處在公網的TURN服務器爲客戶端提供本身的一個外部IP地址和端口，並且負責中轉通信雙方的媒體流。TURN協議雖然支持所有類型的NAT穿越，但是它需要中轉通信雙方的媒體流，使得媒體流在傳輸過程中增加了一跳，不可避免地增加了包的延遲和丟包的可能性，而且完全使用TURN方式需要大量的TURN服務器，在有大量用戶時，TURN服務器會成爲系統瓶頸，因此我們應該儘量避免使用這種方法。目前，TURN的使用越來越少。
ICE目前已經被推認爲在非對稱性NAT環境下首選的客戶端解決方案。ICE本身是一種方法，它利用STUN,TURN等任何符合UNSAF的協議來提供一個通用的解決方案。
2.路由邊界解決方案
路由邊界解決方案主要包括：應用層網關ALG、通用即插即用UPnP、中間盒通信MIDCOM。
應用層網關可以設計成能夠識別指定IP協議（比如H.323和SIP協議）的防火牆，也被叫做ALGFirewall。它不是簡單地察看包頭信息來決定數據包是否可以通過，而是更深層的分析數據包負載內的數據，也就是應用層的數據。H.323和SIP協議都在負載中放了重要的控制信息，例如語音和視頻終端使用哪一個數據端口來接收對方終端的語音和視頻數據。通過分析哪一個端口需要打開，防火牆動態地打開那些被應用的端口，而所有別的端口依然安全地保持關閉狀態。如果網絡中有多層防火牆和NAT，則在呼叫路徑上的每個防火牆都必須被升級以支持ALG功能。
UPnP是爲了在電腦、智能設備和智能家電之間建立無所不在的網絡連接而提出的協議體系。由微軟公司發起，在1999年成立了一個開放的產業聯盟UPnPForum，制訂了一系列標準。其中的IGD(internetgatewaydevice)工作委員會提出了穿透NAT的解決方案，很多NAT設備製造商已經在新產品中支持這個協議。它以Internet 標準和技術(例如，TCP/IP、HTTP和XML)爲基礎，使這樣的設備彼此可自動連接和協同工作，從而使網絡(尤其是家庭網絡)對更多的人成爲可能。
MIDCOM是一種新出現的概念，其目的是使用第三方應用程序(包括硬件設備)來控制FireWall/NAT設備動態地決定安全策略，以適應VoIP業務。第三方的應用程序使用MIDCOM定義的協議(或私有協議)控制FireWall/NAT設備，根據“MultiMediaoverIP”的需要動態地打開呼叫信令、媒體流互通的IP地址和端口號，這樣Firewall/NAT系統就無須嵌入過多的對“MultiMediaover IP”協議分析、解析的功能，而只需要維持已經存在的安全策略及轉發機制，從而實現Firewall/NAT設備的穿透。
3．服務器端解決方案
服務器端解決方案主要包括：B2BUA（Back-to-BackUserAgent）、服務器端RTP中繼。
B2BUA是一個接收請求並充當UAS處理請求的邏輯實體，主要是通過兩個UA以Back-to-Back的工作模式控制經過它的呼叫。B2BUA與SIP代理服務器不同，B2BUA可以接收呼叫，並能對其進行修改，以其它形式代表發起呼叫的UA向終端目標發起呼叫，並能充當呼叫雙方的媒體協商代表或對其進行監控管理。B2BUA可以對經過它的來自於私網的呼叫進行處理完成NAT的穿越。爲適應所有類型NAT的環境，B2BUA也需要做媒體流的中介，因此，對於通信雙方來說，呼叫控制信令和媒體流在傳輸過程中均增加了一跳，隨着用戶的增加，B2BUA將成爲系統瓶頸。
服務器端RTP中繼的方式相對B2BUA有所改進，它將B2BUA所完成的功能集成到了SIP代理服務器上，由SIP系統中的代理服務器完成信令部分的NAT處理修改，另外增設獨立運行的媒體中繼服務器來完成媒體流的中繼。也就是說，將信令部分的NAT穿越和媒體流部分的NAT穿越分離開來，由不同的功能組件完成。服務器端RTP中繼方式相對B2BUA來說，具有更好的可擴展性，但由於在發展期，對於軟硬件支持方面來說，不是很成熟。
結論：
客戶端解決方案，雖然無需對現有NAT做任何改動，但對SIPUA的要求較高，需要支持相應的協議，而且到目前爲止還無法解決通信雙方均處在對稱性NAT的情況；
路由邊界的各種解決方案，均需要對NAT設備升級，但目前網絡實際已部署了大量的不支持相關特性的NAT設備，因而這種方式可行性較差；
服務器端解決方案，通過中繼RTP數據包來解決所有類型NAT的穿越，缺點就是增加了包的時延和丟包的可能性。
具體採用哪種方式解決SIP 防火牆問題需要從以下角度進行綜合考慮：
（1）升級要求：我們只能接受小規模的改造，所以只考慮對服務器端的改造，在極小一部分用戶這邊考慮一些客戶端改造，不考慮更換邊緣設備的解決方案；
（2）網絡業務量：我們的網絡業務量很大，所以要考慮好大業務量下的問題；
（3）語音質量：此解決方案是否影響語音質量，增加時延或丟包率；
（4）運營投資：運營是否隨着規模增大，需要做大量投資；
（5）客戶投資：客戶是否需要做投資；
（6）兼容性：此解決方案是否只能在特定環境下生效，是否可以支持各種應用方案，是否可以穿越各種NAT和防火牆；
（7）擴展性：此方案是否支持大規模應用。
接觸到的所有產品情況
PortaSIP內置B2BUA，可以滿足我們的要求；
Cisco SIP Proxy Server無支持，需要自己架設STUN以及Outbound Proxy服務器，是否能夠滿足需要調研；
Nortel需要加Nortel專有的RTP proxy（使用RTP中繼方式實現），滿足我們的要求；
華爲的解決方案是使用ALG防火牆，滿足我們的要求，但需要做一些邊緣設備的升級；
我們自己的試驗平臺，只能使用STUN或者Outbound Proxy。
SER，可以在PortaOne網站免費下載PortaOne nathelper RTP proxy來解決這個問題（使用RTP中繼方式實現）。