CN101567853B - 音频媒体发包控制装置、方法及音频媒体服务器 - Google Patents
音频媒体发包控制装置、方法及音频媒体服务器 Download PDFInfo
- Publication number
- CN101567853B CN101567853B CN2009101429225A CN200910142922A CN101567853B CN 101567853 B CN101567853 B CN 101567853B CN 2009101429225 A CN2009101429225 A CN 2009101429225A CN 200910142922 A CN200910142922 A CN 200910142922A CN 101567853 B CN101567853 B CN 101567853B
- Authority
- CN
- China
- Prior art keywords
- media
- sending
- time
- pointer array
- message
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
- 238000000034 method Methods 0.000 title claims abstract description 48
- 238000012856 packing Methods 0.000 claims abstract description 25
- 230000005540 biological transmission Effects 0.000 claims abstract description 22
- 230000003111 delayed effect Effects 0.000 claims abstract 3
- 238000012545 processing Methods 0.000 claims description 97
- 230000006870 function Effects 0.000 claims description 25
- 230000008569 process Effects 0.000 claims description 21
- 230000011664 signaling Effects 0.000 claims description 19
- 238000005516 engineering process Methods 0.000 claims description 18
- 230000003993 interaction Effects 0.000 claims description 5
- 238000001914 filtration Methods 0.000 claims description 3
- 230000002194 synthesizing effect Effects 0.000 claims description 3
- 239000003795 chemical substances by application Substances 0.000 description 7
- 238000010586 diagram Methods 0.000 description 7
- 238000006243 chemical reaction Methods 0.000 description 6
- 238000004806 packaging method and process Methods 0.000 description 5
- 238000004458 analytical method Methods 0.000 description 4
- 238000010276 construction Methods 0.000 description 4
- 238000004422 calculation algorithm Methods 0.000 description 3
- 238000004891 communication Methods 0.000 description 3
- 238000002156 mixing Methods 0.000 description 3
- 230000003044 adaptive effect Effects 0.000 description 2
- 238000013459 approach Methods 0.000 description 2
- 238000001514 detection method Methods 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 230000002452 interceptive effect Effects 0.000 description 2
- 230000004044 response Effects 0.000 description 2
- 238000005070 sampling Methods 0.000 description 2
- 239000011800 void material Substances 0.000 description 2
- 101100438245 Solanum tuberosum PCM8 gene Proteins 0.000 description 1
- 230000003213 activating effect Effects 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 239000000969 carrier Substances 0.000 description 1
- 230000006835 compression Effects 0.000 description 1
- 238000007906 compression Methods 0.000 description 1
- 238000004883 computer application Methods 0.000 description 1
- 230000007812 deficiency Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 230000009977 dual effect Effects 0.000 description 1
- 238000011156 evaluation Methods 0.000 description 1
- 238000000605 extraction Methods 0.000 description 1
- 238000005243 fluidization Methods 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 238000002955 isolation Methods 0.000 description 1
- 238000011068 loading method Methods 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 238000003672 processing method Methods 0.000 description 1
- 230000009131 signaling function Effects 0.000 description 1
- 238000004088 simulation Methods 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 238000013519 translation Methods 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明提供一种音频媒体发包控制装置，该装置包括预计发包控制模块及时间管理发包控制模块，其中，所述预计发包控制模块，用于确定要发送的媒体报文的预计发送时间，还用于将所述媒体报文挂接到与所述预计发送时间对应的指针数组元素所指的链表上；所述时间管理发包控制模块，用于根据指针数组元素索引依次读取指针数组元素所指的链表上的媒体报文，并在所述预计发送时间将所述媒体报文发送出去；若该指针数组元素所指的链表上没有媒体报文，则延时到所述指针数组元素的预计发送时间。本发明音频媒体发包控制装置、方法及音频媒体服务器，可以提高媒体报文打包间隔精度。
Description
技术领域
本发明属于计算机应用领域的网络通信技术，具体涉及一种基于Linux/vxworks的音频媒体发包控制装置、方法及音频媒体服务器。
背景技术
媒体服务器是下一代网络(NGN，Next Generation Network))中的重要设备，其在NGN网络中的位置如图1所示。现有音频媒体服务器中媒体处理***涉及到对大量数据的解析、流化、打包间隔的精确控制等关键技术。针对这些关键技术，目前业内媒体服务器媒体处理***主要用两种方式：硬件方式-专用DSP(Digital Singnal Processing，数字信号处理)和软件方式-HMP(Host Media Processing，主机媒体处理)技术。但是它们的缺陷在于：硬件方式成本高、软件方式虽然成本降低了，但是容量却太小，一旦增加容量又造成流化和打包间隔精确控制性能降低。专用DSP技术是通过专有芯片中的特定算法来进行媒体数据的处理，一般来说专有DSP芯片媒体处理能力强，通道密度也即容量大，每个通道的价格一定的话，通道密度越高成本也就越高；而HMP技术是未来媒体服务器的发展方向，但相对于专有DSP，主机媒体处理能力一般，因此在大容量的情况下，打包精度控制会显著下降，大容量和打包精度成为其发展的瓶颈。
发明内容
本发明要解决的技术问题是提供一种音频媒体发包控制装置、方法及音频媒体服务器，提高媒体报文打包间隔精度。
为解决上述技术问题，本发明提供一种音频媒体发包控制装置，该装置包括预计发包控制模块及时间管理发包控制模块，其中，
所述预计发包控制模块，用于确定要发送的媒体报文的预计发送时间，还用于将所述媒体报文挂接到与所述预计发送时间对应的指针数组元素所指的链表上；
所述时间管理发包控制模块，用于根据指针数组元素索引依次读取指针数组元素所指的链表上的媒体报文，并在所述预计发送时间将所述媒体报文发送出去；若该指针数组元素所指的链表上没有媒体报文，则延时到所述指针数组元素的预计发送时间。
进一步地，
所述媒体报文的预计发送时间是这样确定的：读取所述时间管理发包控制模块正在处理的当前指针数组元素的预计发送时间；在读取的预计发送时间的基础上增加一定的时间余量作为所述媒体报文的预计发送时间，以保证所述时间管理发包模块浏览到挂接在对应的指针数组元素的所述媒体报文。
进一步地，
所述指针数组元素的索引及所述指针数组元素指向的链表上的媒体报文的预计发送时间具有依次对应关系，相邻指针数组元素的预计发送时间间隔是固定的。
所述预计发包控制模块及时间管理发包控制模块采用多线程处理技术实现。
为解决上述技术问题，本发明还提供了一种媒体发包控制方法，该方法包括：
挂接步骤，指确定要发送的媒体报文的预计发送时间并将所述媒体报文挂接到与所述预计发送时间对应的指针数组元素所指的链表上；
发送步骤，指根据指针数组元素索引依次读取指针数组元素所指的链表上的媒体报文并在所述预计发送时间将所述媒体报文发送出去；若该指针数组元素所指的链表上没有媒体报文，则延时到该元素预计发送时间。
进一步地，
所述挂接步骤由多个预计发包线程实现，每个线程浏览其负责的通道，当发现某个通道要求发送媒体报文时，执行以下步骤：
A：读取时间管理发包控制线程中当前正在处理的当前指针数组元素的索引index和预计发送时间foresndtime；
B：确定要发送的第一个媒体报文的挂接索引nextpkt_tindex及预计发送时间nextpkt_foresndtime，其中，
nextpkt_tindex＝(index+n)％指针数组的元素个数；
nextpkt_foresndtime＝foresndtime+n*每个指针数组索引代表的时间间隔；其中，n为预先设定的索引余量，以保证所述时间管理发包控制线程浏览到挂接在对应的指针数组元素的所述媒体报文；
C：确定后续媒体报文的挂接索引nextpkt_tindex及预计发送时间nextpkt_foresndtime，直到所有媒体报文处理完毕，其中：
nextpkt_index＝nextpkt_index+(打包间隔/每个索引代表的时间间隔)％(指针数组的元素个数)，其中，所述打包间隔是每个索引代表的时间间隔的整数倍；
nextpkt_foresndtime＝nextpkt_foresndtime+(打包间隔)。
所述发送步骤由多个时间管理发包控制线程实现，各时间管理发包控制线程循环执行以下步骤：
A：浏览指针数组当前索引的链表上是否有要发送的媒体报文，若有，则读取所述媒体报文，并把所述媒体报文的地址和载荷信息以及这批媒体报文的预计发送时间参数传到sendmsg函数；sendmsg函数在预计发送时间把该批媒体报文批量发送出去，然后在预计发送时间返回；
若在当前索引的链表上没有要发送媒体报文，所述时间管理发包控制线程调用延时函数DelayTime延时到当前索引链表的预计发送时间；
B：更新当前索引index以及当前索引的链表上媒体报文的预计发送时间，其中，
当前索引：Index＝(Index+1)％(指针数组最大元素个数)；
当前索引对应的预计发送时间：foresndtime+＝每个索引代表的时间间隔(10ms)。
进一步地，
所述挂机步骤中，每挂接一个媒体报文，对应链表结构的媒体报文计数器加1；所述时间管理控制线程根据所述媒体报文计数器确定当前索引的链表上是否有要发送的媒体报文。
为解决上述技术问题，本发明还提供一种音频媒体服务器，所述音频媒体服务器包括该音频媒体发包控制装置，该装置包括预计发包控制模块及时间管理发包控制模块，其中，
所述预计发包控制模块，用于确定要发送的媒体报文的预计发送时间，还用于将所述媒体报文挂接到与所述预计发送时间对应的指针数组元素所指的链表上；
所述时间管理发包控制模块，用于根据指针数组元素索引依次读取指针数组元素所指的链表上的媒体报文并在所述预计发送时间将所述媒体报文发送出去；若该指针数组元素所指的链表上没有媒体报文，则延时到该元素预计发送时间。
进一步地，
所述媒体报文的预计发送时间是这样确定的：读取所述时间管理发包控制模块正在处理的指针数组元素的预计发送时间；在读取的预计发送时间的基础上增加一定的时间余量作为所述媒体报文的预计发送时间，以保证所述时间管理发包模块浏览到挂接在对应的指针数组元素的所述媒体报文。
进一步地，所述音频媒体服务器还包括信令转发单元、主控单元及媒体存储转发单元，其中，
所述信令转发单元：用于实现服务器内部与外部信令的统一转发；
所述主控单元：用于接收并解析所述信令转发单元转发的控制信令生成相应的控制消息来***体存储转发单元；
所述媒体存储转发单元，具有对外网口，用于根据所述主控单元下发的控制消息实现录音及语音播放功能，其中，由所述音频媒体发包控制装置实现媒体报文的发包控制。
进一步地，所述媒体存储转发单元实现的各种操作采用多线程处理技术实现。
进一步地，所述音频媒体服务器还包括媒体处理单元，所述媒体处理单元包括呼叫代理模块、收发号模块及会议处理模块，其中，
呼叫代理模块，用于实现主控单元和媒体处理单元之间控制消息的交互，若控制消息为收发号消息则通知收发号模块处理，若控制消息为转码或者会议消息则通知会议处理模块处理；
收发号模块，用于进行收号器资源设置，以及对媒体流中的有效号码进行有效性识别；还用于根据主控单元的控制消息产生号码；
会议处理模块，用于处理来自各个参与者的媒体流，把不同参与者的输入语音帧合成在一起作为混合语音帧，且输出给每个参与者的语音帧是把混和语音帧滤掉该参与者的输入语音帧；
所述主控单元，还用于生成对所述媒体处理单元的控制消息；
所述媒体存储转发单元还用于将含有多音双频DTMF号码的媒体报文的目的地址转换成收发号器通道对应的地址。
相较于现有技术，本发明发包控制装置和方法利用发包线程管理带时间信息的指针数组的方法实现对媒体报文指针数组挂载索引和预计发送时间的准确有效的控制，能高效的把该索引位置的所有媒体报文在预定发送时刻批量的发送出去，实现了对打包间隔的精确控制，能够提供高精度Qos(Quality of Service)性能，另外采用多线程处理技术，具有大容量的特点。
本发明音频媒体服务器，基于HMP实现，成本低，不仅实现对打包间隔的精确控制，容量可与专用DSP媲美，可以提供基本和增强业务中的媒体处理功能，包括业务音提供、会议、交互式应答、通知和高级语音业务等功能。
附图说明
图1是NGN网络中媒体服务器的位置的示意图。
图2是本发明媒体服务器各个功能模块的示意图。
图3是音源文件结构的示意图。
图4是音源文件解析流程图。
图5是本发明采用的多线程处理技术示意框图。
图6是本发明音频媒体发包控制装置的模块结构示意图。
图7是本发明音频媒体发包控制方法的示意图。
图8是本发明预计发包控制模块的处理流程图。
图9是本发明时间管理发包控制模块处理流程图。
图10是DTMF号码收发号流程图。
图11是会议电话流程图。
具体实施方式
如图2所示，本发明音频媒体服务器包括信令转发单元、与信令转发单元连接的主控单元、控制/媒体交换单元、媒体存储转发单元、媒体处理单元，其中主控单元、媒体存储转发单元及媒体处理单元均通过控制/媒体交换单元相互交互控制流或媒体流，媒体存储转发单元、媒体处理单元是本发明媒体处理技术实现的载体。
信令转发单元：主要实现***内部网络与外部网络的隔离，设备的控制信令SIP(Session Initiation Protocol，会话初始化协议)/H248/MGCP(MediaGateway Control Protocol，媒体网关控制协议)统一通过信令转发单元转发，实现设备对外单一的IP(Internet Protocol)地址呈现；
主控单元：用于接收并解析控制信令生成相应的控制消息来***体存储转发单元和媒体处理单元对放音、录音、收发号、会议、转码进行相应通道处理；
控制信令是按国际标准格式的消息，而控制消息是把控制信令中的各个字段解释翻译后，组成的适合于***内部的传递格式的消息。
控制/媒体交换单元：用于完成服务器内部控制消息交换/媒体数据包交换，其实现交换机的功能，是其他模块之间通信的桥梁，在此不再赘述。
媒体存储转发单元：完成海量的多媒体数据存储，包括实现语音播放功能的语音库、实现录音功能时对用户录音的存储。媒体存储转发单元设置有对外网口，当媒体不需要额外转换处理时，直接通过单元上的对外网口收发。
通过对外网口发送的媒体报文是流化后的媒体报文，该报文是符合国际标准格式的报文。
在实现录音业务时，通过对外网口接收媒体流如果终端(比如固定电话终端)想录音，并且在录制的过程中，没有按任何DTMF号码(0-9、*、#)，那么此时媒体流中就不会含有DTMF号码；如果录制完毕时(比如：以#号表示录音完毕的结束键)，此时按#，那么此时接收的媒体流中就含有DTMF号码(#号)，探测到#号，并上报给主控单元，主控单元就会下发控制消息来关闭该通道停止录音。
媒体存储转发单元包括内部call代理模块、录音媒体处理模块、放音媒体处理模块、发包控制模块、收包控制模块及存储模块，其中，
内部call代理(呼叫代理)模块，用于实现与主控模块之间控制消息的交互，这些消息是通过控制/媒体交换单元的控制平面实现的。若分析接收的控制消息为录音则通知录音处理模块；若为放音，则通知放音处理模块。
录音媒体处理模块，用于从把收包控制模块接收来的媒体报文排序后，提取其有效载荷存储为指定的文件格式(WAV/AMR)。
放音媒体处理模块，用于根据放音控制消息中的参数从存储模块找到音源文件，并对音源文件进行解析、读取音源的有效数据、打包流化为适合于网络传输的媒体报文；若根据音源数据流化后的媒体报文编码格式与终端需要的编码格式不一致，需要发送到媒体处理单元进行处理；
发包控制模块，用于通过内外网口的发送媒体报文，具体地，该发包控制模块即发包控制装置，是本发明的核心，具体将在下文中进行详细说明。
收包控制模块，用于通过内外网口的接收媒体报文，如果从外网口接收到的媒体报文与需要的存储的音源文件格式(WAV/AMR)不一致就需要转发到媒体处理单元，由媒体处理单元进行转码后发送到收包控制模块的内网口，然后给录音媒体处理模块处理，还用于将含有DTMF号码的媒体报文的目的地址转换成收发号器通道对应的地址。
存储模块，用于存储音源文件。
媒体处理单元：完成语音编解码方式转换、实现DTMF(Dual ToneMulti-Frequency，双音多频)收发号以及会议混音功能。
媒体处理单元有以太网口和TDM(Time Division Multiplex andMultiplexer，时分复用)接口，来实现IP用户和PSTN(Public SwitchedTelephone Network，公用交换电话网)用户的各自需要。
媒体处理单元包括call代理模块、收发号模块及会议处理模块，其中，
call代理模块，用于实现主控单元和媒体处理单元之间控制消息的交互，若控制消息为收发号消息则通知收发号模块处理，若控制消息为转码或者会议消息则通知会议处理模块处理
收发号模块，用于进行收号器资源设置，以及对媒体流中的有效号码进行有效性识别；还用于根据主控单元的控制消息产生号码；
会议处理模块，用于处理来自各个参与者的媒体流，把不同参与者的输入语音帧合成在一起作为混合语音帧；输出给每个参与者的语音帧是把混和语音帧滤掉该参与者的输入语音帧，这样就避免该用户听到自己的回声。
本发明音频媒体服务器在HMP方式改进的基础上提供低成本和大容量来克服上述DSP和HMP的不足是，一种基于Linux/vxworks操作***的适用于各种网络用户的媒体处理技术实现方案，本发明媒体服务器在应用服务器的控制下，提供各种业务所需的媒体处理功能，包括：放音，录音，DTMF收号，会议、转码等媒体处理技术。本发明媒体处理技术的要点如下：
一、对于音源文件格式的解析和构造：
由于不同类型的文件对音频采样数据的组织形式不同，所以需要根据相应的格式进行分析。一般来说，文件包含对数据的描述部分和数据部分。目前，对音源文件的处理支持WAV(Wave Form，波形)和AMR(AdaptiveMulti-Rate，自适应多速率)等文件类型，如图3所示，当然根据要求也可以支持其他的音源类型，完全由软件控制。
WAV文件头作为多媒体中使用的声波文件格式之一，它是以RIFF(Resource Interchange File Format，资源交换文件格式)格式为标准的。AMR全称Adaptive Multi-Rate，自适应多速率编码，主要用于移动设备的音频，压缩比比较大。
WAV文件和AMR文件文件的解析流程框图如图4，构造流程与此类似。其中，
对WAV文件的解析过程：
读取WAV文件的文件头；提取文件头信息，包括数据编码方式、频道数、采样频率、每个采样需要的bit数等信息；跳过文件描述信息；从音频数据部分读取数据。
对AMR文件的解析过程：
读取文件的magic number；读取首帧数据；根据帧头计算帧数据的大小；读帧头；判断是否坏帧，若坏帧则读取下一个帧头，否则读取本帧语音数据。
二、语音数据的流化和流化数据的语音构造
流化处理指把读取的音源文件中的数据进行RTP(Real-timeTransportProtocol，实时传送协议)打包处理，构造成可在IP网上传输的符合RFC3550标准的媒体报文。这其中包括构造IP/UDP(UserDatagram Protocol，用户数据报协议，)/RTP头和payload(有效载荷)数据。
若语音数据的编码格式与终端用户所要求的编解码格式相同，则不需要转换处理，直接由媒体存储转发单元的放音处理模块进行流化处理后通过对外网口发送；
若语音数据的编码格式与终端用户所要求的编解码格式(如G.711a/u、G.729、G.723)不一致，则需要进行语音数据转换，流化处理的过程由媒体存储转发单元和媒体处理单元共同完成，两者之间的媒体流交互通过控制/媒体交换单元的媒体平面实现。
可以通过以下两种方式实现流化处理过程：
方式一：媒体存储转发单元的放音处理模块将语音数据还原成PCM8或PCM16的格式，媒体处理单元通过算法将其转为对应的G.711/G.729/G.723的编码数据，最后媒体存储转发单元的放音处理模块基于实时传送协议RTP进行构包处理。
方式二：媒体存储转发单元的放音处理模块将音源文件中的语音数据，比如a/u-law或者AMR帧，直接流化处理成G.711a/u或者RFC3267 payload格式的RTP报文，媒体处理单元的会议处理模块再将RTP处理后数据转码为目的编解码G.729/G.723方式。本发明推荐使用第二种方式。
当然对于WAV文件的流化，需要知道WAV文件中的音源数据编码格式(音源数据编码格式在文件头中)。IP/UDP的源和目的地址信息由主控单元带下来的参数决定，payload数据的长度由主控单元带下来的打包时长信息决定。
对于AMR文件的流化，需要参考rfc3267标准把存储格式变为传输格式的流化数据。这里涉及到不同的payload格式的问题：字节对齐格式和带宽效率格式。需要根据信令中SDP描述选择不同的格式，再进行音源语音帧在payload中的格式变换。
流化数据的语音构造相反：就是把流化数据中的payload变化为音源数据进行存储。在这个过程中需要对接收的RTP数据进行排序和抖动处理，并进行格式转换以便语音数据按正确格式存于相应的文件类型。
三、大容量的多线程处理技术
媒体存储转发单元的各模块实现的各个操作，包括录音处理时文件头信息构造、rtp报文载荷提取、有效语音存储及放音处理时的音源解析、数据读取、流化、打包以及发包，都采用多线程处理技术，即每种操作有多个线程并行处理，从而实现多通道大容量的特点。
操作文件最常用的一个模型是同步阻塞I/O模型。在这个模型中，用户空间的应用程序执行一个***调用，这会导致应用程序阻塞。如图5所示，以读操作为例，本发明利用线程族(也就是起多个线程)来模拟异步读操作；读请求线程决定是否发起读操作，读文件线程读取数据；由多个这样的读请求线程和读文件线程构成读请求线程族和读文件线程族；这样通过并发读文件线程就可以模拟异步读文件操作了，另外图中还显示了进行打包处理的构造RTP包线程族及执行发包处理的发包线程族。写文件的模拟也是类似的。在需要执行文件操作时，在读写请求线程与读写文件线程之间用消息队列的方式在两个线程族之间通信。
一旦某些通道需要发送媒体流，那么对于所读取的语音数据要不停的打包和发包处理。如果全由一个进程或线程来处理，肯定会造成“拥塞”的情况，这就对大容量造成了限制；而多个线程并发处理的运用对这些问题的解决奠定了基础。
四、高精度发包控制技术
媒体服务器中有大量的媒体流从媒体存储转发单元的发包控制模块即发包控制装置的内外网口发送。为了对流化数据(rtp数据)的打包间隔进行精确控制，本发明发包控制装置通过发包线程管理带时间信息的指针数组的方法实现，如图6所示，本发明发包控制装置包括预计发包控制模块及时间管理发包控制模块，其中：
预计发包控制模块用于缓存放音媒体处理模块流化后的媒体报文，确定预计发送时间并挂接到指针数组对应发送时刻的元素所指的链表上。
每个网口都对应一定数量的缓存，用来存储媒体报文；当没有媒体报文要处理时，所有的缓存都在idlelist上，若有媒体报文需要处理，预计发包控制模块就会从空闲链表idlelist上申请缓存用来装载媒体报文，然后把该报文挂接到该网口对应的时间管理发包控制模块管理的指针数组元素上。等时间管理发包控制模块把该数组元素上的报文发送完毕后，又会把这些缓存挂接到该网口的空闲链表idlelist上。
所述媒体报文的预计发送时间是这样确定的：读取所述时间管理发包控制模块正在处理的当前指针数组元素的预计发送时间；在读取的预计发送时间的基础上增加一定的时间余量作为所述媒体报文的预计发送时间，以保证所述时间管理发包模块浏览到挂接在对应的指针数组元素的所述媒体报文。
所述指针数组元素的索引及所述指针数组元素指向的链表上的媒体报文的预计发送时间具有依次对应关系，相邻指针数组元素的预计发送时间间隔是固定的。
时间管理发包控制模块用于根据指针数组元素索引依次读取指针数组元素所指链表上的媒体报文，并在预计发送时间发送出去；如果指针数组元素链表头没有携带任何媒体报文，那么需要延时到该元素预计发送时间。
所述预计发包控制模块及时间管理发包控制模块采用多线程处理技术实现。对应地，如图7所示，本发明媒体发包控制方法包括以下步骤：
步骤701：挂接步骤，指确定要发送的媒体报文的预计发送时间并将所述媒体报文挂接到与所述预计发送时间对应的指针数组元素所指的链表上；
步骤702：发送步骤，指根据指针数组元素索引依次读取指针数组元素所指的链表上的媒体报文并在所述预计发送时间将所述媒体报文发送出去；若该指针数组元素所指的链表上没有媒体报文，则延时到该元素预计发送时间。
以下结合附图对模块功能及步骤进行详细的说明：
预计发包控制模块的流程图如图8所示，当预计发包控制模块的预计发包线程族由调度进程创建起来后进入永远的while循环，在这个while循环中会浏览该线程负责所有的通道，一旦发现某个通道要求发送媒体报文就会进入打包函数中，在打包函数中会查看一下要发送的媒体报文是否第一个，如果是，那么按以下步骤进行：
A、读取时间管理发包控制线程中当前正在处理的指针数组的索引index和预计发送时间foresndtime；为了能够把该第一个媒体报文发送出去，那么第一个媒体报文的索引和预计发送时间必须是index和foresndtime之后的索引和时间，所以需要在index和foresndtime上保留一定的余量(索引余量及时间余量)，以便时间管理发包控制线程会浏览到(时间管理发包控制线程按索引递增浏览的)；目前第一个媒体报文的索引nextpkt_tindex及预计发送时间nextpkt_foresndtime的计算方法为：
nextpkt_tindex＝(index+n)％指针数组的元素个数；
nextpkt_foresndtime＝foresndtime+n*每个指针数组索引代表的时间间隔；
其中，n为预先设定的索引余量(比如n＝5)，以保证所述时间管理发包控制线程浏览到挂接在对应的指针数组元素的所述媒体报文；对应的时间余量即索引余量n与每个指针数组索引代表的时间间隔的乘积。
目前每个指针数组索引代表的时间间隔即相邻指针数组元素的预计发送时间间隔是固定的(如10ms)，索引和预计发送时间其实是依次对应的关系的，第一个媒体报文的发送索引是当前索引往后移n个索引，对应的预计发送时间是当前预计发送时间往后移n个索引对应的时间间隔。索引号找到后会把该媒体报文挂接到指针数组的对应索引的链表上，同时该链表结构中的媒体报文计数器会加1。
B、计算该通道的下一个要发送的媒体报文的索引和预计发送时间，算法如下：
nextpkt_index＝nextpkt_index+(打包间隔/每个索引代表的时间间隔)％(指针数组的元素个数)
nextpkt_foresndtime＝nextpkt_foresndtime+(打包间隔)
这里的打包间隔是每个索引代表的时间间隔的整数倍，最简单的情况就是打包间隔与每个索引代表的时间间隔是相同的。
该通道接下来的发送的第二个媒体报文就利用以上计算的索引号和预计发送时间找到指针数组的对应索引的链表上，同时该链表结构中的媒体报文计数器会加1。
C、后续的媒体报文的所挂接的索引号和预计发送时间都重复B步骤进行，直到媒体报文处理完毕。
根据以上方式确定媒体报文的指针数组元素索引可以保证的媒体报文都会被发送，不会产生丢包的现象。每个指针元素上存放的媒体报文没有量的限制，即使同时有多个通道的媒体报文需要发送，只要根据以上原则确定指针数组元素索引，以上多个通道的媒体报文可以存放在同一指针数组元素索引对应的链表上，从而为媒体报文的批量发送提供了前提条件。
时间管理发包控制模块的流程图如图9，当时间管理发包控制模块的时间管理发包控制线程族由调度进程创建起来后，就会获取当前***时间，并把该时间圆整到秒，作为指针数组第一个索引0链表上携带的媒体报文的预计发送时间T0，当前索引index＝0，然后永远的while循环，在这个while循环中会：
A、浏览指针数组当前索引的链表上是否有要发送的媒体报文(通过媒体报文计数器)，一旦发现当前索引的链表上有要发送媒体报文就会把这些媒体报文取下来，然后把这些媒体报文的地址和载荷信息以及这批媒体报文的预计发送时间参数传到sendmsg函数中，由该函数在预预计发送时间把该批报文批量发送出去，然后在预计发送时间返回；若在当前索引的链表上没有要发送媒体报文，那么会调用延时函数DelayTime延时到该索引链表的预计发送时间。
B、更新当前索引index以及当前索引的链表上媒体报文的预计发送时间。更新方法：
当前索引：
Index＝(Index+1)％(指针数组最大元素个数)
当前索引对应的预计发送时间：
foresndtime+＝每个索引代表的时间间隔(10ms)
C、重复步骤A、B，永远的循环下去
代码实现如下：
void*TimeQueueThread(void*arg)
{
gettimeofday(&tpSndTime，NULL)；
tpSndTime.tv_sec+＝3；
tpSndTime.tv_usec＝0；
tpLastSndTime＝tpSndTime；
wQStartIndex＝0；
PointerArray[wQStartIndex].QForeCastSndTime
＝tpSndTime；
while(1)
{
wQIndex＝wQStartIndex；
wEleNum＝PointerArray[wQIndex].wElememtNum
if(！wEleNum)
{
DelayTime()；
}
Else
{
Sendmsg()；
}
NextTv(&tpLastSndTime，MinPktTime*1000，&tpSndTime)；
tpLastSndTime＝tpSndTime；
wQStartIndex+＝1；
wQStartIndex＝wQStartIndex％QUEUE_MAX；
PointerArray[wQStartIndex].QForeCastSndTime
＝tpSndTime；
}
因为对终端用户来说，打包间隔如果抖动过大那么就会严重影响语音质量，这个打包间隔精确度是Qos的重要指标，直接影响运营商对产品质量的评估。可以说，在文件读取数据和打包能够及时供给的情况下，Qos就完全依赖打包间隔精确度了。
本发明发包控制装置，通过对媒体报文的在指针数组挂载索引和预计发送时间的准确有效的控制，能高效的把该索引位置的所有媒体报文在预定发送时刻批量的发送出去。
五、DTMF收发号功能，支持带内方式和RFC2833方式
DTMF收发号功能是在媒体处理单元的收发号模块上实现的，如图10所示，当媒体处理单元的收发号模块收到主控单元要求打开收发号器收发号码时，首先进行一系列的收号器资源的设置(包括创建收发号通道；设置语音通道参数、DTMF号码的探测方式及激活收号器资源)，然后媒体存储转发单元通过nat(Network Address Translation，网络地址转换)把外网来的含有DTMF号码的媒体流转发到对应的媒体处理单元的收号资源上，由收号资源对该媒体流中的有效号码进行探测和有效性的识别(符合国标GB9038-88)；发送号码，就是根据GB9038-88产生有效的DTMF号码通过媒体存储转发单元的NAT转发到目的终端上去。以上是描述了IP侧的收发号过程，TDM侧的收发号，需要通过E1/T1把PCM(Pulse Code Modulation，脉码调制)流引入到媒体处理单元的收号资源上作同样的流程处理。只不过配置收发号时配置参数不一样。
主控模块是通过控制消息对收发号器的参数进行配置，让收发号器处于工作状态，当想收号的，媒体流是通过媒体存储转发单元的nat转发进来的，由于外网设备只能看到媒体存储转发单元的外网口，其媒体报文的目的地址也是外网口的地址(ip+port)，因此需要媒体存储转发单元把该媒体报文的目的地址在外网口替换成收发号器通道对应的地址，然后发送到收发号器通道上，而外网口的地址与收发号器通道对应的地址的映射关系就是在nat表保存着的；当想发送号码时需要根据主控发号消息的指示产生号码。
六、支持3方及多方会议功能，最大可支持64方混音
会议/转码都是在媒体处理单元的会议处理模块上实现的；会议是允许多个用户参与到一个会议中，每个用户可以听到其他用户的谈话。会议的参与者可以是TDM用户也可以是IP用户。会议/转码中有关键的处理方法，该方法能够把不同参与者的输入语音帧合成在一起作为混合语音帧；输出给每个参与者的语音帧是把混和语音帧滤掉该参与者的输入语音帧，这样就避免该用户听到自己的回声。每个参与者可以是不同的编解码；转码只是会议的一种特殊形式。
会议的参与者可以设置为“哑音”状态，此时混音器会把该参与者作为静音处理，但是该参与者可以听到其他参与者的声音；会议的参与者可以设置为“保持”状态，此时混音器把该参与者作为静音处理，并且该参与者也听不到其他参与者的声音；会议的参与者可以设置为“通告保持”状态，此时混音器把该参与者作为静音处理，该参与者可听到源参与者的声音；会议的参与者可以设置为“源参与者”状态，此时混音器把该参与者的输入输到其他“通告保持”的参与者，使其他“通告保持”的参与者都能够听到“源参与者”的声音；“源参与者”典型的用来播放音乐、新闻、以及通告等等。
创建会议的实现流程如图11，当会议处理模块接收到主控单元发送的创建会议消息时，若会议ID已经存在则上报主控单元，否则创建会议ID及参与者ID，并设置参与者参数、使能参与者对应的通道，会议进行中执行混合语音帧、过滤参与者自身的语音帧的处理过程；当收到参与者加入会议的消息时，同样执行创建参与者ID及设置参与者参数、使能参与者对应的通道的过程；若在会议进行中收到主控单元下发的撤销会议参与者的消息，则使会议参与者对应的通道失效并撤销对应参与者的ID，当参与者只剩下一个时，撤销会议ID。
本发明发包控制装置和方法，利用发包线程管理带时间信息的指针数组的方法实现对媒体报文指针数组挂载索引和预计发送时间的准确有效的控制，能高效的把该索引位置的所有媒体报文在预定发送时刻批量的发送出去，实现了对打包间隔的精确控制，能够提供高精度Qos(Quality of Service)性能，另外采用多线程处理技术，具有大容量的特点。
本发明音频媒体服务器，基于HMP实现，成本低，不仅实现对打包间隔的精确控制，容量可与专用DSP媲美，可以提供基本和增强业务中的媒体处理功能，包括业务音提供、会议、交互式应答、通知和高级语音业务等功能。
Claims (13)
1.一种音频媒体发包控制装置，其特征在于：该装置包括预计发包控制模块及时间管理发包控制模块，其中，
所述预计发包控制模块，用于确定要发送的媒体报文的预计发送时间，还用于将所述媒体报文挂接到与所述预计发送时间对应的指针数组元素所指的链表上；
所述时间管理发包控制模块，用于根据指针数组元素索引依次读取指针数组元素所指的链表上的媒体报文，并在所述预计发送时间将所述媒体报文发送出去；若该指针数组元素所指的链表上没有媒体报文，则延时到所述指针数组元素的预计发送时间。
2.如权利要求1所述的装置，其特征在于：
所述媒体报文的预计发送时间是这样确定的：读取所述时间管理发包控制模块正在处理的当前指针数组元素的预计发送时间；在读取的预计发送时间的基础上增加一定的时间余量作为所述媒体报文的预计发送时间，以保证所述时间管理发包控制模块浏览到挂接在对应的指针数组元素的所述媒体报文。
3.如权利要求1或2所述的装置，其特征在于：所述指针数组元素的索引及所述指针数组元素指向的链表上的媒体报文的预计发送时间具有依次对应关系，相邻指针数组元素的预计发送时间间隔是固定的。
4.如权利要求1或2所述的装置，其特征在于：所述预计发包控制模块及时间管理发包控制模块采用多线程处理技术实现。
5.一种媒体发包控制方法，其特征在于，该方法包括：
挂接步骤，指确定要发送的媒体报文的预计发送时间并将所述媒体报文挂接到与所述预计发送时间对应的指针数组元素所指的链表上；
发送步骤，指根据指针数组元素索引依次读取指针数组元素所指的链表上的媒体报文并在所述预计发送时间将所述媒体报文发送出去；若该指针数组元素所指的链表上没有媒体报文，则延时到该元素的预计发送时间。
6.如权利要求5所述的方法，其特征在于：所述挂接步骤由多个预计发包线程实现，每个线程浏览其负责的通道，当发现某个通道要求发送媒体报文时，执行以下步骤：
A：读取时间管理发包控制线程中当前正在处理的当前指针数组元素的索引index和预计发送时间foresndtime；
B：确定要发送的第一个媒体报文的挂接索引nextpkt_tindex及预计发送时间nextpkt_foresndtime，其中，
nextpkt_tindex＝(index+n)％指针数组的元素个数；
nextpkt_foresndtime＝foresndtime+n*每个指针数组索引代表的时间间隔；
其中，n为预先设定的索引余量，以保证所述时间管理发包控制线程浏览到挂接在对应的指针数组元素的所述媒体报文；
C：确定后续媒体报文的挂接索引nextpkt_tindex及预计发送时间nextpkt_foresndtime，直到所有媒体报文处理完毕，其中：
nextpkt_tindex＝nextpkt_tindex+(打包间隔/每个索引代表的时间间隔)％(指针数组的元素个数)，其中，所述打包间隔是每个索引代表的时间间隔的整数倍；
nextpkt_foresndtime＝nextpkt_foresndtime+(打包间隔)。
7.如权利要求5所述的方法，其特征在于：所述发送步骤由多个时间管理发包控制线程实现，各时间管理发包控制线程循环执行以下步骤：
A：浏览指针数组当前索引的链表上是否有要发送的媒体报文，若有，则读取所述媒体报文，并把所述媒体报文的地址和载荷信息以及这批媒体报文的预计发送时间参数传到sendmsg函数；sendmsg函数在预计发送时间把该批媒体报文批量发送出去，然后在预计发送时间返回；
若在当前索引的链表上没有要发送媒体报文，所述时间管理发包控制线程调用延时函数DelayTime延时到当前索引链表的预计发送时间；
B：更新当前索引index以及当前索引的链表上媒体报文的预计发送时间，其中，
当前索引：index＝(index+1)％(指针数组最大元素个数)；
当前索引对应的预计发送时间：foresndtime+＝每个索引代表的时间间隔。
8.如权利要求6或7所述的方法，其特征在于：所述挂接步骤中，每挂接一个媒体报文，对应链表结构的媒体报文计数器加1；所述时间管理发包控制线程根据所述媒体报文计数器确定当前索引的链表上是否有要发送的媒体报文。
9.一种音频媒体服务器，其特征在于，所述音频媒体服务器包括音频媒体发包控制装置，该装置包括预计发包控制模块及时间管理发包控制模块，其中，
所述预计发包控制模块，用于确定要发送的媒体报文的预计发送时间，还用于将所述媒体报文挂接到与所述预计发送时间对应的指针数组元素所指的链表上；
所述时间管理发包控制模块，用于根据指针数组元素索引依次读取指针数组元素所指的链表上的媒体报文并在所述预计发送时间将所述媒体报文发送出去；若该指针数组元素所指的链表上没有媒体报文，则延时到该元素的预计发送时间。
10.如权利要求9所述的音频媒体服务器，其特征在于：
所述媒体报文的预计发送时间是这样确定的：读取所述时间管理发包控制模块正在处理的指针数组元素的预计发送时间；在读取的预计发送时间的基础上增加一定的时间余量作为所述媒体报文的预计发送时间，以保证所述时间管理发包控制模块浏览到挂接在对应的指针数组元素的所述媒体报文。
11.如权利要求9或10所述的音频媒体服务器，其特征在于：所述音频媒体服务器还包括信令转发单元、主控单元及媒体存储转发单元，其中，
所述信令转发单元：用于实现服务器内部与外部信令的统一转发；
所述主控单元：用于接收并解析所述信令转发单元转发的控制信令生成相应的控制消息来***体存储转发单元；
所述媒体存储转发单元，具有对外网口，用于根据所述主控单元下发的控制消息实现录音及语音播放功能，其中，由所述音频媒体发包控制装置实现媒体报文的发包控制。
12.如权利要求11所述的音频媒体服务器，其特征在于：所述媒体存储转发单元实现的各种操作采用多线程处理技术实现。
13.如权利要求11所述的音频媒体服务器，其特征在于：所述音频媒体服务器还包括媒体处理单元，所述媒体处理单元包括呼叫代理模块、收发号模块及会议处理模块，其中，
呼叫代理模块，用于实现主控单元和媒体处理单元之间控制消息的交互，若控制消息为收发号消息则通知收发号模块处理，若控制消息为转码或者会议消息则通知会议处理模块处理；
收发号模块，用于进行收号器资源设置，以及对媒体流中的有效号码进行有效性识别；还用于根据主控单元的控制消息产生号码；
会议处理模块，用于处理来自各个参与者的媒体流，把不同参与者的输入语音帧合成在一起作为混合语音帧，且输出给每个参与者的语音帧是把混和语音帧滤掉该参与者的输入语音帧；
所述主控单元，还用于生成对所述媒体处理单元的控制消息；
所述媒体存储转发单元还用于将含有双音多频DTMF号码的媒体报文的目的地址转换成收发号器通道对应的地址。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN2009101429225A CN101567853B (zh) | 2009-05-13 | 2009-05-13 | 音频媒体发包控制装置、方法及音频媒体服务器 |
| PCT/CN2010/072616 WO2010130193A1 (zh) | 2009-05-13 | 2010-05-11 | 音频媒体发包控制装置、方法及音频媒体服务器 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN2009101429225A CN101567853B (zh) | 2009-05-13 | 2009-05-13 | 音频媒体发包控制装置、方法及音频媒体服务器 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN101567853A CN101567853A (zh) | 2009-10-28 |
| CN101567853B true CN101567853B (zh) | 2011-08-10 |
Family
ID=41283809
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN2009101429225A Expired - Fee Related CN101567853B (zh) | 2009-05-13 | 2009-05-13 | 音频媒体发包控制装置、方法及音频媒体服务器 |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN101567853B (zh) |
| WO (1) | WO2010130193A1 (zh) |
Families Citing this family (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101567853B (zh) * | 2009-05-13 | 2011-08-10 | 中兴通讯股份有限公司 | 音频媒体发包控制装置、方法及音频媒体服务器 |
| CN105007281A (zh) * | 2015-08-10 | 2015-10-28 | 武汉中元华电软件有限公司 | 一种基于时间预测的网络同步报文md5加密装置及加密方法 |
| CN107809435A (zh) * | 2017-11-10 | 2018-03-16 | 北京锐安科技有限公司 | 一种amr语音数据的提取方法和装置 |
| CN111277900B (zh) * | 2018-12-05 | 2022-12-23 | 深圳市茁壮网络股份有限公司 | 一种机顶盒的启动方法和装置 |
| CN112511463B (zh) * | 2020-11-18 | 2022-04-05 | 潍柴动力股份有限公司 | 报文的发送方法及装置 |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101136772A (zh) * | 2007-09-28 | 2008-03-05 | 华为技术有限公司 | 定时发送报文的方法及报文发送模块 |
| CN101296184A (zh) * | 2008-05-30 | 2008-10-29 | 华为技术有限公司 | 一种数据传输的方法、***及装置 |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP0940986B1 (en) * | 1998-03-02 | 2011-02-16 | Panasonic Corporation | Method and system downloading a desired portion of a continuous medium with a raised precision |
| JP3348080B1 (ja) * | 2000-07-07 | 2002-11-20 | 松下電器産業株式会社 | データ送信装置とデータ受信装置及びデータ送受信方法 |
| EP1723539A4 (en) * | 2004-03-03 | 2009-02-25 | Packetvideo Network Solutions | SYSTEM AND METHOD FOR RECOVERING DIGITAL MULTIMEDIA CONTENT FROM A NETWORK NODE |
| CN1852423A (zh) * | 2006-01-10 | 2006-10-25 | 华为技术有限公司 | 一种网络流媒体节目播放***及方法 |
| CN101567853B (zh) * | 2009-05-13 | 2011-08-10 | 中兴通讯股份有限公司 | 音频媒体发包控制装置、方法及音频媒体服务器 |
-
2009
- 2009-05-13 CN CN2009101429225A patent/CN101567853B/zh not_active Expired - Fee Related
-
2010
- 2010-05-11 WO PCT/CN2010/072616 patent/WO2010130193A1/zh active Application Filing
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101136772A (zh) * | 2007-09-28 | 2008-03-05 | 华为技术有限公司 | 定时发送报文的方法及报文发送模块 |
| CN101296184A (zh) * | 2008-05-30 | 2008-10-29 | 华为技术有限公司 | 一种数据传输的方法、***及装置 |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2010130193A1 (zh) | 2010-11-18 |
| CN101567853A (zh) | 2009-10-28 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7286652B1 (en) | Four channel audio recording in a packet based network | |
| US6122665A (en) | Communication management system for computer network-based telephones | |
| KR100501324B1 (ko) | 음성 품질 예측값을 이용한 보이스 오버 인터넷프로토콜에서의 콜 라우팅 방법 | |
| EP2223492B1 (en) | Real-time network transport protocol interface method and apparatus | |
| US10068581B2 (en) | Method and arrangement for providing a backwards compatible payload format | |
| US7508815B2 (en) | Method and system for facilitating network troubleshooting | |
| CN101567853B (zh) | 音频媒体发包控制装置、方法及音频媒体服务器 | |
| US7124163B2 (en) | Data server | |
| WO2010083737A1 (zh) | 一种语音信号的处理方法、语音信号的发送方法及装置 | |
| CN101115011A (zh) | 一种流媒体回放方法、装置及*** | |
| CN101272383B (zh) | 一种实时音频数据传输方法 | |
| CN101022545A (zh) | 一种通过h.248协议实现多媒体播放的方法及*** | |
| CN102045586A (zh) | 网络设备、信息处理装置、流切换方法和内容分送*** | |
| CN101860537B (zh) | 一种媒体播放业务的实现方法及媒体服务器 | |
| Lee et al. | Study on eliminating delay and noise in on-site audio center of Anchor technology | |
| KR100726462B1 (ko) | 지능형 통합 멀티미디어 서버 | |
| WO2015196823A1 (zh) | 实现从文本到语音业务循环播放的方法、装置及服务器 | |
| JP3762709B2 (ja) | 音声ｉｐ伝送システム | |
| CN101552774A (zh) | 一种通过h.248协议实现多媒体播放的方法及*** | |
| JP4911579B2 (ja) | 解析のためにストリームを保存又は再生する端末、プログラム及び方法 | |
| WO2021255327A1 (en) | Managing network jitter for multiple audio streams | |
| Huang et al. | IDRS: an interactive digital radio station over Internet |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant | ||
| TR01 | Transfer of patent right | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20170822 Address after: 037500 Shanxi province Guangling County Hu Quan Zhen Jian Xi Cun, No. 1 Patentee after: Kang Haijuan Address before: 518057 Nanshan District high tech Industrial Park, Guangdong, South Road, science and technology, ZTE building, legal department Patentee before: ZTE Corporation |
|
| CF01 | Termination of patent right due to non-payment of annual fee | ||
| CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20110810 Termination date: 20180513 |