基于SIP協(xié)議的forking功能的研究和實現(xiàn)

曾麗君 魏麗 閔芳

摘要：SIP協(xié)議是用于建立、更改和終止呼叫的應(yīng)用層協(xié)議，在IMS系統(tǒng)中使用非常廣泛。而Fork是SIP中一個非常實用非常重要的功能，本文闡述了在Fork功能的基本原理，并在已有的SIP架構(gòu)上，分析了此功能的實現(xiàn)方法和具體的流程。

關(guān)鍵詞：SIP； TU； Fork

中圖分類號：TP393.0

文獻標識碼：A

DOI： 10.3969/j.issn.1003-6970.2015.07.025

0 SIP簡介

SIP（會話初始協(xié)議，RFC3261）是IETF定義的通過IP網(wǎng)絡(luò)建立和管理多媒體會話的協(xié)議，它采用的是眾所周知的客戶機服務(wù)器模式，它借鑒了SMTP（簡單郵件傳送協(xié)議，RFC2821）以及HTTP（超文本傳送協(xié)議，RFC2616）的原理，而這兩個協(xié)議是因特網(wǎng)上最成功的協(xié)議，同時，SIP是一個基于文本的協(xié)議，這意味著它更易于擴展、糾錯和構(gòu)建各種業(yè)務(wù)。因此，在IMS（IP多媒體子系統(tǒng)）中，選擇SIP作為其會話控制協(xié)議，更易于建立具有更大承載能力的業(yè)務(wù)。

根據(jù)協(xié)議標準定義及實際研制經(jīng)驗，協(xié)議平臺的SIP協(xié)議分析劃分為以下幾部分內(nèi)容： SIP事務(wù)用戶層（TU，Transaction User），事務(wù)層（TR，TRansaction），傳輸層（TP，TransPort），編解碼模塊（SIP PARSER/SDPPARSER，SIP協(xié)議編解碼及SDP編解碼），信令壓縮模塊（SIGCOMP）幾個協(xié)議主體部分。除了這幾個協(xié)議主體以外，SIP還需要實現(xiàn)和上層業(yè)務(wù)、數(shù)據(jù)庫以及底層承載之間的接口，方便進行數(shù)據(jù)以及消息的交互。

SIP協(xié)議的TU層是SIP協(xié)議主體的重要組成部分，它的功能包含幾個方面：（1）負責SIP消息到上層應(yīng)用進程的消息分發(fā)；對上層應(yīng)用屏蔽底層協(xié)議實現(xiàn)和分布式處理的細節(jié)；（2）對于需要創(chuàng)建對話的，維護對話的生命周期，管理對話的事務(wù)列表；（3）完成UAC， UAS或者代理pro xy的協(xié)議棧行為。

SIP采用的是一種offer/answer模型來描述會話。一個UA發(fā)起一個會話描述，稱為offer，另一個UA以另一個會話描述來進行響應(yīng)則為answer，一個offer/answer在一個Dialog上下文中進行交互，因為在具體實現(xiàn)SIP協(xié)議棧時，TU需要建立數(shù)據(jù)區(qū)來維護對話Dialog的相關(guān)信息，如圖1所示，TU是通過建立leg模型來維護dialog的，TU建立的數(shù)據(jù)區(qū)稱作leg，leg將會保存對于會話創(chuàng)建、會話釋放，處理請求、處理響應(yīng)所需要的一些關(guān)鍵信息，而這些信息是通過SIP消息從相應(yīng)的頭部中進行提取，和會話相關(guān)的主要頭部From，To以及Call-ID中的信息將都會保存在leg中。

數(shù)據(jù)區(qū)的創(chuàng)建根據(jù)協(xié)議棧的行為分為UA和proxy兩種情況。

Proxy方式下會存在一人一出兩個Leg對象，人呼側(cè)由TU收到事務(wù)層的初始請求而創(chuàng)建人呼側(cè)Leg對象，消息通過人呼側(cè)Leg處理后上報上層應(yīng)用，上層應(yīng)用處理結(jié)束后，轉(zhuǎn)發(fā)初始請求到TU的出呼側(cè)，TU進而創(chuàng)建出呼側(cè)Leg對象以及下發(fā)SIP消息。

