引言

隨著軟交換網(wǎng)絡逐步從試驗走向商用，軟交換網(wǎng)絡的業(yè)務應用也逐漸被人們所關注。軟交換業(yè)務的最大優(yōu)勢在于其可為用戶提供豐富的業(yè)務，特別是為企業(yè)用戶提供語音、數(shù)據(jù)、視頻融合的業(yè)務。目前其走向成熟并商用的業(yè)務主要是在IP網(wǎng)上承載語音和視頻業(yè)務。即是多媒體通信系統(tǒng)標準H.323,SIP,MGCP協(xié)議運用于視頻會議和IP電話中。

1  網(wǎng)絡地址端口轉換（NAPT）技術簡介

在當今的網(wǎng)絡世界里，使用私有IP地址的網(wǎng)絡設備的數(shù)量要遠遠大于擁有合法IP地址的設備數(shù)量。為了能夠讓這些設備可以訪問私網(wǎng)外部的資源，NAT（網(wǎng)絡地址轉換）技術也就應運而生。當私網(wǎng)內(nèi)部設備試圖訪問外部網(wǎng)絡時，NAT技術就可以將其私有的IP地址轉換成合法的IP地址。NAT與PAT被同時使用，稱為網(wǎng)絡地址端口轉換（NAPT）。NAPT的運用，緩解了IPv4構架下Internet網(wǎng)絡的IP地址緊張問題，提高私有網(wǎng)絡內(nèi)部的安全性和可管理性。因此.NAPT被大量運用到各種私網(wǎng)網(wǎng)關設備上，它是絕大多數(shù)網(wǎng)絡路由器設備的一個基本功能，也是網(wǎng)絡防火墻功能的重要組成部分。

2  NAPT對軟交換的影響

2.1  NAT問題

圖1所示是一個軟交換網(wǎng)絡示意圖?，F(xiàn)在假設有一個如圖1所示的軟交換網(wǎng)絡,在這個網(wǎng)絡中，終端A與終端B在私網(wǎng)內(nèi)，只有私網(wǎng)IP地址，而終端C具有獨立的合法IP地址。為了便于描述，假設所有終端都是SIP終端，軟交換與終端間的通訊也釆用標準的SIP協(xié)議。這樣,若終端A向終端B發(fā)起呼叫請求，則會產(chǎn)生一個如圖2所示的消息包，這個消息包在經(jīng)過路由器的NAPT后，會變成圖3所示的消息包，其中1050為NAPT動態(tài)分配的端口號。

由于終端B在向軟交換注冊時，通過SIP協(xié)議層的注冊消息告訴軟交換的是它的私有地址,并且在終端B沒有主動對外發(fā)起連接請求時，防火墻不會為其分配可被訪問的IP地址和端口號，因此，軟交換根本無法將INVITE消息發(fā)送給終端B,因而呼叫無法接續(xù)。

2.2  PAT問題

假設由終端A向終端C發(fā)起呼叫，此時，由于終端C上面沒有防火墻或路由器，軟交換就可以順利地把INVITE消息包轉發(fā)到終端C,這個消息中攜帶有SDP信息,可用于終端間的媒體協(xié)商。媒體協(xié)商的主要目的是選擇合適的編解碼器，并建立RTP媒體流的連接。由終端A發(fā)送的INVITE消息中攜帶的SDP信息內(nèi)容如圖4所示，其中10006是終端A建立RTP連接的端口號。

當終端C收到SDP信息后，它將試圖與192.168.0.3：10006建立RTP連接,很明顯，這是一個私網(wǎng)內(nèi)部的地址，因此，通話也自然無法建立起來。

從以上分析可以看出,NAPT影響軟交換通信主要有兩方面:一方面，私網(wǎng)內(nèi)設備都采用內(nèi)部IP地址，雖然經(jīng)過NAPT可以將IP層的地址轉換為外部地址，但是對更上面的應用層消息中的私有IP地址卻無能為力（稱作NAT問題）；另一方面，私網(wǎng)設備只是在向外部主動發(fā)起連接時，才會被分配到合法IP和端口號。若不做特殊處理，設備對外部網(wǎng)絡來說是不可見的，也無法接受軟交換發(fā)來的呼叫請求（這個可以稱作PAT問題）?；赟IP協(xié)議的問題如此，當軟交換與終端間使用其它協(xié)議（如H.323,MGCP或H.248協(xié)議）時，類似的問題也同樣存在。

2.3  防火墻和NAT對IP語音和視頻通訊的阻礙

