平臺化思路下SIPTU的設(shè)計(jì)與實(shí)現(xiàn)

曾麗君　魏麗　閔芳

摘要：會話初始協(xié)議（SIP）是一種應(yīng)用層控制協(xié)議，在IMS系統(tǒng)中應(yīng)用廣泛。研究了一種平臺化SIP的實(shí)現(xiàn)方案，這種方案使得SIP在不同的產(chǎn)品中能屏蔽上層和底層的實(shí)現(xiàn)，通過提供不同的接口層給上層應(yīng)用使用，使得SIP更具通用性?；诖朔N思路，進(jìn)一步實(shí)現(xiàn)了SIP分層結(jié)構(gòu)中非常重要的組成部分SIP TU的基本功能和關(guān)鍵技術(shù)，具體包括UAC、UAS以及proxy行為的支持等。

關(guān)鍵詞：SIP TU UA proxy

中圖分類號：TP311.52 文獻(xiàn)標(biāo)識碼：A 文章編號：1007-9416（2016）09-0179-02

近幾年來，移動網(wǎng)和互聯(lián)網(wǎng)有效的結(jié)合起來，既能向人們提供無處不在的多媒體業(yè)務(wù)，也能對通信網(wǎng)絡(luò)實(shí)施有效的管理。為了實(shí)現(xiàn)通信以及多媒體的相關(guān)業(yè)務(wù)，3GPP標(biāo)準(zhǔn)定義了一些協(xié)議來配合業(yè)務(wù)的實(shí)現(xiàn)，涉及到的常用協(xié)議有SIP協(xié)議（協(xié)議標(biāo)準(zhǔn)為RFC3261），H248協(xié)議（協(xié)議標(biāo)準(zhǔn)為RFC3525），DIAMETER協(xié)議（協(xié)議標(biāo)準(zhǔn)為RFC3588）等。目前這些協(xié)議應(yīng)用的項(xiàng)目有固網(wǎng)產(chǎn)品（包括軟交換、分組交換服務(wù)、SBC、BGW等），IMS產(chǎn)品（包括CSCF，MGCF，PDF，HSS等）；移動核心網(wǎng)產(chǎn)品（CDMA2000、MSCe，WCDMA、TD-SCDMA等）；由于這些協(xié)議應(yīng)用的產(chǎn)品眾多，則可以采用平臺化的設(shè)計(jì)思路來對這些協(xié)議進(jìn)行實(shí)現(xiàn)，以便人力共享，經(jīng)驗(yàn)共享，成果共享，在企業(yè)中也能準(zhǔn)確快速的響應(yīng)產(chǎn)品需求。

眾多協(xié)議中，SIP協(xié)議定義的目的，是為了建立、修改和終止一個(gè)多媒體的通話，它是信令的控制協(xié)議[1]，和其他協(xié)議配合，共同實(shí)現(xiàn)IMS中相關(guān)通信業(yè)務(wù)。

1 SIP平臺實(shí)現(xiàn)架構(gòu)

基于平臺化的設(shè)計(jì)思路，遵從IETF標(biāo)準(zhǔn)組織的RFC3261協(xié)議的描述對SIP協(xié)議進(jìn)行構(gòu)建。其整體架構(gòu)如圖1所示。

如圖1所示，協(xié)議平臺主要由兩部分組成，第一部分是協(xié)議平臺的主體實(shí)現(xiàn)部分：SIP事務(wù)用戶層（TU，Transaction User），事務(wù)層（TR，TRansaction），傳輸層（TP，TransPort），以及協(xié)議涉及到的配合模塊：編解碼模塊，操作維護(hù)模塊等。另一部分為協(xié)議接口層，協(xié)議接口層是為了屏蔽外部接口及功能的變化而由協(xié)議平臺實(shí)現(xiàn)的封裝部分，此部分設(shè)計(jì)目的在于最大程度的對可能使用SIP平臺的外部需求進(jìn)行整合統(tǒng)一，使外部功能變化的波及最大程度的限制在接口層中，以減少對協(xié)議平臺主體實(shí)現(xiàn)的沖擊，提供良好的可擴(kuò)展性。具體包括TU與上層業(yè)務(wù)用戶的接口部分（TUUI，TU User Interface）；以及SIP與數(shù)據(jù)庫之間的接口部分（SIP DB），SIP與操作系統(tǒng)支撐之間的接口部分（SIP OSS），SIP與底層IP承載之間的接口部分（SIP BRS），SIP與操作維護(hù)OMC之間的接口部分（SIP OMC）。