UA方式下，作為被叫網(wǎng)元，TU協(xié)議棧收到事務(wù)的初始請求后，創(chuàng)建人呼Leg后，通過初始請求消息上報上層業(yè)務(wù)，上層業(yè)務(wù)處理完業(yè)務(wù)邏輯后，通過人呼Leg回送響應(yīng)到事務(wù)層。后續(xù)請求和響應(yīng)都是通過人呼Leg傳送。作為主叫網(wǎng)元，上層應(yīng)用調(diào)用發(fā)送初始請求接口到TU，TU創(chuàng)建出呼側(cè)Leg后，初始請求消息通過該Leg發(fā)送至事務(wù)層，后續(xù)請求和響應(yīng)都是通過出呼側(cè)Leg傳遞。

1 forking功能

fork即常說的分叉，一個請求可以分叉為發(fā)往多個目標地址的請求。假定B用戶為一號多機用戶，即一個SIP用戶可以同時在很多終端上注冊，每種終端可以實現(xiàn)不同的功能，比如便攜PC支持視頻而固定SIP電話可能功能簡潔，B用戶多個終端同時在線，當A用戶呼叫B用戶時，那么B用戶的多個終端都會收到呼叫請求，它的任意終端都可以去響應(yīng)這個呼叫。A最終會選擇一個終端創(chuàng)建會話。

在IMS中實現(xiàn)fork功能涉及到的網(wǎng)元類型分為終端（UA行為）以及代理服務(wù)器（proxy）行為，根據(jù)協(xié)議的描述，梳理不同網(wǎng)元的處理原則。

1.1 終端處理原則

（1）請求

根據(jù)協(xié)議的描述，只有初始對話（獨立事務(wù)）請求才會發(fā)生fork。終端可以在初始請求INVITE的碼流中的通過添加Request-Disposition頭部中指示代理進行fork的相關(guān)處理。同時，當被叫終端注冊了多個時，主叫終端可以添加Accept-Contact，Reject-Contact參數(shù)，指示代理選擇符合用戶偏好的被叫以及優(yōu)先級更高的被叫。

（2）響應(yīng)

當fork發(fā)生時，多個被叫終端都會對主叫產(chǎn)生響應(yīng)，未創(chuàng)建對話前，主叫終端可以接受或拒絕任何被叫終端的Fork應(yīng)答，如果終端拒絕fork臨時應(yīng)答，那么必須發(fā)送cancel或者bye請求，這些請求是針對每個終端即每一個fork的分支都需要發(fā)出。

主叫終端如果接收到被叫終端一個fork分支的成功應(yīng)答即2xx響應(yīng)，開始創(chuàng)建會話；應(yīng)該釋放其他fork分支的早對話和非早對話，具體釋放的方式根據(jù)各個fork分支的不同而不同。其中對于已經(jīng)收到了臨時響應(yīng)的fork分支，不管是否建立起了早對話，則發(fā)送CANCEL請求來釋放；對于沒有收到任何的臨時響應(yīng)的fork分支，則不能發(fā)送CANCEL請求，通過TU設(shè)置的保護定時器超時，來釋放該分支的相關(guān)資源。

主叫終端只能收到一條最終響應(yīng)，如果收到2xx響應(yīng)，則建立對話，如果為2xx以上的響應(yīng)，則認為無法建立呼叫，則需要釋放呼叫。

1.2 代理處理原則

（1）請求

提取碼流中fork和用戶喜好相關(guān)的字段，處理fork請求，比如到被叫的歸屬的服務(wù)器，需要將初始INVITE請求分叉為多個發(fā)送到被叫終端，對于非初始請求，需要進行轉(zhuǎn)發(fā)。

（2）響應(yīng)

立即轉(zhuǎn)發(fā)除100（Trying）以外的任何臨時響應(yīng)。立即轉(zhuǎn)發(fā)能成功建立對話的第一條2xx成功響應(yīng)，如果其中任意一個地址接收呼叫，該網(wǎng)絡(luò)服務(wù)器應(yīng)該向其它地址發(fā)送CANCEL消息，如果由于網(wǎng)絡(luò)時延而導(dǎo)致在代理服務(wù)器接收到多個200消息，代理服務(wù)器應(yīng)當將后續(xù)的200消息拒絕掉，不應(yīng)當后向轉(zhuǎn)發(fā)，這樣能保證只有一個終端能夠建立對話。

對于3xx類以上的非成功響應(yīng)，根據(jù)響應(yīng)碼的具體含義進行處理，比如3xx需要優(yōu)先傳到主教終端進行重定向，而對于4xx、5xx、6xx等非成功相應(yīng)，即先保存這些響應(yīng)，如果最后沒有收到任何2xx響應(yīng)，則根據(jù)協(xié)議規(guī)定的優(yōu)選的原則選擇響應(yīng)碼發(fā)送到主叫終端，結(jié)束整個會話。

