基于Blackfin 533的SIP网络电话

引 言

近年来，Internet得到了飞速发展与普及，而作为其核心技术的IP协议体系在数据网络架构中的统治地位已得到了广泛认同。另外，随着IP技术框架中汇聚网络研究的发展和VoIP(Voice over Internet Protocol)技术的提出，数据网络通信已经融入传统的话音业务领域，而且VoIP与生俱来的Internet血统使得其在应用方面有着很强的拓展性，因此，VoIP技术和应用的研究成为了当今的热点问题。各大芯片厂商相继推出了VoIP方案，比如ADI公司的Blackfin系列等。协议方面的研究也取得了丰硕的成果，其中SIP(Session Initiation Protocol)协议凭借相对简单的实现模式和极强的扩展性受到了越来越多的关注。

ADI公司推出的Blackfin处理器是一类专为满足当今嵌入式音频、视频和通信应用的计算要求和功耗约束条件而设计的新型16／32位嵌入式处理器。该处理器基于ADI和InteI公司联合开发的微信号架构(MSA)，拥有类RISC型指令集、双16位乘法器、双40位逻辑运算单元(ALU)、40位桶形移位器和4个视频运算单元(videoALUS)，将信号处理功能和通用型微控制器所具有的易用性组合在了一起。这种处理特征的组合使得Blackfin处理器能够在信号处理和控制处理应用中均有较好的表现；与此同时，该能力也简化了硬件和软件方面的设计。

SIP类似于HTTP协议，也是一个基于文本的协议，因而易于读取和调试。与此同时，SIP协议在制订时就考虑到了扩充性的问题，通过增加新的消息类型、消息头和消息体即可实现新服务。即使不能支持基于SIP的旧设备也不会妨碍这些新服务。另外，SIP的一个重要特点是，它不定义要建立的会话的类型，而只定义应该如何管理会话。有了这种灵活性，也就意味着SIP可以用于众多应用和服务中。

本文介绍了一种基于Blackfin处理器平台的网络电话方案。考虑未来应用的拓展需要和网络电话的特点，选择了Blackfin 533处理器和基于SIP的VoIP协议栈，实现了一系列的通话功能。

1 系统方案

鉴于Linux强大的网络功能，结合Blackfin的硬件特点，采用μClinux作为操作系统；同时面向控制的操作系统、图形化的人机界面以及复杂的网络协议栈，增加了对MCU的要求，语音处理又需要高效的DSP算法，因此选用Blackfin 533作为核心处理器。系统框图如图1所示。

外围硬件主要有AD1836、DM9000、LCD显示屏和5×5键盘输入设备。

软件方面采用分层设计：

①底层是驱动层。完成硬件的配置和相关操作，并为上层提供硬件访问接口。

②中间层是应用程序库。完成上层应用所需的各种基本操作，并为上层提供丰富的API接口。SIP／SDP、RTP／RTCP结合TCP／IP完成SIP信令交互、会话管理，以及控制实时语音数据的传输；Codec完成语音编解码工作，目前支持PCMU、PCMA、GSM、Speex编码；GUI库提供具体的图形显示功能。

③上层是应用层。利用底层和中间层提供的接口，构建出话机终端具体应用。终端支持P2P和Proxy两种通信模式，可以实现接听、挂机、呼叫保持／恢复、呼叫转接、电话会议、音量调节、自动注册等功能。

2 硬件方案

Blackfin 533为核心处理器芯片。外围辅以AD1836实现语音信号的采集和播放；DM9000实现网络数据包的收发；TFT LCD显示屏和键盘实现图形界面显示以及人机交互。硬件框图如图2所示。

3 软件方案

在详细分析功能需求的基础上，采用并行的程序设计思想，将整个应用划分为4部分，分别由4个线程来完成，如图3所示。

①UI(User Interface)控制线程。负责响应用户的键盘输入和屏幕显示的刷新以及传递消息给协议栈。

②Codec语音线程。完成语音数据的处理，主要包括：本地语音的采集和编码，网络语音数据的解码、混音和播放等。

