基于SIP協議的forking功能的研究和實現

曾麗君 魏麗 閔芳

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

關鍵詞：SIP； TU； Fork

中圖分類號：TP393.0

文獻標識碼：A

DOI： 10.3969/j.issn.1003-6970.2015.07.025

0 SIP簡介

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

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

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

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

數據區的創建根據協議棧的行為分為UA和proxy兩種情況。

Proxy方式下會存在一人一出兩個Leg對象，人呼側由TU收到事務層的初始請求而創建人呼側Leg對象，消息通過人呼側Leg處理后上報上層應用，上層應用處理結束后，轉發初始請求到TU的出呼側，TU進而創建出呼側Leg對象以及下發SIP消息。

UA方式下，作為被叫網元，TU協議棧收到事務的初始請求后，創建人呼Leg后，通過初始請求消息上報上層業務，上層業務處理完業務邏輯后，通過人呼Leg回送響應到事務層。后續請求和響應都是通過人呼Leg傳送。作為主叫網元，上層應用調用發送初始請求接口到TU，TU創建出呼側Leg后，初始請求消息通過該Leg發送至事務層，后續請求和響應都是通過出呼側Leg傳遞。

1 forking功能

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

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

1.1 終端處理原則

（1）請求

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

（2）響應

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

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

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

1.2 代理處理原則

（1）請求

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

（2）響應

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

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

2 SIP中fork的實現原理

SIP協議實現fork的基本邏輯功能：包括fo rk呼叫狀態維護，管理多個臨時響應創建的對話，并在會話創建之前維持多個早對話出/人呼側消息的正確關聯關系。上層業務維護多個Contact的上下文與分叉呼叫之間的關系，分別對早對話進行承載控制。

2.1 確定是否發生fork

當被叫終端注冊了多個Contact地址時，SIP協議需要去提取碼流中的相關字段，通過Accept-Contact，Reject-Contact參數確定好被叫目標集，并按照優先級將多個被叫終端進行排序，進一步的提取Request-Disposition頭部的關鍵信息，對是否需要進行fork進行確定，該頭部的內容如下：

proxy-directive=”proxy”

fork-directive="fork"/"no-fork"

parallel-directive="parallel"/"sequential"

其中proxy-directive確定當前的網元是否為代理proxy，fork-directive是用來指示是否需要fork，當指示為”no-fork”時，雖然被叫有多個，但是初始請求只會發送給優先級最高的被叫終端并不會產生分叉，如果指示為”fork”時，則進一步的讀取parallel-directive指示的值，parallel-directive若為“parallel”為并行fork，并行fork則需要被叫歸屬的代理服務器將初始的INVITE請求同時發送給多個被叫終端，既并行呼叫；若為“sequential”為串行fork，串行fork則不需要代理服務器將初始請求同時發送給多個被叫終端，而是逐個的發送，先發給第一個優先級最高的被叫，如果接通，則不需要進行后續處理，如果沒有成功接續，則繼續發送給第二個被叫，依次類推。

2.2 TU中會話的維護

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

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

3 具體流程

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

3.1 并行流程

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

各步驟的具體含義如下：

主叫用戶A發起請求INVITE到代理服務器，對應圖上消息（1）；

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

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

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

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

主叫掛機，發送BYE消息，被叫回應200 0K響應，整個通話結束，對應圖上的（14）（15）（16）（17）。

3.2 串行流程

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

各步驟的具體含義如下：

主叫用戶A發起請求INVITE到代理服務器，對應圖上消息（1）；

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

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

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

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

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

主叫掛機，發送BYE消息，被叫回應200 0K響應，整個通話結束，對應圖上的（14）（15）（16）（17）。

4 結束語

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