公用信道技術(shù)在ＶｏＩＰ中的應用

摘要：隨著 Internet 的發(fā)展，VoIP獲得了廣泛應用。目前的VoIP有多種協(xié)議，但是傳統(tǒng)VoIP服務器只能夠支持單一的協(xié)議，不同VoIP協(xié)議的互通問題始終是VoIP發(fā)展中的核心問題。本文基于公用信道思想，介紹了一種使用多協(xié)議的VoIP技術(shù)。

關(guān)鍵詞：VoIP；公用信道；服務器

中圖分類號：TP393文獻標識碼：A文章編號：1009-3044(2008)24-1185-04

在VoIP通信過程中，服務器要為每個客戶端創(chuàng)建一個信道來維持與其通信。這種用于和客戶端保持通信的信道稱為協(xié)議信道。如圖1所示，傳統(tǒng)的VoIP服務器都是由上層控制模塊來直接控制協(xié)議信道，由于上層控制模塊和底層協(xié)議信道相關(guān)，無法實現(xiàn)對不同類型協(xié)議信道的控制，因此傳統(tǒng)VoIP服務器只能夠支持單一的協(xié)議。如果能夠設計出可同時支持多種協(xié)議的服務器，那么它就可以對各種協(xié)議進行處理和轉(zhuǎn)換，從而解決不同VoIP協(xié)議的互通問題。

1 公用信道的思想

為了解決分布異構(gòu)問題，人們提出了中間件的概念。中間件是位于平臺(硬件和操作系統(tǒng))和具體應用之間的通用服務，這些服務具有標準的程序接口和協(xié)議。中間件能夠屏蔽操作系統(tǒng)和網(wǎng)絡協(xié)議的差異，為應用程序提供多種通訊機制，并提供相應的平臺以滿足不同領域的需要。因此，中間件為應用程序提供了一個相對穩(wěn)定的高層應用環(huán)境。這里借鑒了中間件的思想，在底層協(xié)議信道和上層控制模塊之間添加一類特殊的信道，稱為公用信道。圖2描述了增加公用信道以后服務器控制協(xié)議信道的方式。通過公用信道將上層控制模塊和底層協(xié)議信道相分離。公用信道提供了一系列的接口，上層控制模塊只需通過這些接口就可以控制公用信道，從而達到管理和控制整個會話過程的目的，而不必關(guān)注底層協(xié)議信道具體使用的是哪種VoIP協(xié)議。

2 公用信道接口

2.1 會話模型

不同VoIP協(xié)議雖然在信令、媒體傳輸方式上存在不同，但服務器建立會話的過程都大致分為以下幾個階段：

呼叫開始：當服務器收到客戶端的呼叫請求后，建立主叫用戶信道。然后查找被叫用戶地址，創(chuàng)建與被叫用戶通信的信道。

呼叫被叫：在主被叫信道建立之后，開始向被叫用戶發(fā)送能夠呼叫請求消息，并等待被叫用戶應答。

通話：服務器收到被叫用戶應答后，就開始轉(zhuǎn)發(fā)主被叫用戶的語音數(shù)據(jù)。

呼叫結(jié)束：當收到主叫或被叫用戶的掛機請求后，服務器分別拆除主被叫信道，結(jié)束通話。

公用信道可以根據(jù)服務器建立會話的過程，抽象出一系列與會話相關(guān)(呼叫、應答、掛機)的接口，以便上層控制模塊使用這些接口來管理和調(diào)度公用信道，從而控制整個會話過程。

2.2 接口的多態(tài)性

多態(tài)性提供了接口和實現(xiàn)的分離，也就是說把做什么和怎么做分開來。多態(tài)性不但能改善代碼的接口，提高其可讀性，而且能創(chuàng)建可擴展的程序。

由于公用信道位于各協(xié)議信道之上，公用信道的這些接口的實現(xiàn)是和底層協(xié)議信道相關(guān)的。根據(jù)底層VoIP協(xié)議的不同，這些接口的實現(xiàn)方法有很大的差別。因此可采用多態(tài)性的思想來設計公用信道接口。由公用信道中定義上層控制模塊調(diào)用的接口，而這些接口的實現(xiàn)交給底層各協(xié)議信道來完成。