2 TU總體介紹

2.1 TU在SIP平臺中的位置

平臺化的思路主要針對是不同的上層應(yīng)用，而SIP TU又是直接和上層應(yīng)用進(jìn)行交互的，所以平臺化思路下，SIP TU的實(shí)現(xiàn)就成了最為核心的部分，SIP TU設(shè)計(jì)的合理化，可以是的SIP的應(yīng)用更加通用化。TU模塊在整個(gè)SIP平臺系統(tǒng)中的位置如圖2所示。

與TU模塊相關(guān)的各構(gòu)件及接口有：（1）編解碼模塊：SIP是一個(gè)基于文本的協(xié)議，底層傳輸?shù)亩际亲址?，編解碼模塊完成SIP信令字符流形式到結(jié)構(gòu)化的轉(zhuǎn)換（解碼）和結(jié)構(gòu)化SIP消息到字符流形式SIP消息的轉(zhuǎn)換（編碼）。（2）操作維護(hù)模塊：用以協(xié)助解決和規(guī)避SIP平臺運(yùn)行過程中可能遇到的問題，并在發(fā)生故障的時(shí)候予以警示和提供收集定位問題相關(guān)信息的手段。（3）SIP事務(wù)層[2]：事務(wù)層處于TU層下面，服務(wù)器事務(wù)負(fù)責(zé)從傳輸層接收請求消息，并傳遞給SIP TU，同時(shí)也負(fù)責(zé)從SIP TU接收響應(yīng)，并傳遞給傳輸層發(fā)出。（4）SIP傳輸層：正常情況下，傳輸層從底層承載獲得消息后，都是傳送給事務(wù)層，某些情況下，SIP作為無狀態(tài)代理，協(xié)議平臺所做工作僅僅是進(jìn)行消息的轉(zhuǎn)發(fā)，此時(shí)TP和TU之間會直接進(jìn)行交互。（5）上層應(yīng)用：SIP平臺的使用者，不同的網(wǎng)元上層應(yīng)用所實(shí)現(xiàn)的業(yè)務(wù)不同，對于SIP平臺而言，綜合考慮使用網(wǎng)元的應(yīng)用情況，提供對應(yīng)的接口供上層應(yīng)用使用，比如業(yè)務(wù)進(jìn)程的注冊接口，上行消息的上報(bào)接口，下行消息的發(fā)送接口，不同功能的信息傳遞接口等。這樣實(shí)現(xiàn)后，上層應(yīng)用對于SIP的內(nèi)部實(shí)現(xiàn)是不可見的，只是通過接口來SIP之間進(jìn)行交互。

2.2 TU模塊功能劃分

2.2.1 進(jìn)程管理功能

SIP TU層功能較多，因此將其設(shè)計(jì)為單獨(dú)的一個(gè)模塊，單獨(dú)的一個(gè)進(jìn)程，進(jìn)程管理功能負(fù)責(zé)分發(fā)支撐的各種消息到各個(gè)不同的子模塊的分發(fā)入口函數(shù)中，這樣使得對于和上層以及事務(wù)層交互的消息的處理都很獨(dú)立很清晰。

2.2.2 TU層協(xié)議功能

根據(jù)協(xié)議要求需實(shí)現(xiàn)的功能包括[3]：（1）完成UAC的功能，主動創(chuàng)建請求并處理對應(yīng)的響應(yīng)。（2）完成UAS的功能，接收請求，檢查請求并對請求中的方法進(jìn)行識別，創(chuàng)建對應(yīng)的應(yīng)答；（3）有狀態(tài)和無狀態(tài)proxy的支持，能正確的對消息轉(zhuǎn)發(fā)，有狀態(tài)時(shí)能正確的提取參數(shù)維護(hù)狀態(tài)機(jī)。（4）會話管理，會話INVITE的傳輸和終結(jié)，通過狀態(tài)機(jī)修改和管理會話參數(shù)。（5）基本功能：路由處理、路由重選、路由刷新等。（6）支持SIP REGISTER方法、SUBSCRIBE方法、REFER方法、OPTIONS請求等。（7）數(shù)據(jù)區(qū)的?；睿轂?zāi)和主備倒換機(jī)制的支持等。