2 SIP中fork的實現(xiàn)原理

SIP協(xié)議實現(xiàn)fork的基本邏輯功能：包括fo rk呼叫狀態(tài)維護，管理多個臨時響應(yīng)創(chuàng)建的對話，并在會話創(chuàng)建之前維持多個早對話出/人呼側(cè)消息的正確關(guān)聯(lián)關(guān)系。上層業(yè)務(wù)維護多個Contact的上下文與分叉呼叫之間的關(guān)系，分別對早對話進行承載控制。

2.1 確定是否發(fā)生fork

當被叫終端注冊了多個Contact地址時，SIP協(xié)議需要去提取碼流中的相關(guān)字段，通過Accept-Contact，Reject-Contact參數(shù)確定好被叫目標集，并按照優(yōu)先級將多個被叫終端進行排序，進一步的提取Request-Disposition頭部的關(guān)鍵信息，對是否需要進行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則需要被叫歸屬的代理服務(wù)器將初始的INVITE請求同時發(fā)送給多個被叫終端，既并行呼叫；若為“sequential”為串行fork，串行fork則不需要代理服務(wù)器將初始請求同時發(fā)送給多個被叫終端，而是逐個的發(fā)送，先發(fā)給第一個優(yōu)先級最高的被叫，如果接通，則不需要進行后續(xù)處理，如果沒有成功接續(xù)，則繼續(xù)發(fā)送給第二個被叫，依次類推。

2.2 TU中會話的維護

從前面SIP的簡介我們得知，TU需要去維護會話dialog，而對于dialog的維護，TU需要創(chuàng)建數(shù)據(jù)區(qū)Leg去保存相應(yīng)的信息，fork情況下，可能存在同時發(fā)起多路fork分支的呼叫，而多個被叫終端的對話信息是不完全相同的，如果把所有的信息都保存在簡單情況下的一個Leg數(shù)據(jù)區(qū)里，則容易引起一些誤操作，邏輯很不清楚，所以，可以采用TU維護多對數(shù)據(jù)區(qū)的方式來解決。

普通呼叫情況下，SIP的TU層只需要維護人呼側(cè)和出呼側(cè)的一對Leg即可，這樣所有的消息都通過這一對Leg來進行關(guān)鍵信息的記錄以及轉(zhuǎn)發(fā)。而fork情況下，由于終端有多個，而每個終端都可以傳送不同的請求和響應(yīng)到主叫終端，為了對每個終端的信息進行彼此獨立的進行保存，TU為每一個終端建立對應(yīng)的數(shù)據(jù)區(qū)Leg，具體如圖2所示，圖2和圖1比較可以看出，fork情況下，TU的人呼側(cè)和出呼側(cè)分別有多個Leg，而且人呼側(cè)和出呼側(cè)是一一對應(yīng)的，比如In Leg（0）和Out Leg（0）是對應(yīng)第一個被叫終端，用來記錄第一個別叫終端和主叫之間的會話信息，并進行這一分支呼叫的消息轉(zhuǎn)發(fā)，而In Leg（l）和Out Leg（l）是為主叫終端和第二個被叫終端服務(wù)的。當然，不管是fork的第一個分支還是第二個分支和主叫發(fā)生聯(lián)系，這都是屬于當前的這一個完整的會話，因此兩路分支之間也可能有信息的交互，此時可以通過CALL這樣的一個空間來保存兩者的數(shù)據(jù)區(qū)索引，方便通過一個人呼叫的Leg能很快的訪問到另一個分支的Leg。

3 具體流程

SIP的具體流程要分為并行和串行兩種情形，分別進行介紹：

3.1 并行流程

在并行流程中主叫的請求會同時被發(fā)送給兩個別叫用戶，具體流程如圖3所示，其中User AgentA為主叫用戶，User Agent B，C為被叫用戶，Proxy Server是IMS系統(tǒng)中的某個具體的網(wǎng)元，是代理服務(wù)器，主要是起到消息轉(zhuǎn)發(fā)以及完成fork功能的作用。

各步驟的具體含義如下：

主叫用戶A發(fā)起請求INVITE到代理服務(wù)器，對應(yīng)圖上消息（1）；

假定此代理服務(wù)器是被叫歸屬地的網(wǎng)元，它能檢測到有多個被叫聯(lián)系contact地址，同時通過Request-Disposition確定為發(fā)生并行fork，于是，向兩個被叫用戶B和C發(fā)起INVITE請求，對應(yīng)圖上消息（2）和（3）；

