概述

近年來，隨著網絡向分組化方向發展，VOip、軟交換等技術開始越來越多地應用于網絡。這些新技術在為用戶帶來更多服務選擇的同時，自身也面臨許多需要解決的問題，網絡中大量使用私有IP地址就是其中之一。 

1、問題的產生

先來簡單介紹一下軟交換系統的用戶接入方式。從軟交換機放置的等級區分，大致可分兩類：(1)通過PSTN接入，軟交換機位于匯接局/長途局；(2)通過IP網接入，軟交換機相當于本地端局，如圖1所示。   

軟交換用戶接入方式

第一種接入方式，通過原有的PSTN交換機接入，和傳統方式相比用戶側沒有任何變化，也不存在IP地址問題；第二種接入方式(包括IP-IP、IP-PSTN等)，IP多媒體用戶通過IP網接入，必須分配IP地址。由于IPv4本身地址空間有限，且分配不均，隨著互聯網用戶的飛速發展，IP地址匱乏情況越來越嚴重，因此運營商、企業用戶等大量采用私有IP地址。據估計目前網上使用私有IP地址的設備數量遠遠超過使用合法IP地址的設備數量。

這些私網用戶在訪問公網時，一般采用NAT+PAT技術來解決地址轉換問題。當私網內部設備試圖訪問外部網絡時，NAT(網絡地址轉換)技術可將其私有的IP地址轉換成合法的IP地址。動態的端口轉換(PAT)技術可解決合法IP地址緊缺的問題，PAT將私有地址+TCP/UDP端口轉換并為一個合法地址+一個TCP/UDP端口，這樣可有多個私有地址對應一個合法地址，用不同的TCP/UDP端口進行區分。NAT與PAT通常被同時使用，稱為網絡地址端口轉換(NAPT)。

NAPT一般只完成IP層地址的轉換，而軟交換協議(如H.323、SIP、MGCP等)需要依靠封裝在高層的地址信息完成通信。一方面，由于NAPT不能相應地修改這些封裝在協議包內的地址，使軟交換系統無法獲得終端正確的地址信息，結果造成無法建立通信；另一方面，私網設備只有在向外部主動發起連接時，才會被分配到合法IP和端口號。若不做非凡處理，設備對外部網絡來說是不可見的，也無法接受軟交換發來的呼叫請求。 

目前業界有多種解決私網穿越的方案。完善的方案應能解決私網穿越中可能碰到的各種問題，如NAT、PAT、對稱NAT(Symmetric NAT)、防火墻等，另外在建設時對現有IP承載網和軟交換系統的影響要盡可能小。本文介紹兩種被多數廠家采用，并已有成熟產品的方案：ALG和SBC。

2、ALG解決方案 

ALG(應用層網關，application Layer Gateway)要求設備有識別應用程序的功能。在軟交換系統中，ALG需要支持IP語音和多媒體協議(H.323、SIP、MGCP/H.248)。ALG方案的組網模型見圖2。  

ALG組網方案

以SIP協議為例，簡述ALG工作原理(MGCP、H.248和H.323情況類似)。假設圖2中終端A、C都是SIP終端，軟交換機是SIP代理。位于私網的終端A用戶通過公網的SIP代理向終端C發出INVITE請求，并創建相應的SDP消息體。當消息通過ALG時，ALG會分析IP包頭、UDP包頭及SIP/SDP消息體，并用ALG外部端口的合法IP地址和臨時分配的UDP端口號來替換相應的終端A的私網地址和端口號。如表1所示。 

ALG網關將轉換后的消息發往SIP代理(軟交換)，呼叫接續流程的其它信令消息、轉換方式與INVITE類似。SDP描述中RTP信息也相應被ALG修改，這樣，參與通信的終端都能獲得正確的IP地址和端口信息。如圖2所示，當呼叫建立后，終端A、C間的RTP媒體流通過ALG事先分配的端口建立連接。 

另外，假如ALG判定出兩臺終端在同一私網內(如圖2中終端A、終端B)，將不對IP包做修改，終端A、B可直接用自己的私有地址建立RTP連接。 

ALG方式不需要對軟交換協議和終端做任何修改，是比較簡單的解決方式。在實際應用中，ALG可以是私網原有NAT/防火墻的一部分，也可是與原有NAT/防火墻并列的新增設備。本文建議采用后一種方式，這樣可以避免原有設備升級對網絡的影響，同時也便于軟交換系統的治理，尤其在IP承載網和軟交換系統由不同運營商所有的情況。不過，由于ALG放置在客戶端，在軟交換大規模部署時，對現網改造的工作量還很大。另外，當有新的應用出現時，需要對所有ALG進行升級來支持新的應用協議。 

圖2所示的方案中，數據應用仍通過網絡中原有的NAT訪問互聯網，軟交換應用則通過ALG與公網連接。由于ALG本身可具有防火墻和高層安全應用功能，可以設置只答應通過軟交換消息和媒體流，只要選擇適當的ALG產品，采用這種建設方案并不會降低原有網絡的安全性。

3、SBC解決方案 

SBC(邊界會話控制器，session Border Controller)是目前主要的解決方案。與ALG設置在用戶側不同，SBC一般設置在軟交換側，該方案的優點是無需改動現有的NAT設備。 

SBC方案的組網模型參見圖3。  

SBC組網方案

不同廠商的系統呼叫流程可能不同，有的系統終端直接向SBC注冊，所有消息和媒體流都需要經SBC轉接；還有的系統則首先由軟交換來判定是否需要SBC介入。兩種方式SBC在地址轉換功能上工作原理大同小異，以下以第一種方式為例簡要介紹。 

當終端向軟交換注冊時，SBC會給每個終端分配一個信令代理端口，所有消息都會經過這個端口轉發給軟交換，同時SBC會用自身地址和這個端口來替換消息體中終端的地址信息。因此在軟交換系統中維護的用戶地址信息，實際上是SBC的地址和SBC分配給終端的端口號。 

如圖3所示，呼叫建立時，SBC會給終端分配一對RTP代理端口(收、發)，并以此替換SDP消息中對RTP接收端口的描述，再轉發給軟交換。即：每個終端收到的對方RTP信息實際上是SBC分配的RTP代理端口號，RTP流經SBC在兩個終端間建立連接。 

一般NAPT為私網終端分配的UDP端口有一定生命期(如40s)，因此SBC和終端間要有某種機制來保持這個端口始終對終端開放。如，SIP終端可定期向SBC發注冊信息；而對MGCP系統，軟交換收到終端RSIP消息后，可定期向終端發AUEP消息，強制終端回應，來保持NAPT上相應端口開放。 

由于所有消息和媒體流都是經過同一SBC轉接，這就解決了對稱NAT(Symmetric NAT)問題。 

需要指出，在軟交換系統中，SBC還可實現很多重要功能，如防止帶寬盜用、安全治理、QoS治理、合法監聽等，本文僅涉及其中的私網穿越功能。引入SBC可使軟交換系統更加完善，但也帶來了新問題：假如所有消息和媒體流都需要經過SBC轉接，似乎與軟交換呼叫控制與承載分離的設計思想不符，SBC有可能會成為整個系統的瓶頸。 

4、結束語 

業內還有其它解決私網穿越的方案，具體采用哪種方法，要綜合考慮承載網現狀、相關設備的成熟度、軟交換系統要實現的功能、規模等來確定。如上文提到的，這一問題的根源在于IPv4系統本身的限制，未來IPv6網絡將會從根據上解決這一問題，也將會給軟交換帶來更廣闊的發展空間。