季光獻

（麗水職業(yè)技術學院 麗水 323000）

1 引言

IMS（IP multimedia subsystem，IP 多媒體子系統(tǒng)）是第三代移動通信伙伴組織（3GPP）在R5版本標準中提出的支持IP多媒體業(yè)務的子系統(tǒng)。它基于SIP（session initiation protocol，會話初始化協(xié)議）的體系，使用SIP呼叫控制機制來創(chuàng)建、管理和終結各種類型的多媒體業(yè)務。各種類型的客戶端通過IMS都可以建立起端到端的IP通信，并可獲得所需要的服務質量。在網(wǎng)絡融合的發(fā)展趨勢下，IMS技術為基于IP的移動和固定通信融合提供了基礎，并被業(yè)界認為是網(wǎng)絡演進的一個重要階段[1]。

SIP是由IETF制定的面向Internet會議和電話的應用層控制協(xié)議，用于建立、修改和終止多媒體會話。最初版本是1999年形成的RFC2543，之后不斷更新，最新的版本是2002年6月提出來的RFC3261。所謂多媒體會話是指多媒體發(fā)送者、接收者和從發(fā)送者到接收者的數(shù)據(jù)流的集合。在基于SIP的應用中，每一個會話可以是各種不同的數(shù)據(jù)，如普通的文本、經(jīng)過數(shù)字化處理的音頻、視頻數(shù)據(jù)等，應用具有很大的靈活性[2,3]。

SIP是一個基于ASCII碼的端到端的協(xié)議，參與會話的成員可以通過多播方式、單播連網(wǎng)或者兩者結合的形式進行通信。作為一個應用層的控制協(xié)議，SIP可以用來建立、修改和終止多媒體會話（或者會議）,如 Internet電話；也可以邀請參與者參加已經(jīng)存在的會話，如多方會議。媒體可以在一個已經(jīng)存在的會話中方便地增加（或者刪除）。SIP支持名字映射和重定向服務，可用于支持個人移動業(yè)務——用戶可以使用一個唯一的外部標志而不用關心他們的實際網(wǎng)絡地點。

SIP在建立和維持終止多媒體會話協(xié)議上，支持以下5個方面的功能。

·用戶定位：檢查終端用戶的位置，用于通信。

·用戶有效性：檢查用戶參與會話的意愿程度。

·用戶能力：檢查媒體和媒體的參數(shù)。

·建立會話：在呼叫方和被叫方間建立會話參數(shù)。

·會話管理：包括發(fā)送和終止會話，修改會話參數(shù)，激活服務等[4]。

SIP是IETF多媒體數(shù)據(jù)和控制體系結構的一部分，該協(xié)議大量借鑒了成熟的HTTP協(xié)議，并且具有易擴展、易實現(xiàn)等特點。SIP信令的特點如下[6]。

·基于文本，便于用Java、Perl等面向對象語言實現(xiàn)，易于調測排錯，結構靈活，便于擴展。

·中性的底層傳輸協(xié)議：可用TCP或UDP，推薦首選UDP。TCP是通過證實機制保證可靠傳送的，在網(wǎng)絡負載較大的情況下，常會發(fā)生超時，導致建立信令通道時延較大，采用UDP后，可以用應用層控制協(xié)議消息的定時和重發(fā)，并可方便地利用多播機制并行搜索目的用戶，無需為每一次搜索建立一個TCP連接。

·呼叫和媒體信息同時發(fā)送：SIP在傳送呼叫控制信令的同時，還可以在消息本體中傳送呼叫的媒體類型和格式等信息，以加快呼叫的建立速度。

·充分利用和組合Internet已有的協(xié)議：SIP容易與其他協(xié)議組合起來提供服務，如DNS用于地址解析、SDP用于會話和媒體流描述、RTP用于實時多媒體傳送、RSVP和RTCP用于QoS質量保證等。隨著網(wǎng)絡技術的發(fā)展，只需更新相關的協(xié)議，有利于系統(tǒng)的優(yōu)化和對新業(yè)務的靈活、快速反應。

