引 言
近年来，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的硬件特点，采用μC linux 作为操作系统；同时面向控制的操作系统、图形化的人机界面以及复杂的网络协议栈，增加了对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逻辑上的实体；
本文关键字：网络电话 DSP/FPGA技术，单片机-工控设备 - DSP/FPGA技术
