基于Blackfin 533的SIP網(wǎng)絡(luò )電話(huà)

作者：時(shí)間：2008-11-07 來(lái)源：網(wǎng)絡(luò )

加入技術(shù)交流群
- 掃碼加入
  和技術(shù)大咖面對面交流
  海量資料庫查詢(xún)

引言

近年來(lái)，Internet得到了飛速發(fā)展與普及，而作為其核心技術(shù)的IP協(xié)議體系在數據網(wǎng)絡(luò )架構中的統治地位已得到了廣泛認同。另外，隨著(zhù)IP技術(shù)框架中匯聚網(wǎng)絡(luò )研究的發(fā)展和VoIP(Voice over Internet Protoc01)技術(shù)的提出，數據網(wǎng)絡(luò )通信已經(jīng)融入傳統的話(huà)音業(yè)務(wù)領(lǐng)域，而且VoIP與生俱來(lái)的Internet血統使得其在應用方面有著(zhù)很強的拓展性，因此，VoIP技術(shù)和應用的研究成為了當今的熱點(diǎn)問(wèn)題。各大芯片廠(chǎng)商相繼推出了VoIP方案，比如ADI公司的Blackfin系列等。協(xié)議方面的研究也取得了豐碩的成果，其中SIP(Session Initiation Protoc01)協(xié)議憑借相對簡(jiǎn)單的實(shí)現模式和極強的擴展性受到了越來(lái)越多
的關(guān)注。ADI公司推出的Blackfin處理器是一類(lèi)專(zhuān)為滿(mǎn)足當今嵌入式音頻、視頻和通信應用的計算要求和功耗約束條件而設計的新型16／32位嵌入式處理器。該處理器基于A(yíng)DI和Intel公司聯(lián)合開(kāi)發(fā)的微信號架構(MSA)，擁有類(lèi)RISC型指令集、雙16位乘法器、雙40位邏輯運算單元(ALU)、40位桶形移位器和4個(gè)視頻運算單元(videoALUs)，將信號處理功能和通用型微控制器所具有的易用性組合在了一起。這種處理特征的組合使得Blackfin處理器能夠在信號處理和控制處理應用中均有較好的表現；與此同時(shí)，該能力也簡(jiǎn)化了硬件和軟件方面的設計。SIP類(lèi)似于HTTP協(xié)議，也是一個(gè)基于文本的協(xié)議，因而易于讀取和調試。與此同時(shí)，SIP協(xié)議在制訂時(shí)就考慮到了擴充性的問(wèn)題，通過(guò)增加新的消息類(lèi)型、消息頭和消息體即可實(shí)現新服務(wù)。即使不能支持基于SIP的舊設備也不會(huì )妨礙這些新服務(wù)。另外，SIP的一個(gè)重要特點(diǎn)是，它不定義要建立的會(huì )話(huà)的類(lèi)型，而只定義應該如何管理會(huì )話(huà)。有了這種靈活性，也就意味著(zhù)SIP可以用于眾多應用和服務(wù)中。本文介紹了一種基于Blackfin處理器平臺的網(wǎng)絡(luò )電話(huà)方案?？紤]未來(lái)應用的拓展需要和網(wǎng)絡(luò )電話(huà)的特點(diǎn)，選擇了Blackfin 533處理器和基于SIP的VoIP協(xié)議棧，實(shí)現了一系列的通話(huà)功能。

1 系統方案

鑒于Linux強大的網(wǎng)絡(luò )功能，結合Blackfin的硬件特點(diǎn)，采用μClinux作為操作系統；同時(shí)面向控制的操作系統、圖形化的人機界面以及復雜的網(wǎng)絡(luò )協(xié)議棧，增加了對MCU的要求，語(yǔ)音處理又需要高效的DSP算法，因此選用Blackfin 533作為核心處理器。系統框圖如圖1所示。

外圍硬件主要有ADl836、DM9000、LCD顯示屏和55鍵盤(pán)輸入設備。

軟件方面采用分層設計：