·SIP使用統(tǒng)一資源定位器給出SIP資源的地址：SIP URI的格式和Web及E-mail系統(tǒng)中使用的格式是相同的，這給SIP重定向以巨大的靈活性，并且能將多種通信格式整合起來。

SIP的消息機制[7]使用ISO0646字符集UTF-8格式，除了字符集的區(qū)別以外，SIP的許多消息語法都與HTTP/1.1相同，也是一個請求/應答協(xié)議。需要注意的是，SIP并不是HTTP的擴展。SIP消息可以是客戶端發(fā)給服務器的請求或服務器對客戶端的響應。SIP客戶端是指產(chǎn)生請求的SIP實體，而SIP服務器是指接收請求和返回應答的SIP實體，按照這個定義，當兩個用戶代理交換SIP消息的時候，發(fā)送請求的用戶代理就是用戶代理客戶端（UAC），而返回應答的用戶代理就是用戶代理服務器 （UAS）。一個SIP請求連同它所出發(fā)的所有應答稱為一個SIP事務。

SIP消息分為兩種：從客戶端到服務器的請求；從服務器返回網(wǎng)絡客戶端的響應。SIP請求和響應消息都使用RFC2822規(guī)定的通用消息格式，包括開始行、一個或多個消息頭、一個空行（CRLF，表示消息頭結束）以及一個可選消息體。

SIP消息＝開始行

*消息頭

空行（CRLF）

[消息體]

開始行＝請求行|狀態(tài)行

消 息 頭＝（通 用 頭 （general-header）|請 求 頭 （requestheader）|響應頭（response-header）|實體頭（entity-header））

SIP協(xié)議中的請求消息提供了6種方法，見表1。

表1 SIP請求消息

SIP的響應消息和請求消息結構類似，但格式中第一行由狀態(tài)碼構成，代表服務器不同的響應狀態(tài)。RFC3261中使用nXX（n從1到6）的格式對狀態(tài)碼進行定義，n用來表示不同的響應類型，XX用來對響應類型進行進一步的描述。響應消息中的相關應答碼及其含義見表2。

SIP的協(xié)議結構如圖1所示。SIP是一個分層的協(xié)議，由多個處理層次組成。協(xié)議分成不同層次來描述是為了能夠更清晰地表達。

最底層的是語法和編碼層。編碼方式是采用擴展的Backus-Naur Form Grammar（BNF 范式）。

第二層是傳輸層。它定義了一個客戶端如何發(fā)送請求和接收應答以及一個服務器如何接收請求和發(fā)送應答。所有的SIP要素都包含一個通信層。

表2 SIP響應消息

第3層是事務層。事務是SIP的基本組成部分。一個事務是客戶發(fā)送一個請求事務（通過通信層）到一個服務器事務，連同服務器事務的所有該請求的應答發(fā)送回客戶端事務。事務層處理應用服務層的重發(fā)，匹配請求的應答以及應用服務層的超時。任何一個用戶代理客戶端完成的事情都是由一組事務構成的。用戶代理包含一個事務層來實現(xiàn)有狀態(tài)的代理服務器。無狀態(tài)的代理服務器并不包含事務層。事務層包含一個客戶元素（可以認為是一個客戶事務）和一個服務器元素（可以認為是一個服務器事務），它們都可以用一個有限狀態(tài)機來處理特定的請求。

在事務層之上是事務用戶（TU）。每一個SIP實體，除了無狀態(tài)代理，都是一個事務用戶。當一個TU發(fā)出一個請求，它首先創(chuàng)建一個客戶事務實例 （client transaction instance）并且和請求一起發(fā)送，這包括了目標IP地址、端口號以及發(fā)送請求的設備。TU可以創(chuàng)建客戶事務，也可以取消客戶事務。當客戶取消一個事務，它請求服務器終止正在處理的事務，并且回滾狀態(tài)到該事務開始前的狀態(tài)，并且產(chǎn)生指定的該事務的錯誤報告。這是由cancel請求完成的，這個請求有自己的事務，并且包含一個被取消的事務[3]。

