謝斌盛，唐作其，張正平

(貴州大學(xué) 計(jì)算機(jī)科學(xué)與信息學(xué)院，貴州 貴陽550025)

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

在本實(shí)驗(yàn)中，主要與SDP(Session Description Protocol)、RTP(Real-time Transport Protocol)、UDP 等 協(xié) 議 一 起構(gòu)建了完整的音頻通信系統(tǒng)，如圖1所示。本地UA端通過訪問其他SIP的UA端或者SIP音樂服務(wù)器，實(shí)現(xiàn)語音通信和網(wǎng)絡(luò)音樂點(diǎn)播的功能。

圖1 音頻通信系統(tǒng)示意圖

1 SIP組網(wǎng)模型簡介

SIP網(wǎng)絡(luò)中有兩個(gè)要素：SIP用戶代理(UA)和SIP網(wǎng)絡(luò)服務(wù)器。UA主要由負(fù)責(zé)發(fā)起SIP請(qǐng)求的用戶代理端(UAC)和負(fù)責(zé)對(duì)呼叫請(qǐng)求做出響應(yīng)的用戶代理服務(wù)端(UAS)組成。

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

2 基于SIP的VOIP UA系統(tǒng)的設(shè)計(jì)

2.1 系統(tǒng)的整體分析

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

該UA系統(tǒng)主要分為用戶界面層、模塊接口層、功能實(shí)現(xiàn)層以及底層。其中用戶界面層基于VS2010C#開發(fā)，包含了程序的入口函數(shù)，為應(yīng)用程序提供交互的圖形界面，并且確定了應(yīng)用程序的整體框架結(jié)構(gòu)；模塊接口層是由軟件中所調(diào)用的各個(gè)模塊的接口函數(shù)組成的；主要屏蔽了所有調(diào)用下層模塊的細(xì)節(jié)，提供一些簡單的類，便于用戶界面層的控件的回調(diào)函數(shù)調(diào)用，來完成具體的注冊(cè)、call或者call incoming等具體功能；功能實(shí)現(xiàn)層是由SIP用戶代理模塊、媒體流處理模塊、系統(tǒng)配置模塊和網(wǎng)絡(luò)配置模塊構(gòu)成；底層主要提供媒體處理流處理提供相應(yīng)的接口。

2.2 UA間的會(huì)話過程

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

圖2 基于SIP協(xié)議的UA系統(tǒng)間的通信流程圖

2.3 STUN技術(shù)和實(shí)驗(yàn)分析

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

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

實(shí)驗(yàn)中用了Wire Shark抓包，分析其中一個(gè)IP端口的STUN協(xié)議包如圖3所示。通過STUN服務(wù)器發(fā)送的數(shù)據(jù)包可以看出本地的IP和端口 是192.168.1.110:21240，STUN服務(wù)器的IP地址和端口號(hào)是213.192.59.93:3479。通過STUN服務(wù)器返回的數(shù)據(jù)包可以得到本地私網(wǎng)的IP地址以及端口號(hào)對(duì)應(yīng)的公網(wǎng)上的IP地址和端口號(hào)為117.63.181.58:55012。

2.4 RTP/RTCP技術(shù)和實(shí)驗(yàn)數(shù)據(jù)包分析

RTP是用于英特網(wǎng)上針對(duì)多媒體數(shù)據(jù)流傳輸?shù)囊环N協(xié)議，例如音頻和視頻等具有實(shí)施性質(zhì)的數(shù)據(jù)提供端到端的傳輸服務(wù)。RTP可以在一對(duì)一或者一對(duì)多的傳輸情況下工作。其主要作用是提供時(shí)間和流的同步。RTP通常使用UDP傳輸數(shù)據(jù)。一個(gè)RTP會(huì)話將使用兩個(gè)端口，一個(gè)給RTP另一個(gè)給RTCP。RTP負(fù)責(zé)媒體數(shù)據(jù)的實(shí)時(shí)傳輸，RTCP負(fù)責(zé)反饋控制，傳輸檢測(cè)。RTP自身并不提供任何保證及時(shí)傳輸?shù)臋C(jī)制，也不保證其他服務(wù)的質(zhì)量，但是可以依賴底層服務(wù)進(jìn)行。它并不保證網(wǎng)絡(luò)可靠或者預(yù)防無序傳輸，它依靠RTCP監(jiān)控?cái)?shù)據(jù)傳輸質(zhì)量，進(jìn)行自適應(yīng)調(diào)整。RTP中包含了序列號(hào)，允許接收者重組數(shù)據(jù)包[6]。

