平臺化思路下SIPTU的設計與實現

曾麗君　魏麗　閔芳

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

關鍵詞：SIP TU UA proxy

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

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

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

1 SIP平臺實現架構

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

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

2 TU總體介紹

2.1 TU在SIP平臺中的位置

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

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

2.2 TU模塊功能劃分

2.2.1 進程管理功能

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

2.2.2 TU層協議功能

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

3 TU關鍵技術

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

3.1 TU數據區機制

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

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

通常情況下，存儲在Leg中的對話狀態信息由對話ID、本地序列號、遠端序列號、本地URI、遠端URI、遠端目的地、路由集、對話狀態等組成，這些信息也是通過收到的請求或者響應進行賦值和修改。以入呼側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發出請求時，請求消息會通過一些代理服務器被轉發到UAS，而UAS產生一個響應后，響應消息會以同樣的方式被轉發到UAC。因此，對于UAC的基本行為包含幾個方面：產生請求消息、請求消息的發送以及響應消息的處理。

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

3.3 UAS行為的支持

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

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

3.4 proxy行為的支持

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

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

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

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

4 結語

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

參考文獻

[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].北京：機械工業出版社，2006：45-65.

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

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