在本文中，設計了一個穩(wěn)定、高效的SIP協(xié)議棧，其實現(xiàn)方式主要通過提供SIP操作所需的基本數(shù)據(jù)結構和應用程序編程接口（API），包括用于表示SIP中的各類對象（如SIP消息、SDP消息體以及各種頭域、計時器等）的數(shù)據(jù)結構以及對消息、消息體進行解析的API和實現(xiàn)4類有限狀態(tài)機的API。為驗證信令協(xié)議棧的可靠性和SIP軟終端的通信功能，本文對局域網(wǎng)內SIP軟終端的信令流程進行測試，采用Wireshark軟件抓取分組，并分析所捕獲數(shù)據(jù)分組的內容，結果表明本文提出的SIP協(xié)議棧是有效的。

2 提出的SIP協(xié)議棧

oSIP是按照RFC3261和RFC2327標準，使用ANSIC編寫的開源協(xié)議棧。它結構簡單小巧，支持線程安全，可用于多線程及單線程的編程模式，eXosip是oSIP的一個擴展協(xié)議集，它在oSIP基礎上對SIP消息的API做了較高級的封裝。eXosip可方便地創(chuàng)建一個完整的SIP程序，適用于SIP終端開發(fā)。

鑒于上述特性，本終端的SIP協(xié)議棧在oSIP/eXosip協(xié)議?；A上，通過引入有限狀態(tài)機進行修改和二次開發(fā)來實現(xiàn)，包括4大模塊：狀態(tài)機模塊、解析器模塊、工具模塊和上層封裝接口層。其模塊結構如圖2所示。

解析器模塊主要完成對SIP消息的語法解析，SIP中以事務為單位來描述各種請求和響應的交互過程。狀態(tài)機模塊的功能就是完成UAS或UAC對接收到的某個事務的響應，完成對該事務（注冊過程、呼叫過程等）的狀態(tài)記錄，并在特定狀態(tài)下觸發(fā)相應的事件或回調函數(shù)。工具模塊主要是提供一些進行SDP協(xié)商和對話管理的API。上層封裝接口層根據(jù)MVC模式中的Model層的調用方式，提供了面向Model層簡便易用的操作協(xié)議棧接口。

2.1 狀態(tài)機

2.1.1 事務

事務是SIP最基本的元素，事務是指SIP客戶端向SIP服務器發(fā)起的一次請求以及針對此次請求產(chǎn)生的所有應答的處理過程。

事務分為客戶事務和服務器事務兩大類。客戶事務是指發(fā)起請求一端（即客戶端)的處理過程，服務器事務是指接收請求一端（即服務器端）的處理過程。事務還可以根據(jù)發(fā)起事務的請求是否為invite分為invite事務和non-invite事務。因此，事務可以分為4類：invite客戶事務、non-invite客戶事務、invite服務器事務和non-invite服務器事務。

結構體transaction_t主要用于管理事務，同時在這個結構中記錄事務的相關信息。協(xié)議棧在開始一個對話時（如創(chuàng)建一個invite transaction來發(fā)送invite請求）分配該數(shù)據(jù)結構。在transaction_t的數(shù)據(jù)結構中，transactionid是事務處理鏈表中每個個體的唯一標識，transactionff是一個FIFO結構，用以標識此事務處理的事件，事務的狀態(tài)則由state來說明。

2.1.2 有限狀態(tài)機

SIP UA的核心就是事務處理，UA中事務的處理可以用有限狀態(tài)機來表示。

一個事務和一個狀態(tài)機有關。每一時刻狀態(tài)機（發(fā)送方或接收方）總處于一個特定的狀態(tài)，其狀態(tài)是由所有變量值組成的，包括計數(shù)器在內，其執(zhí)行于事務層。每個狀態(tài)機都有一個初始狀態(tài)，當有消息到來時，判斷是哪種狀態(tài)機的事件，根據(jù)消息的類型和狀態(tài)機的狀態(tài)，在狀態(tài)機的鏈表中查找需要執(zhí)行的操作函數(shù)的地址進行處理，并設置事件完成后的狀態(tài)。狀態(tài)機使用鏈表結構而不是單一對象，是為了在多事務同時處理環(huán)境下的應用（SIP服務器以及支持多方會議的SIP電話）。

