基于SIP協議的VOIP用戶代理研究*

謝斌盛，唐作其，張正平

(貴州大學 計算機科學與信息學院，貴州 貴陽550025)

會議初始協議SIP(Session Initiation Protocol)是下一代網絡中的重要協議之一，是NGN領域研究的熱點。傳統的多媒體網絡通信基于H.323系列，它詳細說明了一系列在Internet上進行多媒體通信的協議和流程，比較成熟，但是組網復雜，靈活性不佳。相比于H.323而言，SIP主要有以下三點優勢：(1)從編碼格式的角度來看，SIP采用文本編碼格式，易于解析和調試，實現起來簡單容易。(2)從可擴展性的角度來看，H.323的網關和網守必須在呼叫期間保存呼叫的相關信息，并使用TCP傳輸，需要保存連接狀態，大大地限制了它所支持的網絡規模。而SIP協議報文包含了相關操作的必要信息，實體可以無狀態地工作，不需要呼叫信息并且SIP支持UDP方式，無需保存連接狀態。大規模應用時，H.323會議中的集中式多點控制單元會形成瓶頸，從而影響系統的性能。(3)從移動性的角度來看，SIP同時通過代理和重定向功能來支持用戶移動性，而H.323在這方面的性能較欠缺[1]。

在本實驗中，主要與SDP(Session Description Protocol)、RTP(Real-time Transport Protocol)、UDP 等 協 議 一 起構建了完整的音頻通信系統，如圖1所示。本地UA端通過訪問其他SIP的UA端或者SIP音樂服務器，實現語音通信和網絡音樂點播的功能。

圖1 音頻通信系統示意圖

1 SIP組網模型簡介

SIP網絡中有兩個要素：SIP用戶代理(UA)和SIP網絡服務器。UA主要由負責發起SIP請求的用戶代理端(UAC)和負責對呼叫請求做出響應的用戶代理服務端(UAS)組成。

SIP網絡服務器主要由注冊服務器(Register Server)、代理服務器(Proxy Server)、位置服務器(Location Server)和重定向服務器(Redirect Server)組成。Register Server用于保存用戶數據，為用戶提供注冊服務，和代理服務器一起為用戶提供定位服務。SIP Proxy Server主要負責提供路由功能，根據被叫用戶的網絡地址，負責將SIP用戶請求和響應轉發到響應的下一跳。Location Server可以與SIP網絡服務器結合，存儲用戶注冊信息和IP地址映射表，提供地址查詢服務。Redirect Server提供解析地址服務，類似于DNS，可以將UA目的地址映射成相應格式的用戶名[2]。

2 基于SIP的VOIP UA系統的設計

2.1 系統的整體分析

要實現一個網絡音頻通信系統，首先初始化系統的音頻輸入輸出設備；然后建立Call，在得到對方確認后，開始實時語音的采集、處理與播放，并且進行可靠地傳送和接收，這樣PC之間就可以實現音頻通信；最后通話結束，摘除Call。呼叫的建立可以通過SIP協議的信令來實現。音頻傳輸采用RTP協議，因為RTP建立于UDP之上，能自動處理分組丟失和交付失序的問題，從而可以確保音頻數據以正確的次序提交給用戶。另外，RTP還有一個伴隨協議RTCP，這個協議主要為會話提供大量的可供交換的信息和關于會話質量的反饋信息。

該UA系統主要分為用戶界面層、模塊接口層、功能實現層以及底層。其中用戶界面層基于VS2010C#開發，包含了程序的入口函數，為應用程序提供交互的圖形界面，并且確定了應用程序的整體框架結構；模塊接口層是由軟件中所調用的各個模塊的接口函數組成的；主要屏蔽了所有調用下層模塊的細節，提供一些簡單的類，便于用戶界面層的控件的回調函數調用，來完成具體的注冊、call或者call incoming等具體功能；功能實現層是由SIP用戶代理模塊、媒體流處理模塊、系統配置模塊和網絡配置模塊構成；底層主要提供媒體處理流處理提供相應的接口。

