摘  要： 為了解決傳統(tǒng)的VOIP系統(tǒng)組網(wǎng)復雜、靈活性不佳的問題，對目前的SIP技術和STUN技術進行了研究。利用STUN技術解決了內(nèi)網(wǎng)IP端口到公網(wǎng)IP端口轉換問題。以開源Lumisoft  SIP為核心，結合RTP/RTCP相關技術，設計了一種基于SIP協(xié)議的VOIP UA用戶代理系統(tǒng)模型。實現(xiàn)了通過訪問網(wǎng)絡上的SIP用戶代理或者SIP音樂服務器，為網(wǎng)絡用戶提供便捷的網(wǎng)絡語音、音樂點播等服務。實驗表明，基于SIP的VOIP網(wǎng)絡結構更簡單，更靈活。
關鍵詞： 網(wǎng)絡語音通信；會話初始協(xié)議；NAT的UDP穿越；信號傳輸；通信軟件開發(fā)

    會議初始協(xié)議SIP(Session Initiation Protocol)是下一代網(wǎng)絡中的重要協(xié)議之一，是NGN領域研究的熱點。傳統(tǒng)的多媒體網(wǎng)絡通信基于H.323系列，它詳細說明了一系列在Internet上進行多媒體通信的協(xié)議和流程，比較成熟，但是組網(wǎng)復雜，靈活性不佳。相比于H.323而言，SIP主要有以下三點優(yōu)勢：(1)從編碼格式的角度來看， SIP采用文本編碼格式，易于解析和調(diào)試，實現(xiàn)起來簡單容易。(2)從可擴展性的角度來看，H.323的網(wǎng)關和網(wǎng)守必須在呼叫期間保存呼叫的相關信息，并使用TCP傳輸，需要保存連接狀態(tài)，大大地限制了它所支持的網(wǎng)絡規(guī)模。而SIP協(xié)議報文包含了相關操作的必要信息，實體可以無狀態(tài)地工作，不需要呼叫信息并且SIP支持UDP方式，無需保存連接狀態(tài)。大規(guī)模應用時， H.323會議中的集中式多點控制單元會形成瓶頸，從而影響系統(tǒng)的性能。(3)從移動性的角度來看，SIP同時通過代理和重定向功能來支持用戶移動性，而H.323在這方面的性能較欠缺[1]。
    在本實驗中，主要與SDP(Session Description Protocol)、RTP(Real-time Transport Protocol)、UDP等協(xié)議一起構建了完整的音頻通信系統(tǒng)，如圖1所示。本地UA端通過訪問其他SIP的UA端或者SIP音樂服務器，實現(xiàn)語音通信和網(wǎng)絡音樂點播的功能。

1 SIP組網(wǎng)模型簡介
    SIP網(wǎng)絡中有兩個要素：SIP用戶代理(UA)和SIP網(wǎng)絡服務器。UA主要由負責發(fā)起SIP請求的用戶代理端(UAC)和負責對呼叫請求做出響應的用戶代理服務端(UAS)組成。
    SIP網(wǎng)絡服務器主要由注冊服務器(Register Server)、代理服務器(Proxy Server)、位置服務器(Location Server)和重定向服務器(Redirect Server)組成。Register Server用于保存用戶數(shù)據(jù)，為用戶提供注冊服務，和代理服務器一起為用戶提供定位服務。SIP Proxy Server主要負責提供路由功能，根據(jù)被叫用戶的網(wǎng)絡地址，負責將SIP用戶請求和響應轉發(fā)到響應的下一跳。Location Server可以與SIP網(wǎng)絡服務器結合，存儲用戶注冊信息和IP地址映射表，提供地址查詢服務。Redirect Server提供解析地址服務，類似于DNS，可以將UA目的地址映射成相應格式的用戶名[2]。
