3G交互式視頻網(wǎng)關(guān)的設計與實(shí)現方案

　　圖4 3G-324M 協(xié)議棧結構

　　從圖中可以看出，所設計的3G-324M 協(xié)議棧一共有3 個(gè)邏輯信道，分別是H.245 控制消息信道、音頻信道和視頻信道。由應用自上而下傳遞的控制消息翻譯成對應的H.245消息，經(jīng)過(guò)CCSR（Control ChannelSegmentation and Reassembly Layer，簡(jiǎn)稱(chēng)CCSR）分段后交NSRP（Numbered Simple RetransmissionProtocol，簡(jiǎn)稱(chēng)NSRP）加上序列號，加入到控制消息發(fā)送隊列中，由應用自上而下傳遞的音頻和視頻數據經(jīng)過(guò)H.223 的適配層進(jìn)行適配后，也加入到相應的媒體數據發(fā)送隊列中，H.223 的復用層分別從各隊列中取得數據復用后通過(guò)3G 網(wǎng)絡(luò )發(fā)送到3G 手機上。對于從3G網(wǎng)絡(luò )得到的數據，協(xié)議棧自下而上通過(guò)H.223 進(jìn)行解復用到各邏輯信道的接收隊列中，應用從各邏輯信道提取控制消息或媒體數據進(jìn)行處理。

　　在設計3G-324M 協(xié)議棧音視頻發(fā)送機制的時(shí)候，考慮到媒體流中視頻的數據量較大，而電路域提供給視頻的帶寬只有40kbps 左右，所以如果不做適當處理，肯定會(huì )出現音頻超前視頻的情形。因此為音頻數據流設計一個(gè)緩沖區，只有當音頻緩沖區中音頻包的個(gè)數大于一定域值的時(shí)候，才會(huì )發(fā)送音頻數據，這樣就最大限度的避免了可能出現的音視頻不同步的問(wèn)題。

　　在設計協(xié)議間媒體格式轉換機制，特別是在將RTP 格式的H.263 視頻數據轉換成3G-324M 協(xié)議棧能處理的視頻幀的時(shí)候，由于RTP 封裝的H.263視頻數據在圖像開(kāi)始碼處字節對齊，具有填充位，如果不去掉填充位直接發(fā)送到3G 手機終端，則會(huì )出現馬賽克，所以設計了一個(gè)H.263 視頻幀的緩沖區，將連續兩個(gè)圖像開(kāi)始碼之間的視頻幀緩沖起來(lái)，以去掉幀間的填充位。具體的處理流程是讓程序掃描H.263格式的視頻流緩沖區，每遇到圖像開(kāi)始碼便將其之后的視頻幀緩沖起來(lái)，緩沖區的大小動(dòng)態(tài)分配，直到遇到下一個(gè)圖像開(kāi)始碼，然后將兩個(gè)圖像開(kāi)始碼之間的視頻數據去掉填充位后發(fā)送到3G-324M 協(xié)議棧。

3 網(wǎng)關(guān)的實(shí)現

　　在實(shí)現的時(shí)候，用到的硬件主要包括PC 機一臺和E1 板卡一塊，用到的軟件主要包括Linux 操作系統和實(shí)驗室已有的2G 語(yǔ)音網(wǎng)關(guān)平臺（該平臺主要提供應用程序接口、SIP 協(xié)議棧和E1 板卡驅動(dòng)程序），在此基礎上實(shí)現了3G 交互式視頻網(wǎng)關(guān)，其中最主要的是實(shí)現了3G-324M 協(xié)議棧以及3G-324M 協(xié)議與SIP協(xié)議間媒體格式和控制消息的轉換。

　　3.1 3G-324M協(xié)議棧的實(shí)現設計的主要數據結構包括：

　　H324M： 提供協(xié)議棧對外的統一接口，包括H324M：：Int（），H324M：：Demux（），H324M：：Mutex（）等。其中H324M：：Init（）接口初始化3G-324M 協(xié)議棧， H324M：：Demux（）接口解復用從B 信道收到的數據，H324M：：Mutex（）將音頻、視頻和控制消息復用后，發(fā)送到3G 手機終端。

　　H324MChannels： 音視頻信道、控制信道和復用/解復用器等資源的容器，并通過(guò)回調的形式向上層傳遞消息。

　　AudioChannel： 音頻信道，包含H223 適配層等資源，提供的接口包括AudioChannel：：GetFrame（），AudioChannel：：S-endFrame（）。