基于IP的語音和視頻通訊協(xié)議（如H.323等），要求終端之間使用IP地址和數(shù)據(jù)端口來建立數(shù)據(jù)通信通道。這樣，為了建立數(shù)據(jù)連接終端，必須隨時偵聽外來的呼叫，而防火墻卻通常被配置成阻止任何不請自到的數(shù)據(jù)包的通過。

即使網(wǎng)絡管理者打開防火墻上的一個端口來接收呼叫建立數(shù)據(jù)包，例如1720端口，但IP語音和視頻通訊協(xié)議還要求打開許多別的端口接收呼叫控制信息來建立語音和視頻通道，這些端口號事先并不知道，系統(tǒng)是動態(tài)分配的，這也就是說，網(wǎng)絡管理者為了允許語音和視頻通訊將不得不打開防火墻上所有的端口，防火墻也就失去了存在的意義。由于網(wǎng)絡安全的原因，幾乎所有企業(yè)都不會讓他們的網(wǎng)絡防火墻如此開放。

基于目前情況，業(yè)界常用的解決方案有:NAT/ALG方式、MIDCOM方式、STUN方式、TURN方式、Full Proxy方式和SBC等六種。

下面針對企業(yè)網(wǎng)、駐地網(wǎng)小區(qū)用戶接入軟交換網(wǎng)絡解決方案，對上述幾種方式進行簡單介紹和分析。

3  方案分析

3.1  NAT/ALG方式

普通NAT通常通過修改UDP或TCP報文頭部地址信息來實現(xiàn)地址的轉換,但部分承載于TCP/UDP的應用，例如多媒體會話、文件共享、游戲等“端到端”的應用，在TCP/UDP負載中也需帶地址信息。一般的方法中，應用程序在負載中填寫的是自身地址，此地址信息在通過NAT時被修改為NAT上對外的地址，即我們常說的ALG方式。

ALG功能目前主要駐留在一些NAT/Firewall設備中，要求這些設備本身具備應用識別的智能，同時每增加一種新的應用，都需要對NAT/Firewall進行升級。

對于軟交換業(yè)務應用,ALG需要支持IP語音和視頻協(xié)議（H323、SIP、MGCP/H248）的識別和對NAT/Firewall的控制，以使軟交換業(yè)務順利穿透NAT/Firewall

對于ALG應用來說，在應用業(yè)務安全要求上需要作一些折衷，因為ALG不能識別加密后的報文內(nèi)容，所以必須保證報文采用明文傳送，這使得報文在公網(wǎng)中傳送時有很大的安全隱患。

3.2  MIDCOM方式

與NAT/ALG不同的是,MIDCOM的框架結構是采用可信的第三方（MIDCOMAgent）對Middle-box（NAT/FW）進行控制的機制，應用業(yè)務識別的智能也由Middlebox轉移到外部的MIDCOMAgent上，因此，應用協(xié)議對Middlebox是透明的。

由于應用業(yè)務識別的智能可以從Middlebox移到外部的MIDCOMAgent上，根據(jù)MIDCOM的架構，在不需要更改Middlebox基本特性的基礎上，通過對MIDCOMAgent的升級就可以支持更多的新業(yè)務,這是NAT/ALG方式的一個優(yōu)勢。

在軟交換業(yè)務實際應用中，Middlebox功能可駐留NAT/Firewall,因此，通過軟交換設備（即MID-COMAgent）對IP語音和視頻協(xié)議（H323、SIP、MGCP/H248）的識別和對NAT/Firewall的控制，就可以作為軟交換業(yè)務穿越NAT/Firewall的一個解決方案。

出于安全性考慮,MIDCOM方式可支持控制報文的加密，也可支持媒體流的加密，因此，其安全性比較高。

由于軟交換設備已實現(xiàn)了對SIP/H323/MGCP/H248協(xié)議的識別，只需在軟交換和NAT/FW設備上增加MIDCOM協(xié)議即可，而且以后新的應用業(yè)務識別隨著軟交換的支持而支持，因此，這種方案是一種比較有前途的解決方案。但是，現(xiàn)有的NAT/FW設備需要升級支持MIDCOM協(xié)議。

3.3  STUN方式

解決軟交換NAT問題的另一思路是私網(wǎng)接入用戶可通過某種機制預先得到其地址對應的、在出口NAT上的對外地址，然后在報文負載中所描述的地址信息直接填寫出口NAT上的對外地址，而不是私網(wǎng)內(nèi)用戶的私有IP地址，這樣，報文負載中的內(nèi)容在經(jīng)過NAT時就無需被修改了，只需按普通NAT流程轉換報文頭的IP地址即可，負載中的IP地址信息和報文頭地址信息是一致的。STUN協(xié)議就是基于此思路來解決應用層地址的轉換問題。