2.2 UA間的會話過程

一個成功的SIP UA間的呼叫主要由INVITE和ACK組成。首先利用UA1發送INVITE消息邀請UA2加入會話，同時在請求的末尾包含一條SDP會話的描述，其中包含了音頻編碼格式等一系列的媒體信息參數。UA2收到該邀請消息后，回復一條Trying消息給UA1，表示其已經收到該請求，并且正在處理這個請求。此時UA2端提醒有一條來自 UA1的呼叫（振鈴提醒），接著返回給 UA1 Ringing響應。UA1收到 Ringing時，可以通過鈴聲的形式提醒UA1。當UA2確認接通后，向UA1發送OK的響應消息后，停止振鈴提醒，在OK的消息體中包含了SDP媒體描述。UA1收到OK的響應后，停止鈴聲提醒，并且向UA2發送ACK確認消息。在UA2收到ACK消息后，雙方開始多媒體對話。通話結束后，假設UA2先摘機，則UA2向 UA1發送BYE消息，UA1收到BYE后，向UA2發送OK響應消息，本輪通話結束。UA之間的會話過程如圖2所示[3]。

圖2 基于SIP協議的UA系統間的通信流程圖

2.3 STUN技術和實驗分析

STUN (Simple Traversalof UDP Through NAT)是由IETF研制的一種UDP對NAT的穿越方式。STUN技術可以穿越大部分的NAT，并且無需改變現有的NAT設備。其主要思想就是私網中的PC終端先通過和公網上的STUN服務器通信，利用STUN服務器返回的信息判斷其本地NAT的類型，采用相應的NAT穿越方法，最終獲得本地端口在公網上的IP地址和端口[4]。

判斷NAT類型在實現STUN的穿越功能時非常重要，STUN_Client首先要判斷本地NAT的類型，針對其類型采用相應的映射方法，才能保證UDP數據包可以順利地到達目的網絡地址完成通信。根據NAT對UDP處理的不同實現方式，目前分為四種類型：(1)完全映射:完全映射的NAT是指所有的來自內部網同一個IP地址和端口的請求報文，都被映射到同一個外部網IP和端口。任何一個外部的主機可以發送消息到內部的主機，只要發送到其映射的外部IP和端口即可。(2)限制映射：與完全映射一樣，但一個外部主機（IP地址為U）要發送消息包給內部主機，需要該內部主機先發送消息包給IP地址U作為前提。(3)端口限制映射：端口限制映射與限制映射類似，只是限制的內容包括了端口號。(4)對稱映射：一個映射的NAT是指來自內部的IP和端口，發送到同一個IP和端口的請求報文，都將被映射到同一個外部的IP地址和端口。如果內部主機的IP地址和端口相同，但是目標地址和端口不同，將會有不同的映射方式，而且只有收到內部網消息的外部主機，才能夠發送消息給內部主機。根據NAT類型可以得出STUN可以解決前三種NAT的穿越，對于第四種，如果通信端處于對成型NAT后，將不能實現穿越，需要采取服務器轉發等形式才能實現[5]。

實驗中用了Wire Shark抓包，分析其中一個IP端口的STUN協議包如圖3所示。通過STUN服務器發送的數據包可以看出本地的IP和端口 是192.168.1.110:21240，STUN服務器的IP地址和端口號是213.192.59.93:3479。通過STUN服務器返回的數據包可以得到本地私網的IP地址以及端口號對應的公網上的IP地址和端口號為117.63.181.58:55012。

2.4 RTP/RTCP技術和實驗數據包分析

RTP是用于英特網上針對多媒體數據流傳輸的一種協議，例如音頻和視頻等具有實施性質的數據提供端到端的傳輸服務。RTP可以在一對一或者一對多的傳輸情況下工作。其主要作用是提供時間和流的同步。RTP通常使用UDP傳輸數據。一個RTP會話將使用兩個端口，一個給RTP另一個給RTCP。RTP負責媒體數據的實時傳輸，RTCP負責反饋控制，傳輸檢測。RTP自身并不提供任何保證及時傳輸的機制，也不保證其他服務的質量，但是可以依賴底層服務進行。它并不保證網絡可靠或者預防無序傳輸，它依靠RTCP監控數據傳輸質量，進行自適應調整。RTP中包含了序列號，允許接收者重組數據包[6]。