事務有4大類，因此對事務的處理就由4種有限狀態(tài)機來表示，分別為ICT（請求客戶端事務的狀態(tài)）、IST（請求服務器端事務的狀態(tài)）、NICT（非請求客戶端事務的狀態(tài)）和NIST（非請求服務器端事務的狀態(tài)）。其執(zhí)行函數(shù)分別為 osip_ict_execute (manager→config)、 osip_nist_execute(manager→config)、osip_ist_execute(manager→config)、osip_nist_execute(manager→config)。

2.1.3 事件

狀態(tài)機內部的狀態(tài)跳轉是由事件觸發(fā)的。事件是應用程序與狀態(tài)機通信的手段。所有的從網(wǎng)絡上收取的數(shù)據(jù)分組都視為狀態(tài)機的事件，這些事件將被存儲在狀態(tài)機結構相關的事件隊列里。

一個事件主要包含事件類型和關聯(lián)的事務兩部分內容，事件類型指導致狀態(tài)機狀態(tài)跳轉的各類事件的具體類型，如超時事件、收到invite請求等?？梢哉f，外界與SIP模塊通信的載體是SIP消息和程序指令；在SIP模塊內，協(xié)議棧外圍程序與內核狀態(tài)機通信的載體則是事件。

在有限狀態(tài)機中有3種事件：發(fā)送SIP消息（請求和應答）、接收SIP消息（請求和應答）、計時器事件（重傳和上下文刪除或結束）。

事件的結構定義如下：

struct sipevent_t

{

type_t type; //事件的類型

int transactionid; //關聯(lián)的事務的標識號

sip_t*sip; //SIP消息結構

};

2.1.4 回調函數(shù)

