基于Blackfin 533的SIP网络电话

引 言

    近年来，Internet得到了飞速发展与普及，而作为其核心技术的IP协议体系在数据网络架构中的统治地位已得到了广泛认同。另外，随着IP技术框架中汇聚网络研究的发展和VoIP(Voice over Internet Protoc01)技术的提出，数据网络通信已经融入传统的话音业务领域，而且VoIP与生俱来的Internet血统使得其在应用方面有着很强的拓展性，因此，VoIP技术和应用的研究成为了当今的热点问题。各大芯片厂商相继推出了VoIP方案，比如ADI公司的Blackfin系列等。协议方面的研究也取得了丰硕的成果，其中SIP(Session Initiation Protoc01)协议凭借相对简单的实现模式和极强的扩展性受到了越来越多
的关注。ADI公司推出的Blackfin处理器是一类专为满足当今嵌入式音频、视频和通信应用的计算要求和功耗约束条件而设计的新型16／32位嵌入式处理器。该处理器基于ADI和Intel公司联合开发的微信号架构(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所示。

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

    软件方面采用分层设计：

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

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

2 硬件方案
    Blackfin 533为核心处理器芯片。外围辅以ADl836实现语音信号的采集和播放；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 Transpor实体被创建出来(媒体流传输使用的是UDP)。该实体中的地址和端口号信息将被添加到本地SDP结构中，用于Invite会话的协
商过程。当用于本次通话的Offer或Answer会话确立之后(即协商已经完成，双方确定了通信的类型)，根据通话双方的SDP信息，就创建出来一个Media Session Info结构。接着SIP信令交互线程会创建一个Media Session(多媒体会话)结构。在这一过程中，按照在Me dia 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注册到一个在初始化过程中创建的I0Queue上。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 Device 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服务器发送了一条INⅥTE消息(M1)，要求与远端客户机(RC)进行对话。SER马上回复一条100 Trying消息(M2)表示正在尝试连接。然后SER将INⅥTE消息加入相关的Record—Route和Via头部域以后成为消息M3，发送给RC。RC回复一个100 Trying消息(M4)给SER，然后再发送180Ringing(M5)给SER，表示正在响铃中。SER将M5中它的Via和Record—R0ute头部域去掉以后，成为消息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(RCl)的通话转接到远端客户机2(RC2)时，BF发送REFER(M1)给RCl，该信息中Refer—To字头标明了RC2的URL，之后RCl回复202 Accepted(M2)给BP表明接受转接。随后，RCl和RC2之间会有类似于通话建立过程的信令交互INVITE(M3)，100 Trying(M4)，180Ringing(M7)、200 OK(M10)，RCl会通过NOTIFY将转接状态告知BP，最后RCl回复ACK(M13)给RC2建立通话，同时其与BP的通话就断开了。

    (4)呼叫保持／恢复

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

    (5)电话会议

    会议功能是在Blackfin 533上实现的，将不同Port的语音数据混合并发送给目的Port，即可让参与者听到多方的声音。通过测试，各项功能均已实现，而且通话质量良好。

结 语

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