在本實驗系統中，通過RTP/RTCP實現數據流封包發送給下層，依托UDP傳輸，保證網絡的傳輸速度，RTP傳輸的網絡數據包如圖4所示。通過RTP數據序列號，使接收端根據序列號進行排序，保證數據流有序播放。RTP/RTCP有效地解決了UDP傳輸的數據包的無序性。在RTP會話期間，參與者周期性地發送RTCP包。RTCP包中含有已經發送的數據包的數量、丟失的數據包的數量等統計資料。因此，RTP和RTCP配合使用，通過有效的反饋和最小的開銷，使網絡的傳輸效率最佳化，與UDP配合特別適合傳輸網絡上的實時數據。

3 本地UA系統的工作流程和設計

本地UA系統的工作流程主要分為三塊：設備和協議的初始化、呼叫按鈕的觸發事件以及外來呼叫邀請的Callback事件。

首先主要是協議初始化和設備初始化，本系統采用Lumisoft SIP開源協議，該協議主要針對C#的編程環境，主要提供了SIP的一些接口函數，可以直接調用，自己可以根據需要組合出相應的SIP協議棧。初始化一個SIP棧類并且綁定相應的套接字端口，然后定義收到SIP消息時要觸發的事件以及其相應的處理函數。部分關鍵代碼如下：

呼叫按鈕的觸發事件是本系統中由用戶觸發的模塊。其主要分為創建RTP會議，提供SDP，綁定本地IP地址和端口，創建SIP消息并發送。消息體中包含了SDP信息，描述了多媒體通信的相關信息。本實驗的SIP會話的INVITE消息分析如圖5所示。

外來呼叫邀請的Callback事件主要修改當前的SIP協議的會話狀態(register、invite、ring、ok等)。 當狀態變化時，觸發事件處理函數，產生相應的SIP消息發送。部分關鍵代碼如下：

4 基于SIP協議的用戶代理UA系統的實現

本系統在Windows平臺下，以.NET Framework和 LumiSoft為開發工具完成，通過開發設計，最后的系統運行界面如圖 6所示。本系統將 SIP協議、STUN、RTP/RTCP協議等結合到一起，應用界面簡潔清楚、使用方便。軟件開啟，只要輸入本地用戶名和遠端UA用戶名，或者SIP服務器名稱，點擊CALL按鈕就可以直接和網絡上的SIP的UA端進行語音通話，或者訪問特定的SIP音樂服務器，收聽音樂。為后續實現基于SIP協議的視頻會議研究奠定了良好的基礎。通過本實驗得到結論：基于SIP的多媒體通信組網構建比H.323靈活，通過簡單的SIP信令的對話就可以快速實現多媒體通信，并且SIP協議基于文本格式，相對于H.323更加簡單易懂。

本文基于SIP協議的音頻通信的UA系統的項目研發實踐，詳細地闡述了基于SIP的VOIP的UA的設計和所涉及的關鍵技術和難點。對于本系統，提出幾點不足及后續研究應該改進的方向：首先沒有完善SIP服務器的注冊機制；其次STUN技術對于在對稱型NAT之后的UA無法實現穿越，需要結合服務器轉發等形式加以彌補。隨著SIP技術的廣泛應用，相信未來基于SIP多媒體會話技術將會有更好的發展和更廣泛的市場。

[1]張智云.SIP協議及其應用[M].北京：電子工程出版社，2005：89-93.

[2]杜吉友，董德存.基于SIP的多媒體通信系統安全技術[J].數據通信，2004，10(2)：340-350.

[3]范文，梁滿貴.基于oSlP協議棧的用戶代理的設計與實現[J].微計算機信息，2007，23(21)：15-16.

[4]嚴軍.NGN網絡業務穿越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，FREDERICK 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.