在會話過程中，控制模塊只需調(diào)用這些接口來控制會話，程序會根據(jù)底層信道類型的不同，調(diào)用相應的函數(shù)，公用信道因此表現(xiàn)出不同的行為。這樣公用信道就屏蔽了底層協(xié)議信道的差異性，從而解決了不同VoIP協(xié)議的互通問題。

這種方式還具有良好的擴展性。當需要增加對一種新協(xié)議的支持，只需在底層實現(xiàn)公用信道定義的這些接口，而不必對公用信道和上層控制模塊做任何改動。

2.3 多態(tài)性的實現(xiàn)

由于公用信道接口在實現(xiàn)上的多態(tài)性，這里使用結(jié)構(gòu)體com_channel_tech來封裝公用信道的接口。該結(jié)構(gòu)體中包含了很多函數(shù)指針，這些函數(shù)指針指向接口的具體實現(xiàn)。根據(jù)底層協(xié)議信道類型的不同，底層使用不同的函數(shù)來填充com_channel_tech中的各個字段以實現(xiàn)這些接口。當上層控制模塊調(diào)用某一接口時，系統(tǒng)根據(jù)會根據(jù)com_channel_tech的具體類型(底層使用的協(xié)議)調(diào)用相應的函數(shù)。這樣我們就屏蔽了底層協(xié)議信道的差異性，為上層控制模塊的調(diào)用提供了統(tǒng)一的接口。上層只需調(diào)用這些接口，就可以實現(xiàn)對公用信道的統(tǒng)一管理和調(diào)度，而不必關(guān)注在底層采用的是哪種協(xié)議。

例如，當接收到SIP請求，創(chuàng)建公用信道時，上層控制模塊只需直接調(diào)用com_request接口，從而間接調(diào)用結(jié)構(gòu)體com_channel_tech中request函數(shù)指針所指的sip_request函數(shù)。而對于IAX協(xié)議，相應的函數(shù)就換成了iax_request函數(shù)。

3 協(xié)議映射

3.1 公用幀

為了便于上層控制模塊管理會話，公用信道中只使用一種協(xié)議來傳輸信令和語音，這種協(xié)議稱為公用協(xié)議。以公用協(xié)議格式封裝的幀稱為公用幀(COM幀)。從客戶端發(fā)送到協(xié)議信道的各種協(xié)議幀，必須首先轉(zhuǎn)換成COM幀后才能送入公用信道，然后由控制模塊對其進一步處理。從公用信道發(fā)往客戶端的COM幀，需要根據(jù)底層協(xié)議信道的類型，進行相應的幀格式轉(zhuǎn)換后才能發(fā)送。

由于公用信道既要處理信令又要轉(zhuǎn)發(fā)語音數(shù)據(jù)，所以COM幀分為信令幀和語音幀兩種類型。信令幀主要用于控制會話的進程，而語音幀用于傳輸實際的語音數(shù)據(jù)。采用結(jié)構(gòu)體com_frame來表示COM幀：

struct com_frame {

int frametype;

int subclass;

int datalen;

int samples;

void *data;

struct timeval delivery;

};

其中frametype字段用于說明COM幀的類型屬于信令幀(COM_FRAME_CONTROL)還是語音幀(COM_FRAME_VOICE)。

對于信令幀，只有subclass字段有意義，該字段用于說明信令幀表示的具體控制信息。

對于語音幀，subclass字段代表該語音幀使用的編碼格式；datalen表示語音幀長度；samples表示采樣點數(shù)；delivery表示發(fā)送時間戳；指針data指向?qū)嶋H的語音數(shù)據(jù)。

3.2 信令幀的映射

底層信道的各種協(xié)議幀在送入公用信道之前需要轉(zhuǎn)化成COM幀。從公用信道中出來的COM幀需要轉(zhuǎn)化成協(xié)議信道能處理的幀。不同協(xié)議幀之間的轉(zhuǎn)換過程稱為協(xié)議映射。協(xié)議映射關(guān)系的制定是實現(xiàn)VoIP互通的前提和保證。

3.3 語音幀的映射

為了保證語音在轉(zhuǎn)發(fā)時不會失真，COM幀在傳輸語音時必須包含以下信息：語音編碼格式、語音數(shù)據(jù)長度、采樣點數(shù)、發(fā)送時間戳以及實際的語音數(shù)據(jù)。因此，其它協(xié)議幀在轉(zhuǎn)化成COM幀時，必須完成以上內(nèi)容的轉(zhuǎn)換。