① 底層是驅動(dòng)層。完成硬件的配置和相關(guān)操作，并為上層提供硬件訪(fǎng)問(wèn)接口。
② 中間層是應用程序庫。完成上層應用所需的各種基本操作，并為上層提供豐富的API接口。SIP／SDPRTP／RTCP結合TCP／IP完成SIP信令交互、會(huì )話(huà)管理，以及控制實(shí)時(shí)語(yǔ)音數據的傳輸；Codec完成語(yǔ)音編解碼工作，目前支持PCMU、PCMA、GSM、Speex編碼；GUI庫提供具體的圖形顯示功能。

③ 上層是應用層。利用底層和中間層提供的接口，構建出話(huà)機終端具體應用。終端支持P2P和Proxy兩種通信模式，可以實(shí)現接聽(tīng)、掛機、呼叫保持／恢復、呼叫轉接、電話(huà)會(huì )議、音量調節、自動(dòng)注冊等功能。

2 硬件方案
Blackfin 533為核心處理器芯片。外圍輔以ADl836實(shí)現語(yǔ)音信號的采集和播放；DM9000實(shí)現網(wǎng)絡(luò )數據包的收發(fā)；TFT LCD顯示屏和鍵盤(pán)實(shí)現圖形界面顯示以及人機交互。硬件框圖如圖2所示。

3 軟件方案
在詳細分析功能需求的基礎上，采用并行的程序設計思想，將整個(gè)應用劃分為4部分，分別由4個(gè)線(xiàn)程來(lái)完成，如圖3所示。

① UI(User Interface)控制線(xiàn)程。負責響應用戶(hù)的鍵盤(pán)輸入和屏幕顯示的刷新以及傳遞消息給協(xié)議棧。

② Codec語(yǔ)音線(xiàn)程。完成語(yǔ)音數據的處理，主要包括:本地語(yǔ)音的采集和編碼,網(wǎng)絡(luò )語(yǔ)音數據的解碼、混音和播放等。

③ SIP信令交互線(xiàn)程。使用Socket套接字實(shí)現SIP數據報收發(fā)，并將解析后的消息提供給用戶(hù)或直接作出相應的反應。

④ RTP／RTCP收發(fā)線(xiàn)程。使用Socket套接字完成RTP／RTCP數據包收發(fā)。RTP傳送語(yǔ)音數據，RTCP可以提供數據分發(fā)、質(zhì)量反饋等相關(guān)信息。

在整個(gè)應用初始化時(shí)，會(huì )建立Sound Device Port和Conference Bridge兩個(gè)數據結構。前者代表本地的聲音設備，后者控制著(zhù)媒體數據在不同Port之間的傳送。Port結構體代表著(zhù)會(huì )話(huà)參與者，比如sound Device Port代表本地用戶(hù)，Media Stream Port代表遠端參與者。當UI控制線(xiàn)程探測到有外撥電話(huà)時(shí)，它會(huì )傳遞一個(gè)消息給SIP信令交互線(xiàn)程。隨后一個(gè)Media Transpor實(shí)體被創(chuàng )建出來(lái)(媒體流傳輸使用的是UDP)。該實(shí)體中的地址和端口號信息將被添加到本地SDP結構中，用于Invite會(huì )話(huà)的協(xié)
商過(guò)程。當用于本次通話(huà)的Offer或Answer會(huì )話(huà)確立之后(即協(xié)商已經(jīng)完成，雙方確定了通信的類(lèi)型)，根據通話(huà)雙方的SDP信息，就創(chuàng )建出來(lái)一個(gè)Media Session Info結構。接著(zhù)SIP信令交互線(xiàn)程會(huì )創(chuàng )建一個(gè)Media Session(多媒體會(huì )話(huà))結構。在這一過(guò)程中，按照在Me dia sessionInfo數據結構中的codec等設置信息，Media Stream被創(chuàng )建出來(lái)。與此同時(shí)，Media Stream和先前創(chuàng )建的MediaTransport也被連接到了一起。該Media Stream對象將以Port的形式注冊到Conference Bridge。接著(zhù)在Confer―ence Bridge中注冊的Media Stream Port會(huì )根據需要被連接到其他Port，從而實(shí)現語(yǔ)音數據的傳送。比如，將一個(gè)Media Stream Port和Sound Device Port相連，就可以實(shí)現語(yǔ)音的播放和采集。

