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