2 基于SIP的VOIP UA系統(tǒng)的設計
2.1 系統(tǒng)的整體分析
    要實現(xiàn)一個網(wǎng)絡音頻通信系統(tǒng)，首先初始化系統(tǒng)的音頻輸入輸出設備；然后建立Call，在得到對方確認后，開始實時語音的采集、處理與播放，并且進行可靠地傳送和接收，這樣PC之間就可以實現(xiàn)音頻通信；最后通話結束，摘除Call。呼叫的建立可以通過SIP協(xié)議的信令來實現(xiàn)。音頻傳輸采用RTP協(xié)議，因為RTP建立于UDP之上，能自動處理分組丟失和交付失序的問題，從而可以確保音頻數(shù)據(jù)以正確的次序提交給用戶。另外，RTP還有一個伴隨協(xié)議RTCP，這個協(xié)議主要為會話提供大量的可供交換的信息和關于會話質(zhì)量的反饋信息。
    該UA系統(tǒng)主要分為用戶界面層、模塊接口層、功能實現(xiàn)層以及底層。其中用戶界面層基于VS2010C#開發(fā)，包含了程序的入口函數(shù)，為應用程序提供交互的圖形界面，并且確定了應用程序的整體框架結構；模塊接口層是由軟件中所調(diào)用的各個模塊的接口函數(shù)組成的；主要屏蔽了所有調(diào)用下層模塊的細節(jié)，提供一些簡單的類，便于用戶界面層的控件的回調(diào)函數(shù)調(diào)用，來完成具體的注冊、call或者call incoming等具體功能；功能實現(xiàn)層是由SIP用戶代理模塊、媒體流處理模塊、系統(tǒng)配置模塊和網(wǎng)絡配置模塊構成；底層主要提供媒體處理流處理提供相應的接口。
2.2 UA間的會話過程
    一個成功的SIP UA間的呼叫主要由INVITE和ACK組成。首先利用UA1發(fā)送INVITE消息邀請UA2加入會話，同時在請求的末尾包含一條SDP會話的描述，其中包含了音頻編碼格式等一系列的媒體信息參數(shù)。UA2收到該邀請消息后，回復一條Trying消息給UA1，表示其已經(jīng)收到該請求，并且正在處理這個請求。此時UA2端提醒有一條來自UA1的呼叫（振鈴提醒），接著返回給 UA1 Ringing響應。UA1收到Ringing時，可以通過鈴聲的形式提醒UA1。當UA2確認接通后，向UA1發(fā)送OK的響應消息后，停止振鈴提醒，在OK的消息體中包含了SDP媒體描述。UA1收到OK的響應后，停止鈴聲提醒，并且向UA2發(fā)送ACK確認消息。在UA2收到ACK消息后，雙方開始多媒體對話。通話結束后，假設UA2先摘機，則UA2向UA1發(fā)送BYE消息，UA1收到BYE后，向UA2發(fā)送OK響應消息，本輪通話結束。UA之間的會話過程如圖2所示[3]。

2.3 STUN技術和實驗分析
    STUN(Simple Traversal of UDP Through NAT)是由IETF研制的一種UDP對NAT的穿越方式。STUN技術可以穿越大部分的NAT，并且無需改變現(xiàn)有的NAT設備。其主要思想就是私網(wǎng)中的PC終端先通過和公網(wǎng)上的STUN服務器通信，利用STUN服務器返回的信息判斷其本地NAT的類型，采用相應的NAT穿越方法，最終獲得本地端口在公網(wǎng)上的IP地址和端口[4]。
    判斷NAT類型在實現(xiàn)STUN的穿越功能時非常重要，STUN_Client首先要判斷本地NAT的類型，針對其類型采用相應的映射方法，才能保證UDP數(shù)據(jù)包可以順利地到達目的網(wǎng)絡地址完成通信。根據(jù)NAT對UDP處理的不同實現(xiàn)方式，目前分為四種類型：(1)完全映射:完全映射的NAT是指所有的來自內(nèi)部網(wǎng)同一個IP地址和端口的請求報文，都被映射到同一個外部網(wǎng)IP和端口。任何一個外部的主機可以發(fā)送消息到內(nèi)部的主機，只要發(fā)送到其映射的外部IP和端口即可。(2)限制映射：與完全映射一樣，但一個外部主機（IP地址為U）要發(fā)送消息包給內(nèi)部主機，需要該內(nèi)部主機先發(fā)送消息包給IP地址U作為前提。(3)端口限制映射：端口限制映射與限制映射類似，只是限制的內(nèi)容包括了端口號。(4)對稱映射：一個映射的NAT是指來自內(nèi)部的IP和端口，發(fā)送到同一個IP和端口的請求報文，都將被映射到同一個外部的IP地址和端口。如果內(nèi)部主機的IP地址和端口相同，但是目標地址和端口不同，將會有不同的映射方式，而且只有收到內(nèi)部網(wǎng)消息的外部主機，才能夠發(fā)送消息給內(nèi)部主機。根據(jù)NAT類型可以得出STUN可以解決前三種NAT的穿越，對于第四種，如果通信端處于對成型NAT后，將不能實現(xiàn)穿越，需要采取服務器轉發(fā)等形式才能實現(xiàn)[5]。
    實驗中用了Wire Shark抓包，分析其中一個IP端口的STUN協(xié)議包如圖3所示。通過STUN服務器發(fā)送的數(shù)據(jù)包可以看出本地的IP和端口 是192.168.1.110:21240，STUN服務器的IP地址和端口號是213.192.59.93:3479。通過STUN服務器返回的數(shù)據(jù)包可以得到本地私網(wǎng)的IP地址以及端口號對應的公網(wǎng)上的IP地址和端口號為117.63.181.58:55012。