在本實(shí)驗(yàn)系統(tǒng)中，通過RTP/RTCP實(shí)現(xiàn)數(shù)據(jù)流封包發(fā)送給下層，依托UDP傳輸，保證網(wǎng)絡(luò)的傳輸速度，RTP傳輸?shù)木W(wǎng)絡(luò)數(shù)據(jù)包如圖4所示。通過RTP數(shù)據(jù)序列號(hào)，使接收端根據(jù)序列號(hào)進(jìn)行排序，保證數(shù)據(jù)流有序播放。RTP/RTCP有效地解決了UDP傳輸?shù)臄?shù)據(jù)包的無序性。在RTP會(huì)話期間，參與者周期性地發(fā)送RTCP包。RTCP包中含有已經(jīng)發(fā)送的數(shù)據(jù)包的數(shù)量、丟失的數(shù)據(jù)包的數(shù)量等統(tǒng)計(jì)資料。因此，RTP和RTCP配合使用，通過有效的反饋和最小的開銷，使網(wǎng)絡(luò)的傳輸效率最佳化，與UDP配合特別適合傳輸網(wǎng)絡(luò)上的實(shí)時(shí)數(shù)據(jù)。

3 本地UA系統(tǒng)的工作流程和設(shè)計(jì)

本地UA系統(tǒng)的工作流程主要分為三塊：設(shè)備和協(xié)議的初始化、呼叫按鈕的觸發(fā)事件以及外來呼叫邀請(qǐng)的Callback事件。

首先主要是協(xié)議初始化和設(shè)備初始化，本系統(tǒng)采用Lumisoft SIP開源協(xié)議，該協(xié)議主要針對(duì)C#的編程環(huán)境，主要提供了SIP的一些接口函數(shù)，可以直接調(diào)用，自己可以根據(jù)需要組合出相應(yīng)的SIP協(xié)議棧。初始化一個(gè)SIP棧類并且綁定相應(yīng)的套接字端口，然后定義收到SIP消息時(shí)要觸發(fā)的事件以及其相應(yīng)的處理函數(shù)。部分關(guān)鍵代碼如下：

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

外來呼叫邀請(qǐng)的Callback事件主要修改當(dāng)前的SIP協(xié)議的會(huì)話狀態(tài)(register、invite、ring、ok等)。 當(dāng)狀態(tài)變化時(shí)，觸發(fā)事件處理函數(shù)，產(chǎn)生相應(yīng)的SIP消息發(fā)送。部分關(guān)鍵代碼如下：

4 基于SIP協(xié)議的用戶代理UA系統(tǒng)的實(shí)現(xiàn)

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

本文基于SIP協(xié)議的音頻通信的UA系統(tǒng)的項(xiàng)目研發(fā)實(shí)踐，詳細(xì)地闡述了基于SIP的VOIP的UA的設(shè)計(jì)和所涉及的關(guān)鍵技術(shù)和難點(diǎn)。對(duì)于本系統(tǒng)，提出幾點(diǎn)不足及后續(xù)研究應(yīng)該改進(jìn)的方向：首先沒有完善SIP服務(wù)器的注冊(cè)機(jī)制；其次STUN技術(shù)對(duì)于在對(duì)稱型NAT之后的UA無法實(shí)現(xiàn)穿越，需要結(jié)合服務(wù)器轉(zhuǎn)發(fā)等形式加以彌補(bǔ)。隨著SIP技術(shù)的廣泛應(yīng)用，相信未來基于SIP多媒體會(huì)話技術(shù)將會(huì)有更好的發(fā)展和更廣泛的市場。

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

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

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

[4]嚴(yán)軍.NGN網(wǎng)絡(luò)業(yè)務(wù)穿越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.