1)IAX幀映射到COM幀：對于IAX協(xié)議，語音是通過Mini幀來傳輸?shù)模陂_始發(fā)送語音和固定時間間隔內(nèi)發(fā)送Full幀來同步語音幀。由于Mini幀只包含16位的時間戳和語音數(shù)據(jù)，協(xié)議信道需要將先前從Full幀中獲得的語音編碼格式subclass和32位的時間戳記錄下來。這樣，語音數(shù)據(jù)的編碼格式可以從對應的協(xié)議信道獲得。語音數(shù)據(jù)長度可由Mini幀幀長減去幀頭長度得出。采樣點數(shù)是根據(jù)數(shù)據(jù)長度和編碼格式計算得出。時間戳由Full幀的高16位和Mini幀的16位組合而成。原始語音數(shù)據(jù)直接存入到COM幀的data字段。IAX幀的其他信息與轉(zhuǎn)發(fā)語音無關(guān)，均保存在協(xié)議信道之中。

2)RTP幀映射到COM幀：對于SIP協(xié)議的客戶端，語音數(shù)據(jù)通常是通過RTP幀來傳送的。從RTP幀轉(zhuǎn)化成COM幀，時間戳可以直接從RTP幀頭的timestamp字段取得，語音編碼格式從PT字段中得到，語音數(shù)據(jù)長度可由幀長減去幀頭長度計算得出，采樣點數(shù)也是根據(jù)數(shù)據(jù)長度和編碼格式計算得出，而原始的語音數(shù)據(jù)直接存入到相應字段。

4 語音傳輸方式

在呼叫建立之后，客戶端開始語音通信。語音傳輸方式有兩種：一種是P2P方式，另一種是服務器轉(zhuǎn)發(fā)方式(Server Relay)。

4.1 P2P方式

P2P方式是指語音數(shù)據(jù)直接從一個客戶端發(fā)送到另一個客戶端。P2P傳輸方式具有降低網(wǎng)絡時延、減輕服務器負荷等優(yōu)點。但不是任何客戶端之間都可以建立P2P連接的。除了通信雙方需要知道彼此的地址外，P2P還要具備如下條件：

1)通信雙方采用相同的信令和語音傳輸方式。也就是說客戶端采用的是相同的VoIP協(xié)議。

2)如果通信的一方或雙方的網(wǎng)絡中存在NAT，語音數(shù)據(jù)要能夠穿越對方的NAT。

3)通信雙方要能夠理解對方所發(fā)送的語音數(shù)據(jù)。也就是說，發(fā)送語音數(shù)據(jù)的編碼格式要能夠為對方所支持。

對于滿足上述條件的會話，服務器在建立呼叫后會調(diào)用com_bridge函數(shù)，嘗試為客戶端之間建立P2P連接。如果建立P2P成功，服務器就釋放與客戶端通信的信道，由客戶端之間直接進行語音通信。

4.2 服務器轉(zhuǎn)發(fā)方式

對于不滿足建立P2P條件的客戶端之間的會話，需要由服務器轉(zhuǎn)發(fā)雙方的語音數(shù)據(jù)，也就是說客戶端先將語音數(shù)據(jù)發(fā)送給服務器，由服務器轉(zhuǎn)發(fā)到另一個客戶端。根據(jù)會話類型的不同，服務器的轉(zhuǎn)發(fā)方式又分為以下兩種。

1)經(jīng)過公用信道的轉(zhuǎn)發(fā)

對于不同客戶端的語音通信，語音數(shù)據(jù)需要進行協(xié)議類型、語音編碼格式的轉(zhuǎn)換，這些都是由公用信道負責完成的。因此，語音數(shù)據(jù)要送入公用信道處理。圖3描述了SIP和IAX客戶端進行語音通信的過程。下面以SIP客戶端向IAX客戶端發(fā)送語音通信為例，來說明語音數(shù)據(jù)的傳輸路徑。SIP客戶端的語音以RTP幀的形式發(fā)送到服務器的RTP信道中，被轉(zhuǎn)換成COM幀后送入到所在的公用信道。公用信道將其發(fā)送給與IAX客戶端對應的公用信道。然后調(diào)用相應的接口函數(shù)將COM幀轉(zhuǎn)換成IAX幀后，發(fā)送至IAX客戶端。