在SIP協(xié)議棧中，對各類事件的響應都是以回調函數(shù)的方式實現(xiàn)的?；卣{函數(shù)本身是函數(shù)指針的形式，它在狀態(tài)機內部狀態(tài)跳轉時被事務處理函數(shù)調用，事務處理函數(shù)的其余部分完成對該事件的默認響應行為。所以說回調函數(shù)是SIP協(xié)議棧留給外界的用戶接口，用戶需要定義自己UA相關的處理內容。

本協(xié)議棧定義了osip_t對象作為所有回調函數(shù)的管理對象，外圍UA應用程序必須通過該對象實現(xiàn)對協(xié)議?；卣{函數(shù)的使用。osip_t除了管理所有的回調函數(shù)，也包含了4個狀態(tài)機事務對象的相關信息。在使用協(xié)議棧前必須調用函數(shù)osip_init()分配該結構并進行初始化。在系統(tǒng)運行期間，該結構存儲的內容是動態(tài)變化的，而這些變化主要是基于事務的建立或結束。

2.2 解析器模塊

解析器模塊可以分為3個部分：URI解析器、SIP解析器和SDP解析器。它主要實現(xiàn)將收到的SIP消息從文本解析成一個SIP消息結構體（sip_t），處理完畢后將待發(fā)送的sip_t結構還原成SIP文本消息然后發(fā)送的功能。在使用語法解析器之前必須先對它進行初始化：int parser_init()。

sip_t中存儲著發(fā)送或接收到的SIP消息的詳細結構，包含SIP協(xié)議定義的各個頭域以及SIP消息體，而這些解析后的頭域本身也是一些結構體，解析器在解析整個消息的同時也將消息中的頭域分別解析成對應的結構。解析的作用在于方便應用程序內部對消息及各個頭域進行操作。下面給出sip_t結構的部分內容：

struct sip_t

{

startline_t*strtline;

from_t*from;

to_t*to;

call_id_t*call_id;

list_t*contacts;

content_type_t*content_type;

......

}

sip_t的數(shù)據(jù)結構定義分3部分。第一部分是起始行，其結構單獨定義為startline_t，當此消息是SIP請求時，其為請求的方法和請求源的URI；當此消息是SIP應答時，它為應答狀態(tài)碼。第二部分是一些SIP消息頭域的結構列表，這是由于頭域的個數(shù)是可變的原因，故采用列表來存放。最后一部分是一些其他頭域字段、消息體（list_t*bodies）以及對消息的描述字段。

sip_t中的一些成員（不包括char*message）為null時表示該SIP消息不含該字段。協(xié)議棧在要發(fā)送SIP消息或接收到SIP消息時創(chuàng)建sip_t，并填寫好相應的信息，發(fā)送完后或處理完之后釋放該結構。

sip_t結構中各個變量的值是從界面的用戶輸入或系統(tǒng)配置中讀取的，然后通過函數(shù)將讀取的值存放到sip_t結構中。如int msg_setbody(sip_t*sip,char*buf)就是設定sip_t結構中body的值。相應地，也可以從結構中根據(jù)名字獲取各個參數(shù)，實現(xiàn)函數(shù)的名稱類似對應的函數(shù)中的set改為 get，如 int msg_getbody(sip_t*sip,char*buf)就是獲得body的值。

對于消息結構體sip_t的操作包括以下5種操作。

（1）初始化結構體

利用msg_init函數(shù)對結構體進行初始化，目的是為結構體分配存儲空間。

（2）釋放結構體

利用msg_free函數(shù)釋放初始化時分配給結構體的存儲空間。

（3）將結構體變成字符串的形式

利用msg_2char函數(shù)將結構體轉化為符合SIP消息規(guī)范的字符串的形式。

（4）將消息的字符串格式轉化為結構體的存儲形式

利用msg_parse函數(shù)分析消息的字符串，將相應的字符存儲到結構體實例的相應字段中。

（5）拷貝結構體

利用msg_clone函數(shù)創(chuàng)建結構體實例的副本。

2.2.1 SIP消息的解析

SIP消息的解析流程如圖3所示。

（1）解析起始行

對起始行的分析首先是判斷第一個參數(shù)，如果是sipversion（字符是SIP/2.0），則該消息是響應消息，這時從起始行中獲得狀態(tài)碼和原因短語，并將結構體中的成員sipmethod 和 rquri設為 null；如果是 sipmehtod（invite、Ack、bye、register、cancel、options共 6 種方法），則該消息是請求消息，這時從起始行中獲得請求方法、請求URI和版本號，并將statuscode和reasonphrase設為 null。

（2）解析 SIP 頭域

頭域采用通用格式，其結構體定義如下：

typedef struct_header_t{

char*hname;

char*hvalue;

}header_t;

字段的值可以有多個參數(shù)，參數(shù)之間用分號"；"來分隔。對頭域的分析可有以下兩種情況：

·對于僅僅為單個參數(shù)的成員，根據(jù)頭域字段的名字調用相應字段的分析函數(shù)，分析字符串來獲得該頭域字段的值；

·對于可以有多個參數(shù)的成員，由于是采用鏈表的形式存儲，直接將字段名字和字段的值相分離，根據(jù)字段名字的屬性將字段的值賦給相應的成員。

（2）解析 SIP 消息體

根據(jù)content type（編碼類型）和 content length（編碼長度）兩個標題頭的值來判斷消息體部分是否有值，這兩個標題頭的參數(shù)表明消息體中是否存在消息體，如果有，則把這些數(shù)據(jù)拷貝到消息體的結構體中。

2.2.2 SIP消息的構造

相對于SIP消息的解析過程，SIP消息的構造也是通過調用解析器模塊的相關函數(shù)和工具模塊的相關函數(shù)來完成的。

當SIP服務器想發(fā)送一個消息時，通知解析器模塊開始操作。首先對起始行、頭域等結構體進行初始化；隨后調用各個功能函數(shù)對SIP消息結構體中的各項內容分別進行添加和設定；然后調用sipmsg_2char函數(shù)將SIP消息結構體中的信息轉化為可以發(fā)送的字符串，調用sipmsg_clone函數(shù)為sipmsg_t結構創(chuàng)建副本 （以備重發(fā)）；最后對各結構體的信息進行釋放。

2.3 工具模塊

工具模塊提供了比較完善的SDP協(xié)商機制，包括SDP結構體的定義、各類SDP字段的添加設置以及根據(jù)預定義的本地SDP環(huán)境產(chǎn)生針對某個SDP結構體的應答。SDP協(xié)商指主被叫用戶交換關于呼叫的一些相關媒體信息（如媒體編解碼方式、媒體流傳輸所用的端口號等）的行為。SDP協(xié)商主要采用offer/answer的模式，而協(xié)議棧中的SDP協(xié)商工具（SDP negotiator）主要提供了一種從SDP offer去構建SDP answer的方法，如通過分析invite請求消息中消息體SDP部分的媒體參數(shù)描述去構造對于invite請求的響應消息200OK中的SDP消息體部分。

此外，工具模塊還提供了基本的對話（dialog）處理機制。對話就是指持續(xù)一段時間的兩個UA之間對等的一種SIP會話關系。對話可以幫助管理UA的消息排序和UA之間正確的路由。在dialog中，可以動態(tài)地創(chuàng)建新的事務來開始端點之間的SIP通信過程。在UA中，對話用dialog ID標識。一個dialog ID由SIP消息中的Call-ID、一個本地tag（local tag）和一個遠程 tag（remote tag）組成。在同一個對話中，UA的本地tag就是對等 UA的遠程tag，反之，遠程tag就是對等UA的本地tag。基本的dialog處理機制包括dialog結構體的定義、按照兩種方式建立的dialog（被叫方callee和主叫方caller）、對話的更新維護、對話的拆除。本協(xié)議棧中的對話管理工具主要用來創(chuàng)建dialog并對dialog信息進行管理。

2.4 上層封裝接口層

eXosip封裝了大部分的SIP協(xié)議調用接口，一般的應用都不需要直接調用oSIP的接口函數(shù)。上層封裝接口層在其基礎上進一步封裝，供上層Model層調用，使用幾行代碼就可以實現(xiàn)一個具有音視頻功能的呼叫。下面對其處理呼叫的關鍵接口進行定義。

（1）OWPL_RESULT owplLineAdd (const char *displayname,constchar* sipUsername,constchar*sipServer,const char*sipProxy,OWPL_TRANSPORT_PROTOCOL sipTransport,int regTimeout,OWPL_LINE*phLine)

方法功能描述：添加一條虛擬線路，即向服務器注冊。

參數(shù)說明：displayname:SIP實體要顯示的名字，對應于“displayname”；sipUsername 和sipServer對應于上述格式；sipProxy是代理服務器地址；sipTransport為傳輸層協(xié)議；regTimeout為注冊超時時間；phLine指向新建立的虛擬線路。

（2）OWPL_RESULT owplLineDelete(OWPL_LINE hLine,unsigned int skipUnregister)

方法功能描述：刪除一條虛擬線路。

參數(shù)說明：hLine代表要刪除的虛擬線路；skipUnregister值為1時表示在刪除虛擬線路時跳過注銷，為0時強制刪除虛擬線路，無需注銷。

（3）OWPL_RESULT owplLineRegister(const OWPL_LINE hLine,const int bRegister)

方法功能描述：注冊一條虛擬線路。

參數(shù)說明：hLine代表要注冊的虛擬線路；bRegister值為1時注冊該虛擬線路，為0時注銷該虛擬線路。

（4）OWPL_RESULT owplCallCreate(const OWPL_LINE hLine,OWPL_CALL*hCall)

方法功能描述：建立一個呼叫對象。

參數(shù)說明：hLine代表要建立呼叫對象的虛擬線路；hCall指向建立好的呼叫對象。

（5）OWPL_RESULT owplCallConnect(const OWPL_CALL hCall,const char*szAddress,int mediaStreams)

方法功能描述：呼叫連接。

參數(shù)說明：hCall代表要進行連接的呼叫對象；szAddress呼叫對端的SIP地址；mediaStreams表示媒體流種類。

（6）OWPL_RESULT owplCallAccept(constOWPL_CALL hCall,int mediaStreams)

方法功能描述：接收一個呼叫。

參數(shù)說明：hCall代表要接收的呼叫對象；mediaStreams表示媒體流種類。

（7）OWPL_RESULT owplCallAnswer(const OWPL_CALL hCall,int mediaStreams)

方法功能描述：對到來的一個呼叫應答。

參數(shù)說明：hCall代表要應答的呼叫對象；mediaStreams表示媒體流種類。

（8）OWPL_RESULT owplCallReject(const OWPL_CALL hCall,const int errorCode,const char*szErrorText)

方法功能描述：拒絕到來的一個呼叫。

參數(shù)說明：hCall代表要拒絕的呼叫對象；errorCode指SIP消息的錯誤碼；szErrorText是對應錯誤碼的文本信息。

（9）OWPL_RESULT owplCallHold(const OWPL_CALL hCall)

方法功能描述：掛起一個呼叫。

參數(shù)說明：hCall代表要掛起的呼叫對象。

（10）OWPL_RESULT owplCallUnhold(constOWPL_CALL hCall)

方法功能描述：恢復一個呼叫。

參數(shù)說明：hCall代表要恢復的呼叫對象。

（11）OWPL_RESULT owplCallDisconnect(OWPL_CALL hCall)

方法功能描述：結束一個呼叫。

參數(shù)說明：hCall代表要結束的呼叫對象。

3 仿真實驗

為驗證信令協(xié)議棧的設計實現(xiàn)的可靠性和SIP軟終端的通信功能，本文對局域網(wǎng)內SIP軟終端的信令流程進行測試，采用Wireshark軟件抓取分組，并分析所捕獲數(shù)據(jù)分組的內容。實驗的目的是為了驗證提出的協(xié)議棧的有效性，對其中呼叫建立的基本交互流程不做詳細說明，且由于版面的限制，有關SIP協(xié)議交互流程的更多交互信息見參考文獻[3]。

3.1 實驗建立

如圖4所示，測試環(huán)境包括分別部署在兩臺PC（IP地址分別為***.***.156.225和***.***.158.730）上的兩個SIP軟終端以及一臺IP地址為***.***.158.230的SIP服務器。

3.2 注冊功能

注冊功能測試用例見表3。

表3 注冊功能測試用例

3.3 通話功能

通話功能測試用例見表4。

表4 通話功能測試用例

圖5展示了本SIP軟終端通話功能的實際效果。大的視頻窗口顯示對方的影像，右下角的視頻窗口顯示本地攝像頭采集的影像。

3.4 呼叫建立時間

呼叫建立時間測試用例見表5。

3.5 長時通話

長時通話測試用例見表6。

表5 呼叫建立時間測試用例

表6 長時通話測試用例

由表3～表6及圖5，驗證了本文所設計的軟終端能夠使用SIP信令建立連接，可以完成實時視音頻通信功能，并且具備一定的可靠性，表明本文提出的SIP協(xié)議棧的設計思路和實現(xiàn)方法是合理的、切實可行的。

4 結束語

IMS網(wǎng)絡使用SIP呼叫控制機制來創(chuàng)建、管理和終結各種類型的多媒體業(yè)務。各種類型的客戶端通過SIP都可以建立起端到端的通信，并可獲得所需要的服務質量。本文提出了一種新的SIP協(xié)議棧，并依照該協(xié)議棧實現(xiàn)了SIP軟終端，具備基于SIP的視頻和音頻通話功能。經(jīng)過驗證，該軟終端具有良好的穩(wěn)定性和實用性，能較好地運行于IMS網(wǎng)絡環(huán)境下，實現(xiàn)雙方通信。

1 王尚廣，孫其博，楊放春.IMS網(wǎng)絡中的SIP洪泛攻擊檢測.軟件學報，2011,22(4):761～772

2 胡成喆.一種基于MVC架構的SIP軟終端的設計與實現(xiàn).北京郵電大學碩士學位論文,2010

3 孫建勇.基于SIP協(xié)議的軟終端的研究與實現(xiàn).北京郵電大學碩士學位論文，2004

4 鄧挺，李小兵.SIP在視頻監(jiān)控系統(tǒng)中的應用.安防科技，2007(8)

5 Gonzalo Camarillo著.白建軍，彭暉，田敏等譯.SIP揭密.北京：人民郵電出版社，2003

6 趙慧玲，葉華.以軟交換為核心的下一代網(wǎng)絡技術.北京：人民郵電出版社，2002

7 Session Initiation Protocol RFC3261.IETF Network Working Group,2002