③SIP信令交互线程。使用Socket套接字实现SIP数据报收发，并将解析后的消息提供给用户或直接作出相应的反应。

④RTP／RTCP收发线程。使用Socket套接字完成RTP／RTCP数据包收发。RTP传送语音数据，RTCP可以提供数据分发、质量反馈等相关信息。

在整个应用初始化时，会建立Sound Device Port和Conference Bridge两个数据结构。前者代表本地的声音设备，后者控制着媒体数据在不同Port之间的传送。Port结构体代表着会话参与者，比如Sound Device Port代表本地用户，Media Stream Port代表远端参与者。当UI控制线程探测到有外拨电话时，它会传递一个消息给SIP信令交互线程。随后一个Media Transport实体被创建出来(媒体流传输使用的是UDP)。该实体中的地址和端口号信息将被添加到本地SDP结构中，用于Invite会话的协商过程。当用于本次通话的Offer或Answer会话确立之后(即协商已经完成，双方确定了通信的类型)，根据通话双方的SDP信息，就创建出来一个Media Session Info结构。接着SIP信令交互线程会创建一个Media Session(多媒体会话)结构。在这一过程中，按照在Media SessionInfo数据结构中的Codec等设置信息，Media Stream被创建出来。与此同时，Media Stream和先前创建的MediaTransport也被连接到了一起。该Media Stream对象将以Port的形式注册到Conference Bridge。接着在Confer-ence Bridge中注册的Media Stream Port会根据需要被连接到其他Port，从而实现语音数据的传送。比如，将一个Media Stream Port和Sound Device Port相连，就可以实现语音的播放和采集。

RTP／RTCP数据包的接收并不包含在以上介绍的流程之中，而是由RTP／RTCP收发线程来负责的。这是通过将RTP和RTCP的Sockets注册到一个IOQueue队列中，然后通过select()来完成的。首先，Media Transport会将其Socket注册到一个在初始化过程中创建的IOQueue上。RTP／RTCP收发线程会轮询这个IOQueue，当一个RTP数据报被检测到之后，轮询函数会触发on_rx_rtp()函数调用。这个回调函数是在一开始Socket注册的时候被Media Transport一同注册到了IOQueue上的。接着on_rx_rtp()会将收到的RTP数据包传递给MediaStream Port。Media Stream会将收到的RTP解包，更新相关统计数据，并将负载中的音频数据放到Jitter Buffer中。RTP包的接收到这里就结束了，放到Jitter Buffer中的数据会被Codec语音线程处理。RTCP的接收过程与此类似，只不过RTCP并不传输语音，而是提供语音传输方面的信息。根据这些信息，应用可以对会话作出动态调整，从而提高通话的质量。

整个音频流都是由Codec语音线程来驱动的，具体来说是声卡的回调函数。

当声卡设备需要新的一帧数据播放到扬声器时，回调函数play_cb()就会被调用。接着Sound Devicc Port就会调用get_frame()函数，这会触发Conference Bridge调用另外的get_frame()去收集在其注册的所有Port的媒体流数据。Conference Bridge对Media Stream Port的一次get_frame()调用，会使得Media Stream Port从JitterBuffer中取出一个数据帧，按照配置好的Codec将其解码(如果有包丢失，就会进行Packet Lost Concealment／PLC)，并将解码后的PCM数据帧传递给调用者。如果有必要，会将收集到的信号混合(比如多方通话)，然后再将信号发送到它的目的Port，从而完成音频数据在Port之间的传递(不单单是播放流程，这个过程对声音的采集也是很重要的，因为只有这个过程可以完成数据在Port之间的交换)。之后，Conference Bridge会把声卡设备需要的数据发送到Sound Device Port。

当声卡设备完成了一帧数据的采集后，它就会调用rec_cb()回调函数。这将会导致Conference Bridge的put_frame()函数调用。put_frame()函数调用会将PCM数据帧保存在一个内部的缓冲队列中，当下次ConferenceBridge轮询Port时，这些数据将会被传递给目的Port。该Media Stream Port会将这个PCM数据帧按照配置好的codec进行编码，然后将其封装为RTP数据报，更新RTCP，然后将RTP／RTCP数据报传递给与其相连的Media Transport，最后Media Transport就会将数据报发送到网络。数据流框图如图4所示。