2.4 RTP/RTCP技術和實驗數(shù)據(jù)包分析
    RTP是用于英特網(wǎng)上針對多媒體數(shù)據(jù)流傳輸?shù)囊环N協(xié)議，例如音頻和視頻等具有實施性質(zhì)的數(shù)據(jù)提供端到端的傳輸服務。RTP可以在一對一或者一對多的傳輸情況下工作。其主要作用是提供時間和流的同步。RTP通常使用UDP傳輸數(shù)據(jù)。一個RTP會話將使用兩個端口，一個給RTP另一個給RTCP。RTP負責媒體數(shù)據(jù)的實時傳輸，RTCP負責反饋控制，傳輸檢測。RTP自身并不提供任何保證及時傳輸?shù)臋C制，也不保證其他服務的質(zhì)量，但是可以依賴底層服務進行。它并不保證網(wǎng)絡可靠或者預防無序傳輸，它依靠RTCP監(jiān)控數(shù)據(jù)傳輸質(zhì)量，進行自適應調(diào)整。RTP中包含了序列號，允許接收者重組數(shù)據(jù)包[6]。
    在本實驗系統(tǒng)中，通過RTP/RTCP實現(xiàn)數(shù)據(jù)流封包發(fā)送給下層，依托UDP傳輸，保證網(wǎng)絡的傳輸速度，RTP傳輸?shù)木W(wǎng)絡數(shù)據(jù)包如圖4所示。通過RTP數(shù)據(jù)序列號，使接收端根據(jù)序列號進行排序，保證數(shù)據(jù)流有序播放。RTP/RTCP有效地解決了UDP傳輸?shù)臄?shù)據(jù)包的無序性。在RTP會話期間，參與者周期性地發(fā)送RTCP包。RTCP包中含有已經(jīng)發(fā)送的數(shù)據(jù)包的數(shù)量、丟失的數(shù)據(jù)包的數(shù)量等統(tǒng)計資料。因此，RTP和RTCP配合使用，通過有效的反饋和最小的開銷，使網(wǎng)絡的傳輸效率最佳化，與UDP配合特別適合傳輸網(wǎng)絡上的實時數(shù)據(jù)。

