- 相關推薦
基于SIP協(xié)議的forking功能的研究和實現(xiàn)
摘要：SIP協(xié)議是用于建立、更改和終止呼叫的應用層協(xié)議，在IMS系統(tǒng)中使用非常廣泛。而Fork是SIP中一個非常實用非常重要的功能，本文闡述了在Fork功能的基本原理，并在已有的SIP架構上，分析了此功能的實現(xiàn)方法和具體的流程。
關鍵詞：SIP; Fork; TU
SIP簡介
SIP(會話初始協(xié)議，RFC3261)是IETF定義的通過IP網(wǎng)絡建立和管理多媒體會話的協(xié)議，它采用的是眾所周知的客戶機服務器模式，它借鑒了SMTP(簡單郵件傳送協(xié)議，RFC2821)以及HTTP(超文本傳送協(xié)議，RFC2616)的原理，而這兩個協(xié)議是因特網(wǎng)上最成功的協(xié)議，同時，SIP是一個基于文本的協(xié)議，這意味著它更易于擴展、糾錯和構建各種業(yè)務。因此，在IMS(IP多媒體子系統(tǒng))中，選擇SIP作為其會話控制協(xié)議，更易于建立具有更大承載能力的業(yè)務。
根據(jù)協(xié)議標準定義及實際研制經(jīng)驗，協(xié)議平臺的SIP協(xié)議分析劃分為以下幾部分內(nèi)容： SIP事務用戶層(TU，Transaction User)，事務層(TR，TRansaction)，傳輸層(TP，TransPort)，編解碼模塊(SIP PARSER/SDPPARSER，SIP協(xié)議編解碼及SDP編解碼)，信令壓縮模塊(SIGCOMP)幾個協(xié)議主體部分。除了這幾個協(xié)議主體以外，SIP還需要實現(xiàn)和上層業(yè)務、數(shù)據(jù)庫以及底層承載之間的接口，方便進行數(shù)據(jù)以及消息的交互。
SIP協(xié)議的TU層是SIP協(xié)議主體的重要組成部分，它的功能包含幾個方面：(1)負責SIP消息到上層應用進程的消息分發(fā);對上層應用屏蔽底層協(xié)議實現(xiàn)和分布式處理的細節(jié);(2)對于需要創(chuàng)建對話的，維護對話的生命周期，管理對話的事務列表;(3)完成UAC， UAS或者代理pro xy的協(xié)議棧行為。
SIP采用的是一種offer/answer模型來描述會話。一個UA發(fā)起一個會話描述，稱為offer，另一個UA以另一個會話描述來進行響應則為answer，一個offer/answer在一個Dialog上下文中進行交互，因為在具體實現(xiàn)SIP協(xié)議棧時，TU需要建立數(shù)據(jù)區(qū)來維護對話Dialog的相關信息，如圖1所示，TU是通過建立leg模型來維護dialog的，TU建立的數(shù)據(jù)區(qū)稱作leg，leg將會保存對于會話創(chuàng)建、會話釋放，處理請求、處理響應所需要的一些關鍵信息，而這些信息是通過SIP消息從相應的頭部中進行提取，和會話相關的主要頭部From，To以及Call-ID中的信息將都會保存在leg中。
數(shù)據(jù)區(qū)的創(chuàng)建根據(jù)協(xié)議棧的行為分為UA和proxy兩種情況。
Proxy方式下會存在一人一出兩個Leg對象，人呼側由TU收到事務層的初始請求而創(chuàng)建人呼側Leg對象，消息通過人呼側Leg處理后上報上層應用，上層應用處理結束后，轉發(fā)初始請求到TU的出呼側，TU進而創(chuàng)建出呼側Leg對象以及下發(fā)SIP消息。
UA方式下，作為被叫網(wǎng)元，TU協(xié)議棧收到事務的初始請求后，創(chuàng)建人呼Leg后，通過初始請求消息上報上層業(yè)務，上層業(yè)務處理完業(yè)務邏輯后，通過人呼Leg回送響應到事務層。后續(xù)請求和響應都是通過人呼Leg傳送。作為主叫網(wǎng)元，上層應用調(diào)用發(fā)送初始請求接口到TU，TU創(chuàng)建出呼側Leg后，初始請求消息通過該Leg發(fā)送至事務層，后續(xù)請求和響應都是通過出呼側Leg傳遞。
一、forking功能
fork即常說的分叉，一個請求可以分叉為發(fā)往多個目標地址的請求。假定B用戶為一號多機用戶，即一個SIP用戶可以同時在很多終端上注冊，每種終端可以實現(xiàn)不同的功能，比如便攜PC支持視頻而固定SIP電話可能功能簡潔，B用戶多個終端同時在線，當A用戶呼叫B用戶時，那么B用戶的多個終端都會收到呼叫請求，它的任意終端都可以去響應這個呼叫。A最終會選擇一個終端創(chuàng)建會話。
在IMS中實現(xiàn)fork功能涉及到的網(wǎng)元類型分為終端(UA行為)以及代理服務器(proxy)行為，根據(jù)協(xié)議的描述，梳理不同網(wǎng)元的處理原則。
1.1 終端處理原則
(1)請求
根據(jù)協(xié)議的描述，只有初始對話(獨立事務)請求才會發(fā)生fork。終端可以在初始請求INVITE的碼流中的通過添加Request-Disposition頭部中指示代理進行fork的相關處理。同時，當被叫終端注冊了多個時，主叫終端可以添加Accept-Contact，Reject-Contact參數(shù)，指示代理選擇符合用戶偏好的被叫以及優(yōu)先級更高的被叫。
(2)響應
當fork發(fā)生時，多個被叫終端都會對主叫產(chǎn)生響應，未創(chuàng)建對話前，主叫終端可以接受或拒絕任何被叫終端的Fork應答，如果終端拒絕fork臨時應答，那么必須發(fā)送cancel或者bye請求，這些請求是針對每個終端即每一個fork的分支都需要發(fā)出。
主叫終端如果接收到被叫終端一個fork分支的成功應答即2xx響應，開始創(chuàng)建會話;應該釋放其他fork分支的早對話和非早對話，具體釋放的方式根據(jù)各個fork分支的不同而不同。其中對于已經(jīng)收到了臨時響應的fork分支，不管是否建立起了早對話，則發(fā)送CANCEL請求來釋放;對于沒有收到任何的臨時響應的fork分支，則不能發(fā)送CANCEL請求，通過TU設置的保護定時器超時，來釋放該分支的相關資源。
主叫終端只能收到一條最終響應，如果收到2xx響應，則建立對話，如果為2xx以上的響應，則認為無法建立呼叫，則需要釋放呼叫。
1.2 代理處理原則
(1)請求
提取碼流中fork和用戶喜好相關的字段，處理fork請求，比如到被叫的歸屬的服務器，需要將初始INVITE請求分叉為多個發(fā)送到被叫終端，對于非初始請求，需要進行轉發(fā)。
(2)響應
立即轉發(fā)除100(Trying)以外的任何臨時響應。立即轉發(fā)能成功建立對話的第一條2xx成功響應，如果其中任意一個地址接收呼叫，該網(wǎng)絡服務器應該向其它地址發(fā)送CANCEL消息，如果由于網(wǎng)絡時延而導致在代理服務器接收到多個200消息，代理服務器應當將后續(xù)的200消息拒絕掉，不應當后向轉發(fā)，這樣能保證只有一個終端能夠建立對話。
對于3xx類以上的非成功響應，根據(jù)響應碼的具體含義進行處理，比如3xx需要優(yōu)先傳到主教終端進行重定向，而對于4xx、5xx、6xx等非成功相應，即先保存這些響應，如果最后沒有收到任何2xx響應，則根據(jù)協(xié)議規(guī)定的優(yōu)選的原則選擇響應碼發(fā)送到主叫終端，結束整個會話。
二、SIP中fork的實現(xiàn)原理
SIP協(xié)議實現(xiàn)fork的基本邏輯功能：包括fo rk呼叫狀態(tài)維護，管理多個臨時響應創(chuàng)建的對話，并在會話創(chuàng)建之前維持多個早對話出/人呼側消息的正確關聯(lián)關系。上層業(yè)務維護多個Contact的上下文與分叉呼叫之間的關系，分別對早對話進行承載控制。
2.1 確定是否發(fā)生fork
當被叫終端注冊了多個Contact地址時，SIP協(xié)議需要去提取碼流中的相關字段，通過Accept-Contact，Reject-Contact參數(shù)確定好被叫目標集，并按照優(yōu)先級將多個被叫終端進行排序，進一步的提取Request-Disposition頭部的關鍵信息，對是否需要進行fork進行確定，該頭部的內(nèi)容如下：
proxy-directive=”proxy”
fork-directive="fork"/"no-fork"
parallel-directive="parallel"/"sequential"
其中proxy-directive確定當前的網(wǎng)元是否為代理proxy，fork-directive是用來指示是否需要fork，當指示為”no-fork”時，雖然被叫有多個，但是初始請求只會發(fā)送給優(yōu)先級最高的被叫終端并不會產(chǎn)生分叉，如果指示為”fork”時，則進一步的讀取parallel-directive指示的值，parallel-directive若為“parallel”為并行fork，并行fork則需要被叫歸屬的代理服務器將初始的INVITE請求同時發(fā)送給多個被叫終端，既并行呼叫;若為“sequential”為串行fork，串行fork則不需要代理服務器將初始請求同時發(fā)送給多個被叫終端，而是逐個的發(fā)送，先發(fā)給第一個優(yōu)先級最高的被叫，如果接通，則不需要進行后續(xù)處理，如果沒有成功接續(xù)，則繼續(xù)發(fā)送給第二個被叫，依次類推。
2.2 TU中會話的維護
從前面SIP的簡介我們得知，TU需要去維護會話dialog，而對于dialog的維護，TU需要創(chuàng)建數(shù)據(jù)區(qū)Leg去保存相應的信息，fork情況下，可能存在同時發(fā)起多路fork分支的呼叫，而多個被叫終端的對話信息是不完全相同的，如果把所有的信息都保存在簡單情況下的一個Leg數(shù)據(jù)區(qū)里，則容易引起一些誤操作，邏輯很不清楚，所以，可以采用TU維護多對數(shù)據(jù)區(qū)的方式來解決。
普通呼叫情況下，SIP的TU層只需要維護人呼側和出呼側的一對Leg即可，這樣所有的消息都通過這一對Leg來進行關鍵信息的記錄以及轉發(fā)。而fork情況下，由于終端有多個，而每個終端都可以傳送不同的請求和響應到主叫終端，為了對每個終端的信息進行彼此獨立的進行保存，TU為每一個終端建立對應的數(shù)據(jù)區(qū)Leg，具體如圖2所示，圖2和圖1比較可以看出，fork情況下，TU的人呼側和出呼側分別有多個Leg，而且人呼側和出呼側是一一對應的，比如In Leg(0)和Out Leg(0)是對應第一個被叫終端，用來記錄第一個別叫終端和主叫之間的會話信息，并進行這一分支呼叫的消息轉發(fā)，而In Leg(l)和Out Leg(l)是為主叫終端和第二個被叫終端服務的。當然，不管是fork的第一個分支還是第二個分支和主叫發(fā)生聯(lián)系，這都是屬于當前的這一個完整的會話，因此兩路分支之間也可能有信息的交互，此時可以通過CALL這樣的一個空間來保存兩者的數(shù)據(jù)區(qū)索引，方便通過一個人呼叫的Leg能很快的訪問到另一個分支的Leg。
三、具體流程
SIP的具體流程要分為并行和串行兩種情形，分別進行介紹：
3.1 并行流程
在并行流程中主叫的請求會同時被發(fā)送給兩個別叫用戶，具體流程如圖3所示，其中User AgentA為主叫用戶，User Agent B，C為被叫用戶，Proxy Server是IMS系統(tǒng)中的某個具體的網(wǎng)元，是代理服務器，主要是起到消息轉發(fā)以及完成fork功能的作用。
各步驟的具體含義如下：
主叫用戶A發(fā)起請求INVITE到代理服務器，對應圖上消息(1);
假定此代理服務器是被叫歸屬地的網(wǎng)元，它能檢測到有多個被叫聯(lián)系contact地址，同時通過Request-Disposition確定為發(fā)生并行fork，于是，向兩個被叫用戶B和C發(fā)起INVITE請求，對應圖上消息(2)和(3);
兩個被叫用戶收到INVITE請求后，提示用戶并振鈴，都發(fā)送180( Ringing)消息通過代理服務器傳給主叫用戶，主叫用戶能同時聽到兩個被叫的回鈴音，對應圖上消息(4)(5)(6)(7)，此時，兩路別叫的180消息中的To頭部的tag值是不一樣的，這樣代理服務器中實現(xiàn)SIP的TU層就可以維護兩個leg，來保存兩路的不同會話信息;
兩個被叫用戶都會送響應，上圖中被叫用戶B接通呼叫，產(chǎn)生2000K的應答，而被叫用戶C則回送4XX消息，顯示忙，代理服務器接收到兩個被叫的不同應答，需要進行處理，它主動地對被叫用戶C回送ACK，以結束被叫用戶C之間的呼叫，同時將被叫用戶B的200 OK轉發(fā)到主叫側，具體對應圖上的(8)(9)(10)(11); 主叫收到成功響應后，回送ACK消息到被叫用戶B予以證實，呼叫建立，對應圖上的(12)和(13);
主叫掛機，發(fā)送BYE消息，被叫回應200 0K響應，整個通話結束，對應圖上的(14)(15)(16)(17)。
3.2 串行流程
在并行流程中主叫的請求會按照優(yōu)先級先后發(fā)送給兩個被叫用戶，具體流程如圖4所示：
各步驟的具體含義如下：
主叫用戶A發(fā)起請求INVITE到代理服務器，對應圖上消息(1);
假定此代理服務器是被叫歸屬地的網(wǎng)元，它能檢測到有多個被叫聯(lián)系co ntact地址，同時通過Request-Disposition確定為發(fā)生串行fork，就需要根據(jù)兩個被叫用戶的優(yōu)先級，優(yōu)先級通過Accept-Contact，Reject-Contact等參數(shù)按照RFC3841協(xié)議規(guī)定的原則進行權值的計算，假定用戶B的優(yōu)先級高于用戶C，代理服務器現(xiàn)將INVITE轉發(fā)給用戶B，對應圖上消息(2);
被叫用戶B收到INVITE請求后，提示用戶并振鈴，并發(fā)送180(Ringing)消息通過代理服務器傳給主叫用戶，主叫用戶能聽到被叫用戶B的回鈴音，對應圖上消息(3)(4);
被叫用戶B忙，因此回送4XX消息，代理服務器接收后，由于是fo rk情況，因此不將此失敗響應發(fā)送給主叫用戶，直接給被叫用戶回送ACK確認，并將此初始請求消息INVITE繼續(xù)發(fā)送到第二個用戶C，對應圖上消息(5)(6)(7);
被叫用戶C收到INVITE請求后，提示用戶并振鈴，并發(fā)送180(Ringing)消息通過代理服務器傳給主叫用戶，并進一步的發(fā)送200 0K響應接續(xù)通話，對應圖上消息(8)(9)(10)(11);
主叫收到成功響應后，回送ACK消息到被叫用戶B予以證實，呼叫建立，對應圖上的(12)和(13);
主叫掛機，發(fā)送BYE消息，被叫回應200 0K響應，整個通話結束，對應圖上的(14)(15)(16)(17)。
四、結束語
總體來說，fork功能的實現(xiàn)是比較復雜的，SIP協(xié)議層面要考慮非常多的異常情況，比如所有被叫用戶都無法建議呼叫、或者兩個被叫同時回送2000K成功響應等情況，而且整個功能的完成，還需要底層以及上層業(yè)務的配合，比如考慮如何對兩個被叫都建立媒體通道等問題，這些在本文中沒有闡述，本文主要介紹的是在現(xiàn)有的SIP架構的基礎上，通過TU層維護多路呼叫的數(shù)據(jù)區(qū)的方法去實現(xiàn)fork功能，目前此方案已經(jīng)在企業(yè)中采用并實現(xiàn)。
【基于SIP協(xié)議的forking功能的研究和實現(xiàn)】相關文章：
基于SIP(會話初始協(xié)議)的語音瀏覽器的研究與實現(xiàn)03-07
基于WIFI-SIP的固定移動融合實現(xiàn)方案03-07
一種基于SIP和移動IP的切換機制的研究03-07
基于功能實現(xiàn)的成本管理狀況評價內(nèi)容研究03-23
基于主機的3D網(wǎng)絡應用的研究和實現(xiàn)03-03
基于ＡＳＰ網(wǎng)絡銷售系統(tǒng)的實現(xiàn)與研究03-23