兩個被叫用戶收到INVITE請求后，提示用戶并振鈴，都發(fā)送180（ Ringing）消息通過代理服務(wù)器傳給主叫用戶，主叫用戶能同時聽到兩個被叫的回鈴音，對應(yīng)圖上消息（4）（5）（6）（7），此時，兩路別叫的180消息中的To頭部的tag值是不一樣的，這樣代理服務(wù)器中實現(xiàn)SIP的TU層就可以維護兩個leg，來保存兩路的不同會話信息；

兩個被叫用戶都會送響應(yīng)，上圖中被叫用戶B接通呼叫，產(chǎn)生2000K的應(yīng)答，而被叫用戶C則回送4XX消息，顯示忙，代理服務(wù)器接收到兩個被叫的不同應(yīng)答，需要進行處理，它主動地對被叫用戶C回送ACK，以結(jié)束被叫用戶C之間的呼叫，同時將被叫用戶B的200 OK轉(zhuǎn)發(fā)到主叫側(cè)，具體對應(yīng)圖上的（8）（9）（10）（11）；

主叫收到成功響應(yīng)后，回送ACK消息到被叫用戶B予以證實，呼叫建立，對應(yīng)圖上的（12）和（13）；

主叫掛機，發(fā)送BYE消息，被叫回應(yīng)200 0K響應(yīng)，整個通話結(jié)束，對應(yīng)圖上的（14）（15）（16）（17）。

3.2 串行流程

在并行流程中主叫的請求會按照優(yōu)先級先后發(fā)送給兩個被叫用戶，具體流程如圖4所示：

各步驟的具體含義如下：

主叫用戶A發(fā)起請求INVITE到代理服務(wù)器，對應(yīng)圖上消息（1）；

假定此代理服務(wù)器是被叫歸屬地的網(wǎng)元，它能檢測到有多個被叫聯(lián)系co ntact地址，同時通過Request-Disposition確定為發(fā)生串行fork，就需要根據(jù)兩個被叫用戶的優(yōu)先級，優(yōu)先級通過Accept-Contact，Reject-Contact等參數(shù)按照RFC3841協(xié)議規(guī)定的原則進行權(quán)值的計算，假定用戶B的優(yōu)先級高于用戶C，代理服務(wù)器現(xiàn)將INVITE轉(zhuǎn)發(fā)給用戶B，對應(yīng)圖上消息（2）；

被叫用戶B收到INVITE請求后，提示用戶并振鈴，并發(fā)送180（Ringing）消息通過代理服務(wù)器傳給主叫用戶，主叫用戶能聽到被叫用戶B的回鈴音，對應(yīng)圖上消息（3）（4）；

被叫用戶B忙，因此回送4XX消息，代理服務(wù)器接收后，由于是fo rk情況，因此不將此失敗響應(yīng)發(fā)送給主叫用戶，直接給被叫用戶回送ACK確認，并將此初始請求消息INVITE繼續(xù)發(fā)送到第二個用戶C，對應(yīng)圖上消息（5）（6）（7）；

被叫用戶C收到INVITE請求后，提示用戶并振鈴，并發(fā)送180（Ringing）消息通過代理服務(wù)器傳給主叫用戶，并進一步的發(fā)送200 0K響應(yīng)接續(xù)通話，對應(yīng)圖上消息（8）（9）（10）（11）；

主叫收到成功響應(yīng)后，回送ACK消息到被叫用戶B予以證實，呼叫建立，對應(yīng)圖上的（12）和（13）；

主叫掛機，發(fā)送BYE消息，被叫回應(yīng)200 0K響應(yīng)，整個通話結(jié)束，對應(yīng)圖上的（14）（15）（16）（17）。

4 結(jié)束語

總體來說，fork功能的實現(xiàn)是比較復(fù)雜的，SIP協(xié)議層面要考慮非常多的異常情況，比如所有被叫用戶都無法建議呼叫、或者兩個被叫同時回送2000K成功響應(yīng)等情況，而且整個功能的完成，還需要底層以及上層業(yè)務(wù)的配合，比如考慮如何對兩個被叫都建立媒體通道等問題，這些在本文中沒有闡述，本文主要介紹的是在現(xiàn)有的SIP架構(gòu)的基礎(chǔ)上，通過TU層維護多路呼叫的數(shù)據(jù)區(qū)的方法去實現(xiàn)fork功能，目前此方案已經(jīng)在企業(yè)中采用并實現(xiàn)。