3 本地UA系統(tǒng)的工作流程和設計
    本地UA系統(tǒng)的工作流程主要分為三塊：設備和協(xié)議的初始化、呼叫按鈕的觸發(fā)事件以及外來呼叫邀請的Callback事件。
    首先主要是協(xié)議初始化和設備初始化，本系統(tǒng)采用Lumisoft SIP開源協(xié)議，該協(xié)議主要針對C#的編程環(huán)境，主要提供了SIP的一些接口函數(shù)，可以直接調(diào)用，自己可以根據(jù)需要組合出相應的SIP協(xié)議棧。初始化一個SIP棧類并且綁定相應的套接字端口，然后定義收到SIP消息時要觸發(fā)的事件以及其相應的處理函數(shù)。部分關鍵代碼如下：
    m_pStack = new SIP_Stack();//初始化SIP類
    m_pStack.UserAgent="Lumisoft SIP Stack 1.0";
    m_pStack.BindInfo=new IPBindInfo[]{new IPBindInfo("
    ",BindInfoProtocol.UDP,IPAdress.Any.m_SipPort)}//綁定
    SIP的IP和端口
    m_pStackReceived +=new EventHandler
    <SIP_RequestReceivedEventArgs>(m_pStack_
RequestReceived);//觸發(fā)事件的聲明
    m_pStack.Start();//開啟SIP Stack
    呼叫按鈕的觸發(fā)事件是本系統(tǒng)中由用戶觸發(fā)的模塊。其主要分為創(chuàng)建RTP會議，提供SDP，綁定本地IP地址和端口，創(chuàng)建SIP消息并發(fā)送。消息體中包含了SDP信息，描述了多媒體通信的相關信息。本實驗的SIP會話的INVITE消息分析如圖5所示。

    外來呼叫邀請的Callback事件主要修改當前的SIP協(xié)議的會話狀態(tài)(register、invite、ring、ok等)。當狀態(tài)變化時，觸發(fā)事件處理函數(shù)，產(chǎn)生相應的SIP消息發(fā)送。部分關鍵代碼如下：
    Public wfrm_IncomingCall(SIP_ServerTransaction invite)
    {...
    InitUI();//初始化UI界面
    m_pTransaction=invite;
    m_pTransaction,Canceled+=new
    EventHandler(m_pTransaction_canceled);}
//SIP狀態(tài)變化觸發(fā)函數(shù)的定義
    Private void m_pTransaction_canceled
    (objectsender,EventArgs e){...}//定義SIP消息狀態(tài)
變化的處理函數(shù)，產(chǎn)生SIP代碼并發(fā)送
4 基于SIP協(xié)議的用戶代理UA系統(tǒng)的實現(xiàn)
    本系統(tǒng)在Windows平臺下，以.NET Framework和LumiSoft為開發(fā)工具完成，通過開發(fā)設計，最后的系統(tǒng)運行界面如圖6所示。本系統(tǒng)將SIP協(xié)議、STUN、RTP/RTCP協(xié)議等結合到一起，應用界面簡潔清楚、使用方便。軟件開啟，只要輸入本地用戶名和遠端UA用戶名，或者SIP服務器名稱，點擊CALL按鈕就可以直接和網(wǎng)絡上的SIP的UA端進行語音通話，或者訪問特定的SIP音樂服務器，收聽音樂。為后續(xù)實現(xiàn)基于SIP協(xié)議的視頻會議研究奠定了良好的基礎。通過本實驗得到結論：基于SIP的多媒體通信組網(wǎng)構建比H.323靈活，通過簡單的SIP信令的對話就可以快速實現(xiàn)多媒體通信，并且SIP協(xié)議基于文本格式，相對于H.323更加簡單易懂。

    本文基于SIP協(xié)議的音頻通信的UA系統(tǒng)的項目研發(fā)實踐，詳細地闡述了基于SIP的VOIP的UA的設計和所涉及的關鍵技術和難點。對于本系統(tǒng)，提出幾點不足及后續(xù)研究應該改進的方向：首先沒有完善SIP服務器的注冊機制；其次STUN技術對于在對稱型NAT之后的UA無法實現(xiàn)穿越，需要結合服務器轉發(fā)等形式加以彌補。隨著SIP技術的廣泛應用，相信未來基于SIP多媒體會話技術將會有更好的發(fā)展和更廣泛的市場。
參考文獻
[1] 張智云.SIP協(xié)議及其應用[M].北京：電子工程出版社，2005：89-93.
[2] 杜吉友，董德存．基于SIP的多媒體通信系統(tǒng)安全技術[J]．數(shù)據(jù)通信，2004，10(2)：340-350.
[3] 范文，梁滿貴.基于oSlP協(xié)議棧的用戶代理的設計與實現(xiàn) [J]．微計算機信息，2007，23(21)：15-16.
[4] 嚴軍.NGN網(wǎng)絡業(yè)務穿越NAT探討[J].世界電信，2003(11)：110-130.
[5] ROSENBERG J.J WEINBERGER.STUN-Simple traversal of  user datagram protocol through net work address translators (NATs)[S].RFC3489，2003.
[6] SCHULZRINNE H，CASMER S，F(xiàn)REDERICK R，et al.RTP：a transport protocol for real-time applications[S].RFC3550，2003.
[7] LumiSoft.net.help[EB].http：//www.lumisoft.ee/lswww/download/downloads/Net/Help/Index.aspx，2008.