3 TU關(guān)鍵技術(shù)

第三部分從總體上對TU層在SIP協(xié)議平臺中的作用進(jìn)行了說明，接下來詳細(xì)的介紹以下TU層的幾個(gè)關(guān)鍵實(shí)現(xiàn)技術(shù)。

3.1 TU數(shù)據(jù)區(qū)機(jī)制

無論SIP是有狀態(tài)的proxy或者是UA情況下，為了維護(hù)一個(gè)對話，都必須保留消息中的先關(guān)信息，SIP平臺機(jī)制中是通過在TU層建立數(shù)據(jù)區(qū)來保存對話的相關(guān)信息，這個(gè)數(shù)據(jù)區(qū)我們就用Leg來進(jìn)行表示，Leg對象表示一個(gè)半呼叫分支[4]。TU層通過Leg來接受SIP消息或者發(fā)送SIP消息，同時(shí)TU通過Leg來保存對話的相關(guān)信息。具體的Leg模型如圖3所示。

Proxy方式下，主要是實(shí)現(xiàn)消息的轉(zhuǎn)發(fā)，因此會存在一入一出兩個(gè)Leg對象，入呼側(cè)Leg由TU收到事務(wù)層的初始請求而創(chuàng)建，TU層提取請求消息中的關(guān)鍵信息進(jìn)行保存，TU進(jìn)一步的將此消息上報(bào)上層應(yīng)用。到了出呼測，TU接收到上層應(yīng)用發(fā)送的初始請求進(jìn)而創(chuàng)建出呼側(cè)Leg對象，提取關(guān)鍵信息進(jìn)行存儲后，下發(fā)SIP消息到事務(wù)層。UA方式下，如果是UAS，TU協(xié)議棧收到事務(wù)的初始請求后，創(chuàng)建入呼Leg后，通過初始請求消息上報(bào)上層業(yè)務(wù)，上層業(yè)務(wù)處理完業(yè)務(wù)邏輯后，通過入呼Leg回送響應(yīng)到事務(wù)層。后續(xù)請求和響應(yīng)都是通過入呼Leg傳送。如果是UAC，上層應(yīng)用調(diào)用SIP平臺的接口發(fā)送初始請求到TU，TU創(chuàng)建出呼側(cè)Leg后，初始請求消息通過該Leg發(fā)送至事務(wù)層，后續(xù)請求和響應(yīng)都是通過出呼側(cè)Leg傳遞。

通常情況下，存儲在Leg中的對話狀態(tài)信息由對話ID、本地序列號、遠(yuǎn)端序列號、本地URI、遠(yuǎn)端URI、遠(yuǎn)端目的地、路由集、對話狀態(tài)等組成，這些信息也是通過收到的請求或者響應(yīng)進(jìn)行賦值和修改。以入呼側(cè)Leg為例，比如SIP平臺收到請求后，SIP TU會對收到的消息進(jìn)行編解碼，這樣就能準(zhǔn)確的獲取到消息流中各個(gè)頭部來保存，比如遠(yuǎn)端目的地通常從請求消息的Contact消息的URI獲取，對話ID由Call-ID、From頭部中的tag值以及To頭部中的tag值組成；本地序列號為空；遠(yuǎn)端序列號從CSeq頭部中獲取，遠(yuǎn)端URI設(shè)置為From消息頭中的URI，本地URI設(shè)置為to消息頭中的URI，路由集通過route頭部獲取。同樣，對于出呼側(cè)Leg信息的提取也是類似處理。

3.2 UAC行為的支持