　　VideoChannel： 視頻信道，包含H223 適配層等資源，提供的接口包括VideoChannel：：GetFrame（），VideoChannel：：S-endFrame（）。

　　ControlChannel： 控制信道，實(shí)現了CCSR、NSRP協(xié)議。

　　H223ALReceiver： H223 協(xié)議的適配層，負責對從3G 手機接收到的數據進(jìn)行檢錯。

　　H223ALSender： H223 協(xié)議的適配層，負責對發(fā)發(fā)送到3G手機的數據進(jìn)行適配并追加所計算的校驗和。

　　H223Demuxer： H223 協(xié)議的復用層，負責解復用從3G 手機接收到的數據，并將解復用后的數據根據數據類(lèi)型分別添加到音頻、視頻和控制消息接收隊列中。

　　H223Muxer： H223 協(xié)議的復用層，將從IP 域一側收到的音頻、視頻和控制消息復用到一個(gè)物理通道上，從3G 電路域一側發(fā)送到3G 手機上。

　　3.2 網(wǎng)關(guān)工作流程。

　　網(wǎng)關(guān)的主要工作是在3G 域與IP 域之間進(jìn)行控制消息和媒體格式的轉換，主程序的設計首先進(jìn)行3G-324M 協(xié)議棧等各種數據結構的初始化，然后在3G 域和IP 域兩個(gè)通道同時(shí)監聽(tīng)數據的到達。如果從監聽(tīng)返回的時(shí)候沒(méi)有數據到達，則意味著(zhù)某個(gè)通道出錯，此時(shí)進(jìn)行退出處理；如果從監聽(tīng)返回是因為3G域通道有數據到達，則將收到的數據根據3G-324M協(xié)議解復用后進(jìn)行格式轉換發(fā)送到IP 域的通道；如果從監聽(tīng)返回是因為IP 域通道有數據到達，則轉換格式后根據3G-324M 協(xié)議復用并發(fā)送到3G 域通道。在后兩種情況下，進(jìn)行完數據轉發(fā)后，繼續回到監聽(tīng)3G域通道和IP 域通道的狀態(tài)。程序流程圖如圖5 所示。

　　圖5 網(wǎng)關(guān)工作流程。

　　4 測試

　　聯(lián)合中科院沈陽(yáng)計算所網(wǎng)絡(luò )與通信實(shí)驗室的增值應用服務(wù)器在實(shí)際的3G 環(huán)境中對所實(shí)現的網(wǎng)關(guān)進(jìn)行了測試。在測試用例中，3G 交互式視頻網(wǎng)關(guān)被放在了臺灣宏遠電信的機房中，通過(guò)E1 板卡與交換機相連，并預先分配了一些測試號碼，增值應用服務(wù)器放在了互聯(lián)網(wǎng)的公網(wǎng)上。在臺灣的測試人員通過(guò)3G 手機撥打預先分配的測試號碼撥號到網(wǎng)關(guān)， 網(wǎng)關(guān)通過(guò)3G-324M 協(xié)議與3G 手機終端建立了視頻會(huì )話(huà)后，發(fā)送SIP INVITE 消息與增值應用服務(wù)器建立一個(gè)SIP會(huì )話(huà)，增值應用服務(wù)器將音視頻數據（在此測試用例中為一個(gè)3gp 格式的影音文件）發(fā)送到網(wǎng)關(guān)，網(wǎng)關(guān)將接收到的音視頻數據轉換格式后再發(fā)送到3G 手機，測試人員通過(guò)手機上的按鍵切換播放不同的影音文件，實(shí)現交互功能。測試數據如表1 所示，手機到網(wǎng)關(guān)的接通率在95%以上，接通時(shí)間控制在6 秒之內，手機端收到的音頻聲音清晰，視頻流暢，音視頻基本同步。

　　表1 測試數據

　　5 結語(yǔ)

　　本文在闡述3G 交互式視頻網(wǎng)關(guān)關(guān)鍵技術(shù)的基礎上，提出了該網(wǎng)關(guān)的一個(gè)具體的設計實(shí)現方法。該網(wǎng)關(guān)與增值應用服務(wù)器配合使用，可以用來(lái)在3G 通信網(wǎng)絡(luò )中提供交互式多媒體增值應用服務(wù)，通過(guò)在實(shí)際環(huán)境中進(jìn)行測試，該網(wǎng)關(guān)運行穩定，接通率高，對今后開(kāi)發(fā)類(lèi)似的系統具有借鑒的意義。