RTP／RTCP數據包的接收并不包含在以上介紹的流程之中，而是由RTP／RTCP收發(fā)線(xiàn)程來(lái)負責的。這是通過(guò)將RTP和RTCP的Sockets注冊到一個(gè)IOQueue隊列中，然后通過(guò)select()來(lái)完成的。首先，Media Transport會(huì )將其Socket注冊到一個(gè)在初始化過(guò)程中創(chuàng )建的I0Queue上。RTP／RTCP收發(fā)線(xiàn)程會(huì )輪詢(xún)這個(gè)IOQueue，當一個(gè)RTP數據報被檢測到之后，輪詢(xún)函數會(huì )觸發(fā)on_rx_rtp()函數調用。這個(gè)回調函數是在一開(kāi)始Socket注冊的時(shí)候被Media Transport一同注冊到了IOQueue上的。接著(zhù)on_rx_rtp()會(huì )將收到的RTP數據包傳遞給Mediastream Port。Media Stream會(huì )將收到的RTP解包，更新相關(guān)統計數據，并將負載中的音頻數據放到Jitter Buffer中。RTP包的接收到這里就結束了，放到Jitter Buffer中的數據會(huì )被Codec語(yǔ)音線(xiàn)程處理。RTCP的接收過(guò)程與此類(lèi)似，只不過(guò)RTCP并不傳輸語(yǔ)音，而是提供語(yǔ)音傳輸方面的信息。根據這些信息，應用可以對會(huì )話(huà)作出動(dòng)態(tài)調整，從而提高通話(huà)的質(zhì)量。

整個(gè)音頻流都是由Codec語(yǔ)音線(xiàn)程來(lái)驅動(dòng)的，具體來(lái)說(shuō)是聲卡的回調函數。

當聲卡設備需要新的一幀數據播放到揚聲器時(shí)，回調函數play_cb()就會(huì )被調用。接著(zhù)Sound Device Port就會(huì )調用get_frame()函數，這會(huì )觸發(fā)Conference Bridge調用另外的get_frame()去收集在其注冊的所有Port的媒體流數據。Conference Bridge對Media Stream Port的一次get_frame()調用，會(huì )使得Media Stream Port從JitterBuffer中取出一個(gè)數據幀，按照配置好的Codec將其解碼(如果有包丟失，就會(huì )進(jìn)行Packet Lost Concealment／PLC)，并將解碼后的PCM數據幀傳遞給調用者。如果有必要，會(huì )將收集到的信號混合(比如多方通話(huà))，然后再將信號發(fā)送到它的目的Port，從而完成音頻數據在Port之間的傳遞(不單單是播放流程，這個(gè)過(guò)程對聲音的采集也是很重要的，因為只有這個(gè)過(guò)程可以完成數據在Port之間的交換)。之后，Conference Bridge會(huì )把聲卡設備需要的數據發(fā)送到Sound Device Port。

當聲卡設備完成了一幀數據的采集后，它就會(huì )調用rec_cb()回調函數。這將會(huì )導致Conference Bridge的put_frame()函數調用。put_frame()函數調用會(huì )將PCM數據幀保存在一個(gè)內部的緩沖隊列中，當下次ConferenceBridge輪詢(xún)Port時(shí)，這些數據將會(huì )被傳遞給目的Port。該Media Stream Port會(huì )將這個(gè)PCM數據幀按照配置好的codec進(jìn)行編碼，然后將其封裝為RTP數據報，更新RTCP，然后將RTP／RTCP數據報傳遞給與其相連的Media Transport，最后Media Transport就會(huì )將數據報發(fā)送到網(wǎng)絡(luò )。數據流框圖如圖4所示。

4 功能測試
4．1 測試環(huán)境
為了驗證這部網(wǎng)絡(luò )電話(huà)的功能，我們搭建了一個(gè)實(shí)驗環(huán)境。這個(gè)實(shí)驗環(huán)境包括：

① 一臺單獨的主機運行SER(SIP Express Router)，來(lái)實(shí)現服務(wù)器的功能，包括注冊服務(wù)器、重定向服務(wù)器和代理服務(wù)器等SIP邏輯上的實(shí)體；

② 運行X―Lite的主機，用來(lái)作為遠端客戶(hù)機，和網(wǎng)絡(luò )電話(huà)處于對等的狀態(tài)，用來(lái)進(jìn)行呼叫、接受呼叫等功能性實(shí)驗；