UA是SIP的一個(gè)重要角色，當(dāng)作為UAC發(fā)出請求時(shí)，請求消息會通過一些代理服務(wù)器被轉(zhuǎn)發(fā)到UAS，而UAS產(chǎn)生一個(gè)響應(yīng)后，響應(yīng)消息會以同樣的方式被轉(zhuǎn)發(fā)到UAC。因此，對于UAC的基本行為包含幾個(gè)方面：產(chǎn)生請求消息、請求消息的發(fā)送以及響應(yīng)消息的處理。

（1）產(chǎn)生請求消息：由UAC產(chǎn)生一個(gè)有效的SIP請求消息，首先要包含的是請求行Request-URI，其次需要包含必選的頭字段：To、From、CSeq、Call-ID、Max-Forwards和Via字段，當(dāng)然也可以包含用于SIP擴(kuò)展的一些字段，比如Require頭和Supported頭等。因此，對于TU而言，要主動的產(chǎn)生一個(gè)消息，就要去構(gòu)成這些字段，其中Request-URI和To頭部填寫的是目標(biāo)地址，通常為目的用戶已注冊的公用地址，可以通過網(wǎng)管上配置的數(shù)據(jù)獲取。From消息頭填寫的是發(fā)送者本身的地址，同時(shí)需要添加tag參數(shù)用來標(biāo)識對話。CSeq由一個(gè)請求方法和一個(gè)序列號構(gòu)成，請求方法和對應(yīng)的請求消息類型一致，序列號為隨機(jī)產(chǎn)生的一個(gè)整數(shù)。Call-ID是用來將消息分組的唯一標(biāo)識，SIP平臺采用一定的方法隨機(jī)生成Call-ID，保證全局唯一。Max-Forwards填寫為典型值70。Via頭字段主要是標(biāo)識了傳輸協(xié)議以及響應(yīng)消息應(yīng)該發(fā)往的地址，因此需要將當(dāng)前SIP協(xié)議棧的地址添加到Via中去，同時(shí)Via頭字段必須包含一個(gè)branch參數(shù)來標(biāo)識當(dāng)前請求所建立的事務(wù)，對于branch參數(shù)的生成也需要做到全局唯一。（2）請求消息的發(fā)送：主要是確定請求消息發(fā)送的目的地，對于UAC而言，可以有一個(gè)預(yù)置的路由集，這個(gè)通過本地策略進(jìn)行配置，代表的是UAC希望請求在到達(dá)目的地之前途徑的中間節(jié)點(diǎn)的集合，讀取配置將此路由集放在請求消息的Route頭中。除了通過本地策略以外，還可以通過DNS查詢來獲取請求需要發(fā)往的IP地址和端口。（3）響應(yīng)消息的處理：UAC還需要對它所發(fā)出的請求的響應(yīng)進(jìn)行處理，這些響應(yīng)可能是成功響應(yīng)，也可能是臨時(shí)響應(yīng)或者是錯(cuò)誤響應(yīng)等，TU對響應(yīng)消息的處理主要依賴于請求方法，但也有一些通用的處理原則，比如消息在事務(wù)層出錯(cuò)，無法到達(dá)TU層，TU定時(shí)器超時(shí)后，收到的為408的超時(shí)響應(yīng)。

3.3 UAS行為的支持

SIP支持UAS的行為，所做的工作主要是處理請求以及針對請求的情況，產(chǎn)生對應(yīng)的響應(yīng)，具體包含以下情況。

（1）對請求進(jìn)行檢查：UAS收到請求后，可以對請求中的方法進(jìn)行識別，比如如果不支持某種請求方法，則需要回送一個(gè)405（不允許的請求方法）響應(yīng)。同時(shí)還要檢查Request-URI和To頭部以確定自己是否是這個(gè)請求的目的地，如果不是，就可拒絕從而產(chǎn)生一個(gè)403（禁止）響應(yīng)。（2）對消息內(nèi)容進(jìn)行處理：UAS要檢查消息體和描述消息體內(nèi)容的頭字段，主要涉及到的頭字段有Content-Type（指示消息體類型）、Content-Language（指示語言）、Content-Encoding（指示編碼）等字段進(jìn)行檢查。（3）產(chǎn)生響應(yīng)：除了對請求檢查出錯(cuò)回送對應(yīng)的異常響應(yīng)以外，針對部分請求可以發(fā)送臨時(shí)響應(yīng)，比如INVITE請求，可以回送100（正在嘗試）、180（振鈴）等臨時(shí)響應(yīng)。但是成功或者失敗的最終響應(yīng)只有一個(gè)。