2)不經(jīng)公用信道的轉(zhuǎn)發(fā)

對于同類型客戶端的通信，由于語音數(shù)據(jù)不需要進行協(xié)議、編碼格式的轉(zhuǎn)換，可以將其直接發(fā)送到對方的協(xié)議信道中。所以可以優(yōu)化上面的傳輸路徑。圖4描述了IAX客戶端之間進行語音通信的過程，一方的語音數(shù)據(jù)以Mini幀格式發(fā)送到服務器，然后由IAX信道直接將該Mini幀發(fā)送到對方的IAX信道。這樣語音數(shù)據(jù)就不必經(jīng)過雙方的公用信道，也不需要對幀類型進行轉(zhuǎn)換，因而提高了語音數(shù)據(jù)的傳輸效率，減少了時延。

5 公用信道的通信

5.1 收發(fā)COM幀

每個公用信道都維護著一個readq隊列，該隊列是由COM幀組成的。協(xié)議信道發(fā)給公用信道的COM幀都是先送入該隊列中。當服務器監(jiān)聽到某個公用信道有COM幀時，調(diào)用接口函數(shù)com_read，從該公用信道的readq隊列中讀取COM幀進行處理。

對于要發(fā)送給客戶端的COM幀，直接調(diào)用公用信道提供的接口函數(shù)com_write即可。該函數(shù)的實現(xiàn)是由底層完成的，根據(jù)底層協(xié)議信道類型的不同，先將COM幀轉(zhuǎn)化成對應的協(xié)議幀，然后調(diào)用套接字函數(shù)sendto將其發(fā)往客戶端。

5.2 IO多路轉(zhuǎn)接

如前所述，會話建立后上層控制模塊要同時管理和控制主被叫兩個公用信道，監(jiān)聽主被叫信道的readq隊列是否有COM幀到來。如果采用傳統(tǒng)的IO阻塞技術(shù)，那么線程就可能長時間阻塞在一個信道上，而另一個信道雖然有很多數(shù)據(jù)卻不能得到及時處理。在這種情況下，我們使用IO多路轉(zhuǎn)接技術(shù)來同時監(jiān)聽多個信道。

所謂IO多路轉(zhuǎn)接技術(shù)，是先構(gòu)造一張有關(guān)描述符(公用信道)的列表，然后調(diào)用poll函數(shù)，同時監(jiān)聽這些信道，直到這些信道中的一個已準備好進行IO(有數(shù)據(jù)發(fā)生)時，該函數(shù)立即返回。在返回時，它會告訴進程哪個信道有數(shù)據(jù)發(fā)生。poll函數(shù)的定義如下：

#include

int poll(struct pollfd fdarray[]，nfds_t nfds，int timeout);

參數(shù)：fdarray 數(shù)組中的每一個元素對應一個描述符(公用信道)

nfds描述符的個數(shù)

timeout 監(jiān)聽(等待)時間

返回值：準備就緒的描述符，若超時則返回0，若出錯返回－1

5.3 管道機制

COM幀是由底層的發(fā)送線程送至公用信道的readq隊列中，而監(jiān)聽公用信道是由上層控制模塊的線程來完成的。由于發(fā)送COM幀和監(jiān)聽COM幀是由服務器的不同線程控制，因此需要建立管道機制來解決線程間的通信問題。

在每個公用信道創(chuàng)建的時候，定義了一個alterpipe[2]的數(shù)組，用于建立通知管道。其中alterpipe[0]對應于管道的讀端口，alterpipe[1]作為管道的寫端口。在開始呼叫后，服務器會調(diào)用poll函數(shù)來監(jiān)聽公用信道的讀端口alterpipe[0]。

當有數(shù)據(jù)送入到readq隊列，底層發(fā)送線程控制該信道對應管道的寫端口alterpipe[1]向讀端口alterpipe[0]發(fā)送一個通知信號(通常是一個字符)。當讀端口接收到該信號后，poll函數(shù)就立即返回，并告訴系統(tǒng)哪個信道有數(shù)據(jù)請求處理。服務器就從該信道對應的readq隊列中讀取出COM幀。這個過程可由圖5來描述。

6 互通實例

下面就以IAX與SIP互通為例，說明互通過程中協(xié)議的映射過程。這里以SIP客戶端發(fā)起呼叫和先掛機為例，呼叫的具體流程如圖6所示，圖中省略了一些次要消息的交互過程。