③ Blackfin網(wǎng)絡(luò )電話(huà)，以下簡(jiǎn)稱(chēng)為“BF533網(wǎng)絡(luò )電話(huà)”。

它們都以以太網(wǎng)的方式接入同一個(gè)局域網(wǎng)中。實(shí)驗環(huán)境的示意圖如圖5所示。Ethereal是本次實(shí)驗中用到的監聽(tīng)工具。

4．2 界面簡(jiǎn)介
用戶(hù)界面如圖6所示。

靠近顯示區的頂端是音量顯示區。小圖標指明了顯示音量的種類(lèi)；音量顯示采用遞增柱體，分為6級。緊挨著(zhù)音量顯示區的是狀態(tài)顯示區。這部分包括Server狀態(tài)信息顯示區、Call狀態(tài)信息顯示區、當前通話(huà)狀態(tài)信息顯示區和號碼輸入顯示區。底部是菜單顯示區。從左到右分別為：選擇上一通話(huà)、選擇下一通話(huà)、呼叫轉接、呼叫保持、增大麥克音量、減小麥克音量、增大揚聲器音量、減小揚聲器音量、電話(huà)會(huì )議。

4．3 功能測試
(1)注冊

注冊過(guò)程如圖7所示。BF533網(wǎng)絡(luò )電話(huà)和SER服務(wù)器共交換了兩條消息：一條是目標系統向服務(wù)器發(fā)送的REGISTER請求消息，另一條是服務(wù)器發(fā)送的200 OK消息。

(2) 呼叫過(guò)程

呼叫過(guò)程如圖8所示。BF533網(wǎng)絡(luò )電話(huà)(BP)先是向SER服務(wù)器發(fā)送了一條INⅥTE消息(M1)，要求與遠端客戶(hù)機(RC)進(jìn)行對話(huà)。SER馬上回復一條100 Trying消息(M2)表示正在嘗試連接。然后SER將INⅥTE消息加入相關(guān)的Record―Route和Via頭部域以后成為消息M3，發(fā)送給RC。RC回復一個(gè)100 Trying消息(M4)給SER，然后再發(fā)送180Ringing(M5)給SER，表示正在響鈴中。SER將M5中它的Via和Record―R0ute頭部域去掉以后，成為消息M6發(fā)送給BP。在RC接受本次呼叫以后，它發(fā)送一個(gè)200 OK(M7)給SER。SER去掉Via以后，發(fā)送M8給BP。收到M8以后，BP發(fā)送ACK(M9)給RC。之后，雙方之間的通話(huà)就建立了起來(lái)。當會(huì )話(huà)結束時(shí)，BP發(fā)送BYE(M11)給RC，之后，RC返回200 OK(M14)，這次通話(huà)就結束了。(被叫過(guò)程和呼叫過(guò)程相似。)

(3)呼叫轉接

該過(guò)程是通過(guò)擴展的SIP信令REFER來(lái)完成的，交互過(guò)程如圖9所示。當BF533網(wǎng)絡(luò )電話(huà)要將它和遠端客戶(hù)機1(RCl)的通話(huà)轉接到遠端客戶(hù)機2(RC2)時(shí)，BF發(fā)送REFER(M1)給RCl，該信息中Refer―To字頭標明了RC2的URL，之后RCl回復202 Accepted(M2)給BP表明接受轉接。隨后，RCl和RC2之間會(huì )有類(lèi)似于通話(huà)建立過(guò)程的信令交互INVITE(M3)，100 Trying(M4)，180Ringing(M7)、200 OK(M10)，RCl會(huì )通過(guò)NOTIFY將轉接狀態(tài)告知BP，最后RCl回復ACK(M13)給RC2建立通話(huà)，同時(shí)其與BP的通話(huà)就斷開(kāi)了。

(4)呼叫保持／恢復

呼叫保持并沒(méi)有專(zhuān)門(mén)的信令，而是將INVITE信令體SDP中的Connection Information(c)參數設為空(即(IPV4)0.O.O.0)來(lái)實(shí)現的。 BF533網(wǎng)絡(luò )電話(huà)遠端客戶(hù)機遠端各尸機回復200 0K接受保持，如圖10所示。同理，呼叫恢復就是將c參數恢復原值，過(guò)程與呼叫保持相同。