3.4 proxy行為的支持

SIP平臺除了實(shí)現(xiàn)UA的角色外，還可以實(shí)現(xiàn)網(wǎng)絡(luò)代理服務(wù)器proxy的角色，此時(shí)，SIP平臺作為一個(gè)中間實(shí)體，正常情況下，請求和響應(yīng)不是終結(jié)在SIP平臺，則SIP平臺所做的主要工作主要實(shí)現(xiàn)請求和響應(yīng)的轉(zhuǎn)發(fā)，此時(shí)對消息的轉(zhuǎn)發(fā)可以工作在有狀態(tài)模式下，也可以工作在無狀態(tài)模式下。

無狀態(tài)模式下，SIP平臺只是根據(jù)請求消息進(jìn)行簡單的路由分析和路由決策，然后直接將消息發(fā)送到下個(gè)目的地。有狀態(tài)模式下，TU層會通過維護(hù)狀態(tài)機(jī)來維護(hù)整個(gè)對話，對于請求和響應(yīng)，會建立Leg來存儲會話的相關(guān)信息，這些會話信息的存儲將會影響它對后續(xù)的、與先前接收的某一請求相關(guān)的消息的處理。

上述TU對于UAC、UAS、proxy等關(guān)鍵技術(shù)涉及到TU對各種正常以及異常流程的支持和處理，下圖4簡單描述建立SIP會話的基本流程圖，進(jìn)一步明確TU的這幾項(xiàng)功能。

圖4中，主叫用戶A和被叫用戶B都是支持SIP業(yè)務(wù)的終端，發(fā)起會話時(shí)，主叫A充當(dāng)UAC的角色，根據(jù)生成請求的原則產(chǎn)生請求消息INVITE。Proxy代理服務(wù)器接收到消息，對于INVITE消息則在有狀態(tài)模式下進(jìn)行處理，保存該消息的相關(guān)信息，并將消息轉(zhuǎn)發(fā)至被叫用戶B，被叫為UAS角色，根據(jù)收到請求的相關(guān)信息產(chǎn)生臨時(shí)響應(yīng)180及最終響應(yīng)200 OK，建立呼叫。

4 結(jié)語

在SIP平臺機(jī)制下，對于上層應(yīng)用都是屏蔽的，而SIP的內(nèi)部機(jī)制中，對于協(xié)議規(guī)定的基本功能都是滿足的，上層應(yīng)用可以根據(jù)網(wǎng)管上的配置，來選擇是作為UA的角色還是作為proxy的角色，協(xié)議平臺的TU層會根據(jù)配置建立數(shù)據(jù)區(qū)進(jìn)行對應(yīng)的處理，這樣就實(shí)現(xiàn)了同一套代碼的SIP平臺能應(yīng)對IMS系統(tǒng)中的多個(gè)網(wǎng)元，比如CSCF，PSS，MSCe等。協(xié)議平臺通用性增加，可維護(hù)性也大大提升，目前此設(shè)計(jì)在很多大型的通訊軟件中都獲得了應(yīng)用，效果良好。

參考文獻(xiàn)

[1]Rosenberg J.， Schulzrinne H.， Camarillo G.， Johnston A.， Peterson J.，Sparks R.， Handley M. and Schooler E. RFC 3261，SIP： Session Initiation Protocol[s].June 2002.

[2]周海華，邊恩炯.SIP原理與應(yīng)用[M].北京：機(jī)械工業(yè)出版社，2006：45-65.

[3]畢厚杰，李秀川.IMS與下一代網(wǎng)絡(luò)[M].北京：人民郵電出版社，2005：105-119.

[4]望玉梅，董文宇，周勝.IMS：IP多媒體概念和服務(wù)[M].北京：機(jī)械工業(yè)出版社，2007：289-299.