STUN的全稱是Simple Traversal of UDP Through Network Address Translators,即UDP對NAT的簡單穿越方式。應用程序（即STUN CLI-ENT）向NAT外的STUN SERVER可通過UDP發(fā)送請求STUN消息,STUN SERVER收到請求消息后將產(chǎn)生響應消息，響應消息中攜帶請求消息的源端口，即STUN CLIENT在NAT上對應的外部端口。然后，響應消息通過NAT發(fā)送給STUN CLI-ENT,STUN CLIENT通過響應消息體中的內(nèi)容得知其在NAT上對應的外部地址，并且將其填入以后呼叫協(xié)議的UDP負載中并告知對端，本端的RTP接收地址和端口號為NAT外的地址和端口號。由于通過STUN協(xié)議已在NAT上預先建立了媒體流的NAT映射表項,故媒體流可順利穿越NAT。

STUN協(xié)議最大的優(yōu)點是無需現(xiàn)有NAT/FW設備做任何改動。由于實際的網(wǎng)絡環(huán)境中已有大量的NAT/FW,并且這些NAT/FW并不支持VoIP的應用，因此，如果用MIDCOM或NAT/ALG方式來解決此問題，需要替換現(xiàn)有的NAT/FW,故是不太容易的。而采用STUN方式無需改動NAT/FW,這是其最大優(yōu)勢，同時-STUN方式可在多個NAT串聯(lián)的網(wǎng)絡環(huán)境中使用，而MIDCOM方式無法實現(xiàn)對多級NAT的有效控制。

STUN的局限性在于需要應用程序支持STUNCLIENT的功能，即軟交換的網(wǎng)絡終端需具備STUNClient功能。同時STUN并不適合支持TCP連接的穿越，因此不支持H323應用協(xié)議。另外，STUN方式也不支持軟交換業(yè)務對防火墻的穿越，同時，STUN方式不支持對對稱NAT（SymmetricNAT）類型的穿越，例如在安全性要求較高的企業(yè)網(wǎng)中，出口NAT通常就是這種類型。

3.4  TURN方式

TURN方式解決NAT問題的思路與STUN相似,也是基于私網(wǎng)接入用戶通過某種機制預先得到其私有地址對應在公網(wǎng)的地址（STUN方式得到的地址為出口NAT上的地址,TURN方式得到地址為TURNServer上的地址），然后把報文負載中所描述的地址信息直接填寫在該公網(wǎng)地址的方式，其實際應用原理也是一樣的。

TURN的全稱為TraversalUsingRelayNAT,即通過Relay方式穿越NAT,TURN應用模型通過分配TURNServer的地址和端口來作為客戶端對外的接受地址和端口，即私網(wǎng)用戶發(fā)出的報文都要經(jīng)過TURNServer進行Relay轉發(fā),這種方式的應用模型除了具有STUN方式的優(yōu)點外，還解決了STUN應用無法穿透對稱NAT（SymmetricNAT）以及類似的Firewall設備的缺陷，即無論企業(yè)網(wǎng)/駐地網(wǎng)出口為哪種類型的NAT/FW,都可以實現(xiàn)NAT的穿透，同時,TURN可支持基于TCP的應用（如H323協(xié)議）。此外TURNServer可控制分配地址和端口，并能分配RTP/RTCP地址對（RTCP端口號為RTP端口號加1）作為本端客戶的接受地址，從而避免了STUN應用模型下出口NAT對RTP/RTCP地址端口號的任意分配，這樣，客戶端將無法收到對端發(fā)過來的RTCP報文（對端發(fā)RTCP報文時，目的端口號缺省按RTP端口號加1發(fā)送）。

TURN的局限性在于其需要終端支持TURN-Client,這一點同STUN一樣，也對網(wǎng)絡終端有要求。此外，所有報文都必須經(jīng)過TURNServer轉發(fā)，因而,增大了包的延遲和丟包的可能性。

3.5  FullProxy方式

FullProxy是另外一種解決NAT問題的思路，它通過對私網(wǎng)內(nèi)用戶呼叫的信令和媒體同時做Re-lay來實現(xiàn)出口NAT/FW的穿越，F(xiàn)ullproxy與TURN方式的Relay相比，區(qū)別如下：