6.1 呼叫建立

主叫方SIP協(xié)議信道收到呼叫請求后，立即建立主叫公用信道。并分析被叫號碼，根據(jù)被叫客戶端的類型，建立相應的被叫公用信道以及到被叫客戶端的協(xié)議信道。這樣，雙方就可以開始建立呼叫。SIP客戶端呼叫IAX客戶端的信令過程描述如圖5所示：

1)SIP客戶端向服務器的SIP信道發(fā)送INVITE消息；2)SIP信道收到INVITE消息，立即創(chuàng)建主叫公用信道，并向SIP客戶端發(fā)送100 Trying消息，確認收到呼叫請求，服務器正在處理中；3)SIP信道將INVITE消息翻譯成COM_CONTROL_INVITE消息，并發(fā)送到主叫公用信道中；4)當公用信道收到該消息后，立即創(chuàng)建一個新線程，接入到上層控制模塊，分析被叫號碼，查找被叫地址，并根據(jù)被叫客戶端類型分別創(chuàng)建被叫公用信道和被叫IAX信道，以便與IAX客戶端通信；5)被叫公用信道將COM_CONTROL_INVITE消息轉(zhuǎn)換成NEW消息發(fā)送給IAX信道；6)IAX信道將該消息發(fā)送給IAX客戶端；7)IAX客戶端發(fā)送ACCEPT消息確認建立連接；8)IAX客戶端發(fā)送RINGING消息，表示其正在振鈴中；9)IAX信道將RINGING消息轉(zhuǎn)化成COM_CONTROL_RINGING消息，發(fā)送給被叫公用信道；10)被叫公用信道將該消息轉(zhuǎn)發(fā)給主叫公用信道；11)主叫公用信道將COM_CONTROL_RINGING消息翻譯成180 Ringing消息，發(fā)送給SIP信道；12)SIP信道將該消息發(fā)送給SIP客戶端；13)IAX客戶端發(fā)送ANSWER，表示被叫端已經(jīng)應答。ANSWER消息按與Ringing消息類似傳送過程轉(zhuǎn)化成200 OK消息發(fā)送給SIP客戶端。呼叫建立完成，雙方開始語音通信。

6.2 語音轉(zhuǎn)發(fā)

SIP協(xié)議采用的是RTP傳輸語數(shù)據(jù)音，而且收發(fā)語音的端口不同于SIP協(xié)議端口(2N，2N＋1，N為隨機整數(shù))；IAX是信令和語音是共享端口的，使用Mini幀傳輸語音。同前面的信令映射方法類似，語音幀也需要經(jīng)過RTP/Mini幀 COM幀 Mini/RTP幀的轉(zhuǎn)化過程。

6.3 呼叫釋放

呼叫結(jié)束的過程如圖6所示：28)SIP客戶端向服務器的SIP信道發(fā)送BYE消息，請求結(jié)束會話；29)SIP信道收到BYE消息，立即向SIP客戶端發(fā)送ACK消息，確認收到結(jié)束；30)SIP信道將BYE消息翻譯成COM_CONTROL_HANGUP消息，并發(fā)送給主叫公用信道中；31)主叫公用信道將COM_CONTROL_HANGUP消息發(fā)送給被叫公用信道，并釋放主叫公用信道和SIP信道；32)被叫公用信道向IAX信道發(fā)送HANGUP消息；33)IAX信道向IAX客戶端發(fā)送HANGUP消息；34)IAX客戶端向IAX信道發(fā)送ACK消息，表示已收到釋放請求。服務器釋放被叫公用信道和IAX信道。

參考文獻：

[1] 張登銀，孫精科.VoIP技術(shù)分析與系統(tǒng)設計[M].北京:人民郵電出版社，2003.

[2] Abbasi T， Prasad S， Seddigh N.， Lambadaris I. A Comparative study of the SIP and IAX VoIP protocols.Electrical and Computer Engineering，2005.Canadian Conference on1-4 May 2005 Page(s):179-183.

[3] 糜正琨.IP網(wǎng)絡電話技術(shù)[M].北京:人民郵電出版社，2000.

[4] Mahler P.VoIP Telephony with Asterisk[M].2004.

[5] 黃鷹，朱木成，李暉.軟交換IP信令互通的研究與實現(xiàn)[J].光通信研究，2006(5):22-24.