平臺化思路下SIPTU的設計與實現(xiàn)

曾麗君　魏麗　閔芳

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

關鍵詞：SIP TU UA proxy

中圖分類號：TP311.52 文獻標識碼：A 文章編號：1007-9416（2016）09-0179-02

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

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

1 SIP平臺實現(xiàn)架構

基于平臺化的設計思路，遵從IETF標準組織的RFC3261協(xié)議的描述對SIP協(xié)議進行構建。其整體架構如圖1所示。

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

2 TU總體介紹

2.1 TU在SIP平臺中的位置

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

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

2.2 TU模塊功能劃分

2.2.1 進程管理功能

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

2.2.2 TU層協(xié)議功能

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

3 TU關鍵技術

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

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

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

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

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

3.2 UAC行為的支持

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

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

3.3 UAS行為的支持

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

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

3.4 proxy行為的支持

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

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

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

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

4 結語

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

參考文獻

[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原理與應用[M].北京：機械工業(yè)出版社，2006：45-65.

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

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