4 功能测试

4.1 测试环境

为了验证这部网络电话的功能，我们搭建了一个实验环境。这个实验环境包括：

①一台单独的主机运行SER(SIP Express Router)，来实现服务器的功能，包括注册服务器、重定向服务器和代理服务器等SIP逻辑上的实体；

②运行X-Lite的主机，用来作为远端客户机，和网络电话处于对等的状态，用来进行呼叫、接受呼叫等功能性实验；

③Blackfin网络电话，以下简称为“BF533网络电话”。

它们都以以太网的方式接入同一个局域网中。实验环境的示意图如图5所示。

Ethereal是本次实验中用到的监听工具。

4.2 界面简介

用户界面如图6所示。

靠近显示区的顶端是音量显示区。小图标指明了显示音量的种类；音量显示采用递增柱体，分为6级。

紧挨着音量显示区的是状态显示区。这部分包括Server状态信息显示区、Call状态信息显示区、当前通话状态信息显示区和号码输入显示区。

底部是菜单显示区。从左到右分别为：选择上一通话、选择下一通话、呼叫转接、呼叫保持、增大麦克音量、减小麦克音量、增大扬声器音量、减小扬声器音量、电话会议。

4.3 功能测试

(1)注 册

注册过程如图7所示。BF533网络电话和SER服务器共交换了两条消息：一条是目标系统向服务器发送的REGISTER请求消息，另一条是服务器发送的200 OK消息。

(2)呼叫过程

呼叫过程如图8所示。BF533网络电话(BP)先是向SER服务器发送了一条INVITE消息(M1)，要求与远端客户机(RC)进行对话。SER马上同复一条100 Trying消息(M2)表示正在尝试连接。然后SER将INVITE消息加入相关的Record～Route和Via头部域以后成为消息M3，发送给RC。RC回复一个100 Trying消息(M4)给SER，然后再发送180 Ringing(M5)给SER，表示正在响铃中。SER将M5中它的Via和Record～Route头部域去掉以后，成为消息M6发送给BP。在RC接受本次呼叫以后，它发送一个200 OK(M7)给SER。SER去掉Via以后，发送M8给BP。收到M8以后，BP发送ACK(M9)给RC。之后，双方之间的通话就建立了起来。当会话结束时，BP发送BYE(M11)给RC，之后，RC返回200 OK(M14)，这次通话就结束了。(被叫过程和呼叫过程相似。)

(3)呼叫转接

该过程是通过扩展的SIP信令REFER来完成的，交互过程如图9所示。当BF533网络电话要将它和远端客户机1(RC1)的通话转接到远端客户机2(RC2)时，BF发送REFER(M1)给RC1，该信息中Refer-To字头标明了RC2的URL，之后RC1回复202 Accepted(M2)给BP表明接受转接。随后，RC1和RC2之间会有类似于通话建立过程的信令交互INVITE(M3)，100 Trying(M4)，180Ringing(M7)、200 OK(M10)，RC1会通过NOTIFY将转接状态告知BP，最后RC1回复ACK(M13)给RC2建立通话，同时其与BP的通话就断开了。

(4)呼叫保持／恢复

呼叫保持并没有专门的信令，而是将INVITE信令体SDP中的Connection Information(c)参数设为空(即(IPv4)0.0.0.0)来实现的。远端客户机回复200 OK接受保持，如图10所示。同理，呼叫恢复就是将c参数恢复原值，过程与呼叫保持相同。

(5)电话会议

会议功能是在Blackfin 533上实现的，将不同Port的语音数据混合并发送给目的Port，即可让参与者听到多方的声音。

通过测试，各项功能均已实现，而且通话质量良好。

结 语

本文提出并实现了一种基于Blackfin的SIP网络电话解决方案，介绍了整个系统的构成，包括硬件方案和软件方案，并展示了相关的功能。由于采用层次化设计，并提供了丰富的API接口，因此该方案有较强的可拓展性.