标准SIP终端概要设计.doc

标准SIP终端概要设计 标准SIP终端是完全按照SIP协议和RTP协议进行呼叫和会话的终端,是网关对讲的软件的最小集合。 SIP终端描述: 按照功能需求,标准SIP终端需完成以下功能: SIP协议的INVITE请求和Register请求的发送和接收,其中：按照标准SIP协议,一个SIP终端向另一个SIP终端发出INVITE请求,其过程如下: UAC发出INVITE请求 UAS得到INVITE请求后,开始振铃(Ringing),发出Ringing回应. UAC得到Ringing回应后,等待. UAS接听后,发送OK回应 UAC接到OK回应后,发送ACK请求,INVITE过程结束. UAS接到ACK请求后,INVITE过程结束. 按照标准SIP协议,一个SIP终端向注册服务器发出REGISTER请求,过程如下: UAC发出REGISTER请求 UAS得到REGISTER请求后,开始校验注册内容,如成功,发送200(OK)回应,否则,发送3456xx(失败)回应. 音频的获取,传输以及播放,其中： 从音频设备(如dsp设备)中获取音频数据 将音频数据按照某种音频压缩方式(如gsm编码)编码 压缩后的数据打包成RTP包,从网络中发送出去 从网络中接收音频的RTP包,整合 将整合后的数据按照某种音频压缩方式(如gsm编码)解码 将解码后的数据交给音频设备(如dsp设备)播放 视频的获取,传输以及播放,其中： 从视频设备(如摄像头)中获取视频频数据 将视频数据按照mpeg4编码方式进行编码 编码后的数据打包成RTP包,从网络中发送出去 从网络中接收视频的RTP包,整合 将整合后的数据按照mpeg4编码方式进行解码 将解码后的数据交给framebuffer播放 设计思路: 根据上面的描述,我们将整个SIP终端分成以下几个模块： SIP协议部分 SIP协议部分基于OSIP协议栈和EXOSIP库,INVITE请求和REGISTER请求的发送和接收通过调用Exosip的API来完成.注册服务器通过操作数据库来完成注册 音频读取和播放 音频的读取播放基于对dsp设备的操作完成 音频数据的编解码 音频的编解码基于某一音频编解码库(gsmlib,g.721,g.726等) 视频的读取和编码 视频的读取和编码基于开发板提供的mpeg4编码库,由于开发板提供的mpeg4编码库将视频的读取和编码合为一体,所以,特别地,我们将视频的读取和编码合为一体。 视频的解码 视频的解码基于开发板提供的mpeg4解码库。 视频的播放 视频的播放通过访问开发板的pp设备来完成。 音视频数据的网络传输 音视频的网络传输基于ORTP库 SIP协议的实现 SIP协议的实现基于osip协议栈和exosip库，主要完成INVITE请求和Register请求。由此定义一个GwSip类，类结构如下： GwSip类结构 音频数据的读取、传输、播放 音频数据经过读取播放模块，编码和解码模块，RTP打包和收包模块完成音频的会话，各个模块之间用FIFO连接起来，这样可以降低各个模块之间的耦合度： 由于这3个模块之间由FIFO相连，这里定义一个GwFifo类来实现这个FIFO。类定义如下： Fifo设计为一个环形的buffer，这样减少大量的数据复制时间，同时可以减少内存分配和释放的次数。 FIFO初始化后，状态如下图： Fifo初始状态 开始读写Fifo后，当向Fifo中写入数据后，状态如下图： 开始读写Fifo后一段时间内 当Fifo结尾剩余的可写空间小于用户需申请的空间（writeblocksize）时，将重新从初始状态的unusedptr处开始写入数据，但是此时需检查起始的可写空间是否大于用户申请空间。状态如下图： 结尾的可写空间小于用户申请的空间,将重新从初始状态写入数据 unusedptr指向初始状态的unusedptr处 当Fifo结尾的剩余可读空间小于用户需读取的数据大小(readblocksize)时，需要将结尾的可读数据copy到buffer的reserved空间，usedptr指向copy的数据的起始处，继续读取数据。状态如下： 结尾的可读数据小于用户需读入的数据 将结尾的可读数据copy到reserved空间，开始读取 由于各个模块都要访问到FIFO,这里定义一个GwFilter类，它是这几个模块的基类，实现Fifo的连接、访问功能。GwFilter定义如下： 音频的读取和播放模块类 GwSoundCard类，该类继承自GwFilter,采用线程方式进行音频的读取和播放，类定义如下： 针对不同类型的声卡驱动，我们需定义不同的子类，来完成相应的功能，这里，定义