一種新的面向IMS網絡的SIP協議棧*

季光獻

（麗水職業技術學院 麗水 323000）

1 引言

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

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

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

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

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

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

·用戶能力：檢查媒體和媒體的參數。

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

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

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

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

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

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

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

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

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

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

SIP消息＝開始行

*消息頭

空行（CRLF）

[消息體]

開始行＝請求行|狀態行

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

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

表1 SIP請求消息

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

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

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

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

表2 SIP響應消息

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

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

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

2 提出的SIP協議棧

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

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

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

2.1 狀態機

2.1.1 事務

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

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

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

2.1.2 有限狀態機

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

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

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

2.1.3 事件

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

一個事件主要包含事件類型和關聯的事務兩部分內容，事件類型指導致狀態機狀態跳轉的各類事件的具體類型，如超時事件、收到invite請求等。可以說，外界與SIP模塊通信的載體是SIP消息和程序指令；在SIP模塊內，協議棧外圍程序與內核狀態機通信的載體則是事件。

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

事件的結構定義如下：

struct sipevent_t

{

type_t type; //事件的類型

int transactionid; //關聯的事務的標識號

sip_t*sip; //SIP消息結構

};

2.1.4 回調函數

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

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

2.2 解析器模塊

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

sip_t中存儲著發送或接收到的SIP消息的詳細結構，包含SIP協議定義的各個頭域以及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的數據結構定義分3部分。第一部分是起始行，其結構單獨定義為startline_t，當此消息是SIP請求時，其為請求的方法和請求源的URI；當此消息是SIP應答時，它為應答狀態碼。第二部分是一些SIP消息頭域的結構列表，這是由于頭域的個數是可變的原因，故采用列表來存放。最后一部分是一些其他頭域字段、消息體（list_t*bodies）以及對消息的描述字段。

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

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

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

（1）初始化結構體

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

（2）釋放結構體

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

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

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

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

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

（5）拷貝結構體

利用msg_clone函數創建結構體實例的副本。

2.2.1 SIP消息的解析

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

（1）解析起始行

對起始行的分析首先是判斷第一個參數，如果是sipversion（字符是SIP/2.0），則該消息是響應消息，這時從起始行中獲得狀態碼和原因短語，并將結構體中的成員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;

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

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

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

（2）解析 SIP 消息體

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

2.2.2 SIP消息的構造

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

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

2.3 工具模塊

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

此外，工具模塊還提供了基本的對話（dialog）處理機制。對話就是指持續一段時間的兩個UA之間對等的一種SIP會話關系。對話可以幫助管理UA的消息排序和UA之間正確的路由。在dialog中，可以動態地創建新的事務來開始端點之間的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）、對話的更新維護、對話的拆除。本協議棧中的對話管理工具主要用來創建dialog并對dialog信息進行管理。

2.4 上層封裝接口層

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（9）OWPL_RESULT owplCallHold(const OWPL_CALL hCall)

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

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

（10）OWPL_RESULT owplCallUnhold(constOWPL_CALL hCall)

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

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

（11）OWPL_RESULT owplCallDisconnect(OWPL_CALL hCall)

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

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

3 仿真實驗

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

3.1 實驗建立

如圖4所示，測試環境包括分別部署在兩臺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協議棧的設計思路和實現方法是合理的、切實可行的。

4 結束語

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

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

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

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

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

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

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

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