首先,TURN方式是在TURNServer與終端通過TURN/STUN協(xié)議交互時分配地址和端口，報文內(nèi)部的地址信息由終端生成,TURNServer對后續(xù)的報文根據(jù)分配的地址和端口信息做地址變換后Re-lay轉發(fā);而FullProxy方式是通過對報文進行Relay的設備對呼叫協(xié)議進行解析與處理來改寫其中攜帶的RTP/RTCP地址信息后轉發(fā)信令報文，同時根據(jù)改寫的RTP/RTCP地址信息對媒體報文做地址變換后進行Relay轉發(fā)。原理在于當私網(wǎng)終端呼叫信令到達FullProxy時,FullProxy將對呼叫信令協(xié)議進行解析，并對協(xié)議中攜帶的RTP/RTCP信息進行解析與處理，然后在記錄用戶私網(wǎng)內(nèi)RTP/RTCP地址和端口號的同時，修改RTP/RTCP私網(wǎng)地址信息為FullProxy本身對外的公網(wǎng)IP地址，同時修改媒體流端口為FullProxy上分配的外部端口，最后將呼叫信令發(fā)送到軟交換或對端。這樣，呼叫信令以及媒體流就可以通過FullProxy在主被叫之間進行中轉。由于FullProxy可以配置多個IP地址（如一個私網(wǎng)IP地址和一個公網(wǎng)IP地址），因此通過FullProxy進行Relay,其軟交換業(yè)務就可順利通過NAT/FW.

FullProxy方式無需現(xiàn)有NAT做任何改動即可開展軟交換業(yè)務,也可采用普通的設備，同時私網(wǎng)內(nèi)的終端也無需支持STUN和TURN協(xié)議，這是其一個較大的優(yōu)勢。其局限性同TURN一樣，也是增加了包的延時和丟包的可能性。

由于FullProxy方式會對呼叫協(xié)議進行解析，因此,除了可以處理NAT問題外，還可完成對每次呼叫帶寬等QoS信息的解析與處理，從接入層保證QoS的安全問題。此外，通過對呼叫狀態(tài)的把握，可實現(xiàn)對媒體流的動態(tài)防火墻，保證網(wǎng)絡安全和防止帶寬盜用等。因此,FullProxy模型可以成為軟交換終端接入層NAT,QoS和安全的統(tǒng)一處理平臺。

在應用領域，由于FullProxy的配置很靈活，組網(wǎng)應用也很靈活，它除了實現(xiàn)私網(wǎng)地址向公網(wǎng)地址的轉換外，還可同時實現(xiàn)公網(wǎng)地址向私網(wǎng)地址的轉換，或其它不同地址域之間的變換，以便滿足軟交換不同場合下的組網(wǎng)應用。

3.6  SBC（Session Border Controller）方式

SBC本身可以被看作支持VoIP的Proxy,它是一種“可識別應用層”的設備，可以識別第五層和第七層的消息，并且可以處理第五層的眾多會話信令協(xié)議,修改數(shù)據(jù)包頭的地址，從而實現(xiàn)SBC內(nèi)、外網(wǎng)地址和變換。

SBC可以用于協(xié)助VoIP穿越遠端防火墻/NAT設備。它一般放置在網(wǎng)絡核心交換設備之側。所有經(jīng)過SBC的信令和媒體流經(jīng)過SBC的協(xié)調和修改，均可以在系統(tǒng)側和用戶側正確傳輸。用戶側的NAT/Firewall可以接受這種修改后的信令和媒體流并把他們傳送到用戶側的內(nèi)網(wǎng)。這種利用SBC實現(xiàn)的防火墻穿越技術可以稱之為“遠端防火墻穿越”。

SBC還可以幫助SIP/MGCP信令穿越已經(jīng)存在的FW/NAT,而不需要對現(xiàn)有的FW/NAT設備做任何改變。具體來說，對于SIP終端,SIP終端設備會周期性發(fā)注冊消息到SBC；而對于MGCP終端，當收到MGCP設備的第一個注冊消息后，SBC會周期性發(fā)AUEP消息到終端，以強制其再不停的周期性回復200OK消息。這樣，由于不停的有信令消息經(jīng)過防火墻/NAT設備，可能使防火墻/NAT對通過的消息流始終保持一個確定的端口；同時，當注冊信息經(jīng)過SBC時，它將記錄在防火墻上的第三層IP地址和端口等信息,并且將此信息與防火墻后面的終端用戶名或電話號碼等第五層信息進行綁定記錄。這樣，當一個信令到來后，SBC將通過防火墻上正確的地址和端口發(fā)送給被叫方。