CN100463474C - 一种适用于ip媒体服务器的媒体处理系统 - Google Patents

Abstract

本发明公开了一种适用于IP媒体服务器的媒体处理系统，涉及网络通信领域的媒体处理系统。本发明由媒体资源控制模块1.1、编码格式转换模块1.2、存储资源模块1.3和媒体流传输模块1.4组成；分别用于：媒体资源的组织和管理；语音数据的编码格式转换；语音数据的存取管理；媒体流的发送和接收处理。在本发明中，编码格式转换是以单通道非实时处理方式实现的，在媒体会话过程中，媒体服务器无需对语音内容进行编码格式转换，从而显著降低了处理量；采用本发明后，基于主机媒体处理模式的系统容量达到了基于DSP板卡模式的系统容量，能够充分满足电信级的应用要求；由于成本低、容量大、配置灵活、扩展方便，为电信语音增值业务提供广泛的媒体资源支持。

Description

一种适用于IP媒体服务器的媒体处理系统

技术领域

本发明涉及网络通信领域的媒体处理系统，尤其涉及一种适用于IP媒体服务器的媒体处理系统。

背景技术

IP媒体服务器是软交换网络解决方案的一个重要组成部分，它位于网络的业务层，为软交换网络中的各种业务提供所需的媒体资源和服务，如：放音、录音、双音多频(DTMF：Dual Tone Multi Frequency)收号、交互式语音应答(IVR:Interactive Voice Response)、会议、不同编解码算法间的转换等。

IP媒体服务器主要由呼叫控制系统和媒体处理系统组成。其中，呼叫控制系统通过会话初始协议(SIP：Session Initiation Protocol)或H.248协议与控制设备进行信息交互，对媒体处理系统进行业务控制；媒体处理系统根据呼叫控制信息的指示，实现各种媒体处理和媒体流传输，通过实时传输协议(RTP:Real-time Transport Protocol)与媒体网关或软终端进行通信。

相对于呼叫控制系统的处理过程，媒体处理系统的处理过程包含大量复杂的数字信号处理(DSP：Digital Signal Processing)算法，处理数据量大，实时性强，设计难度高。根据媒体处理系统的实现模式，可分为DSP板卡模式和主机媒体处理模式。

1、DSP板卡模式

在这种实现模式中，全部媒体处理任务由高性能的DSP语音板块实现，主机只负责上层的资源管理和呼叫控制。基于DSP板卡模式的媒体处理系统的系统容量大，处理能力强，已有的电信级应用都采用这种模式。

2、主机媒体处理模式

这种模式是近年来随着通用计算机系统处理速度的迅速提高而出现的。它采用纯软件解决方案，全部媒体处理任务由通用计算机完成，无需额外的硬件支持。相对于采用DSP板卡模式，主机媒体处理模式具有成本低廉、开发效率高、安装配置灵活、功能扩充简便等优点，被誉为下一代电信设备的重要发展方向。然而，就目前的通用计算机处理能力，如果完全采用与DSP板卡模式相同的处理方法，存在着系统容量小、对主机配置要求高的局限。

综上所述，这两种模式均存在着一定的局限：DSP板卡模式虽然容量大，处理能力强，但硬件成本高；主机媒体处理模式虽然成本低，开发配置灵活，但容量较小，难以支持电信级的大规模应用。

发明内容

本发明的目的就在于克服上述两种媒体处理系统的不足，基于主机媒体处理模式，提供一种成本低、容量大的适用于IP媒体服务器的媒体处理系统。

本发明的目的是这样实现的。

如图1所示，媒体处理系统1为IP媒体服务器的组成部分。在IP媒体服务器中，包括呼叫控制系统2和媒体处理系统1。呼叫控制系统2通过软交换网络3，采用SIP协议，与控制设备(应用服务器、软交换设备)通信，根据控制设备的呼叫控制命令与媒体处理系统1交互。媒体处理系统1响应呼叫控制系统2的控制信息，采用RTP协议，与媒体终端(媒体网关、软终端)通信，完成相应的媒体处理任务，包括放音、录音、DTMF收号等。

媒体处理系统1由媒体资源控制模块1.1、编码格式转换模块1.2、存储资源模块1.3和媒体流传输模块1.4四部分组成；

媒体资源控制模块1.1通过外部控制通道与媒体服务器的呼叫控制系统2连接，通过内部控制通道分别与编码格式转换模块1.2、存储资源模块1.3和媒体流传输模块1.4连接；编码格式转换模块1.2以非实时单通道串行方式通过数据通道从存储资源模块1.3中读取待转换的语音文件，再把已转换的语音文件通过数据通道送给存储资源模块1.3，保存在语音文件库中；媒体流传输模块1.4以实时多通道并发方式通过数据通道从媒体流传输模块1.4读取要发送的语音信息，并将接收到的语音信息通过数据通道存放到存储资源模块1.3。

各模块的功能和主要运行过程如下：

媒体资源控制模块1.1：接收呼叫控制系统2的消息，生成相应的控制信息，通过控制信道分别控制编码格式转换模块1.2、存储资源模块1.3、媒体流传输模块1.4；

媒体流传输模块1.4：在收到媒体资源控制模块1.1发来的放音控制信息后，通过数据通道从存储资源模块1.3读取要播放的语音，然后打包由数据通道发送到软交换网络3；在收到媒体资源控制模块1.1发来的录音控制信息后，从数据通道接收媒体流数据包，根据包类型，将语音包送入存储资源模块1.3存取，将DTMF包转换成数字信息。

存储资源模块1.3：在收到媒体资源控制模块1.1发来的放音控制信息后，在语音文件库中检索对应编码格式的语音文件，然后读取文件，通过数据通道送到媒体流传输模块1.4；在收到媒体资源控制模块1.1发来的录音控制信息后，从数据通道读取媒体流传输模块1.4收到的语音信息，根据编码类型写入对应的语音文件中。

语音文件的命名规则为：前缀、后缀。其中，前缀由语音内容决定，由应用服务器和媒体服务器共同约定，后缀由编码类型决定。例如：02号语音内容对应的语音文件有02.711、02.723和02.729，若使用02号语音内容的媒体会话采用G.729编码，则存储资源模块1.3读取02.729文件，然后由媒体流传输模块1.4直接打包发送出去。

编码格式转换模块1.2：在收到媒体资源控制模块1.1发来的编码控制信息后，通过数据信道读取存储资源模块1.3中的语音数据，将其转换为其它几种语音格式，然后通过数据通道将转换后的数据存储到语音文件库中。经过这样的处理后，该语音内容具有G.711、G.723.1和G.729三种语音格式的文件。

综上所述，媒体处理系统1由媒体资源控制模块1.1、编码格式转换模块1.2、存储资源模块1.3和媒体流传输模块1.4四部分组成；

其中，媒体资源控制模块1.1用于媒体资源的组织和管理；媒体流传输模块1.4用于媒体流的发送和接收处理；编码格式转换模块1.2用于语音数据的编码格式转换；存储资源模块1.3用于语音数据的存取管理，这些语音数据以文件形式保存在媒体服务器的硬盘中。

在主机媒体处理模式下，各模块为独立的进程，模块间的控制命令和状态指示通过控制通道传输，模块间的语音数据通过数据通道传输。控制通道采用松耦合的消息接口方式实现，以增强控制操作的独立性。数据通道采用紧耦合的函数调用数据缓冲区指针方式实现，以增强数据传输的高效性。媒体资源控制和媒体流传输是以多通道实时方式运行的，以较高优先级方式运行。编码格式转换是以单通道非实时方式运行的，为一优先级较低的守护进程。

媒体服务器在支持非混音业务(如放音、录音、IVR等)时，与媒体终端(媒体网关、综合接入终端或软终端)之间的媒体会话过程有如下特点：

1、媒体流传输是端对端的，通信双方使用相同的媒体编码类型，并在当前会话过程中保持不变；

2、对于放音业务，媒体服务器所读取的语音内容是预先准备的；

3、对于录音业务，媒体服务器所记录的录音内容由当前会话独占，距下次访问该录音内容的会话有一定时间间隔。

以上特点表明：媒体服务器能够以非实时方式提供媒体会话所需的语音内容。

按照国家标准《基于软交换的媒体服务器技术要求》，媒体服务器必须同时支持G.711、G.723.1和G.729三种语音编码标准。因此，对于每一份语音内容，必须有G.711、G.723.1和G.729三种对应的编码格式文件，这样才能保证在放音过程中，根据媒体终端的编码类型选择访问相应的文件，而无需实时编码格式转换处理。

本发明根据对媒体会话过程的分析，采用了一种特殊的处理机制：所有语音内容在被媒体会话利用之前，进行相应的编码格式转换。这样，在媒体会话启动后，媒体服务器无需进行实时编码格式转换就能提供相应的媒体增值服务。

媒体处理系统1采用两种方式对语音数据进行非实时编码格式转换：安装式和在线式。

1、安装式

对于常用的语音数据，如号码音、业务音提升、铃音等，进行预先处理，在系统软件安装时使用单独的编码格式转换工具生成。

2、在线式

对于系统运行中生成的语音数据，如语音留言业务中的录音文件，由编码格式转换模块生成。主要的工作过程包括：在用户留言后媒体资源控制模块向编码格式转换模块发出格式转换消息；编码格式转换模块不断从格式转换消息队列中读取格式转换消息，执行格式转换操作，将只有一种编码格式的语音内容转换成三种编码格式的语音内容。

同一用户的语音留言和听取是采用相同语音编码的，即使不进行编码格式转换也不会影响听取。虽然不同用户间选用的语音编码可能不同，但由于语音留言在前，听取留言在后，两种操作存在一定的时间间隔，因此只要编码格式转换模块能在该时间间隔内将语音内容转换完毕，就可以实现采用实时编码格式转换时同样的功能，且语音业务质量(QoS：Quality of Service)不会降低。

媒体服务器提供的许多媒体增益业务需要DTMF收号的支持，为了避免在DTMF收号过程中进行实时编码格式转换，要求与媒体服务器通信的媒体终端必须支持RFC2833标准或带外传输方式。遵循《基于软交换的媒体服务器技术要求》的媒体终端能够满足这样的功能要求。

本发明具有以下优点和积极效果：

1、在已有的各种媒体处理系统中，编码格式转换是以多通道实时处理方式实现的。对于一些常用的语音编码格式(如G.723.1、G.729等)，实时编码格式转换的运算量非常大，占媒体会话过程处理量的80％以上。在本发明中，编码格式转换是以单通道非实时处理方式实现的，在媒体会话过程中，媒体服务器无需对语音内容进行编码格式转换，从而显著降低了处理量。

2、采用本发明后，基于主机媒体处理模式的系统容量达到了基于DSP板卡模式的系统容量，能够充分满足电信级的应用要求。

3、本发明主要用于与基于软交换的呼叫控制系统一起组成成本低、容量大、配置灵活、扩展方便的IP媒体服务器，为电信语音增值业务提供广泛的媒体资源支持。

附图说明

图1是本发明的总体结构图；

图2是媒体资源控制模块(1.1)结构图；

图3是通道资源管理(1.1.2)状态流程图；

图4是编码格式转换模块(1.2)结构图；

图5是媒体流传输模块(1.4)结构图；

图6A是多通道实时编码格式转换示意图；

图6B是单通道非实时编码格式转换示意图；

图7是语音留言的工作流程图；

其中：

1—媒体处理系统，

1.1—媒体资源控制模块，

1.1.1—业务逻辑，1.1.2—通道资源管理，1.1.3—存储资源管理；

1.2—编码格式转换模块，

1.2.1—格式转换消息队列，1.2.2—第一选择开关，

1.2.3—第二选择开关；

1.3—存储资源模块；

1.4—媒体流传输模块，

1.4.1—放音控制，  1.4.2—录音控制，  1.4.3—指示轮询分块读取，

1.4.4—放音，      1.4.5—RTP协议栈，1.4.6—UDP接口，

1.4.7—录音，      1.4.8—DTMF。

2—呼叫控制系统。

3—软交换网络。

4—媒体网关/软终端。

a—空闲状态；    b—激活状态；   c—激活放音进程；

d—激活录音进程；e—激活DTMF进程。

主要英文缩略语：

DTMF—双音多频；    IVR—交互式语音应答；  SIP—会话初始协议；

RTP—实时传输协议； DSP—数字信号处理；    UDP—用户数据报协议；

Actv—激活；        Deactv—停止激活。

具体实施方式

下面结合附图和实施例详细说明。

1、媒体资源控制模块1.1

如图2，媒体资源控制模块1.1由业务逻辑1.1.1、通道资源管理1.1.2和存储资源管理1.1.3三个功能部分组成；

媒体资源控制模块1.1将呼叫控制系统2发来的控制信息经控制通道读取到业务逻辑1.1.1；

其中控制信息，如建立、拆除放音、录音通道，建立DTMF传输通道等，交由通道资源管理1.1.2处理；通道资源管理1.1.2将解析后的控制信息经控制通道传给媒体流传输模块1.4；

其中控制信息，如读取语音、存储语音以及对存储语音的编码格式转换等控制信息交由存储资源管理1.1.3来处理；存储资源管理1.1.3将编码控制信息经控制通道传给编码格式转换模块1.2，将读写控制信息经控制通道传给存储资源模块1.3。

图3是媒体资源控制模块1.1的通道资源管理1.1.2状态流程图，当没有建立任何数据流通道时，系统处于空闲状态a；当建立通道的控制信息Actv到来后，通道建立，系统处于激活状态b；判断要求执行任务的类型，如果是要求放音，则经控制信道激活放音进程c，如果要求录音，则经控制信道激活录音进程d，如果是DTMF收发号，则激活DTMF进程e。当这三项任务中被激活的任务执行完以后，通过控制信道告知系统任务结束，回到空闲状态a。

2、编码格式转换模块1.2

如图4，在媒体资源控制模块1.1的控制下，编码格式转换模块1.2完成编码格式的转换，以及与存储资源的信息交互；媒体资源控制模块1.1通过控制信道将控制信息传给编码格式转换模块1.2中的格式转换消息队列1.2.1；语音格式的转换分为两步，首先将语音信号还原成PCM16的编码格式，然后再对每一路PCM16信号分别转换成G.711、G.723.1和G.729三种语音格式；在编码格式转换模块1.2中还有两个选择开关；第一选择开关1.2.2判断从存储资源中读取的语音信号的编码格式类型，然后打开相应的开关还原成PCM16信号；还原后的数据都送到第二选择开关1.2.3；第二选择开关1.2.3接收完一段数据后，就将数据分别送到数据通道进行三种格式的转换；转换后的数据经数据通道送到存储资源模块1.3。

3、媒体流传输模块1.4

如图5，媒体资源控制模块1.1通过两个控制通道将控制信息传递给媒体流传输模块1.4中的放音控制1.4.1和录音控制1.4.2；放音控制1.4.1通过控制通道指示轮询分块读取1.4.3，从存储资源模块1.3的数据通道中读取要播放的语音，再将读取的信息通过多通道传送给放音1.4.4；RTP协议栈1.4.5从放音1.4.4的多数据通道接收到语音后转换成RTP包，经通道传送给用户数据报协议(UDP：User Datagram Protocal)接口模块1.4.6，打包成UDP包后，经通道发送到媒体网关/软终端4；

媒体流传输模块1.4从媒体网关/软终端4接收到语音信号，媒体资源控制模块1.1通过控制通道指示开始录音；UDP接口1.4.6将UDP包中的RTP包提取出来，经通道；送到RTP协议栈1.4.5中，RTP协议栈1.4.5就对RTP包进行处理，提取语音数据发送到录音1.4.7的多通道520上，录音1.4.7将各路语音经数据通道送到存储资源模块1.3保存；DTMF1.4.8将DTMF包转换成数字。

4、图6A、图6B为本发明与已有媒体处理方法在语音编码格式转换过程中的对比示意图。

图6A描述了已有的媒体处理方法。可以看出，各个用户发来的语音数据经多通道在媒体流传输模块接收，处理后又经多通道送到编码转换模块转换成单一的语音编码格式，再经多通道存放在存储资源模块中。各个用户要听取的语音数据经多通道从存储资源中提取，由于仅以一种格式存放，在发送给用户之前，要经编码转换模块转换成与用户匹配的语音格式，编码转换完成后，各路语音再经多通道送到媒体流传输模块，打包后经各路媒体通道发送给用户。整个过程都是多通道独立进行，并且语音数据都是实时的进行编码转换，运算量相当大。

图6B描述了本发明的媒体处理方法。可以看出，各个用户发来的语音数据也是经多通道在媒体流传输模块接收，但是处理后经多通道送到存储资源的单一格式语音文件库。当编码转换模块收到上层发来的“编码转换”消息后，开始从存储资源的单一格式语音文件库中经单数据通道一个一个的处理先前用户发来的语音信息。当读取了一个语音信息后，就开始将这个语音信息逐步转换成三种对应的语音编码格式。转换完后的三份不同格式的语音文件再经单数据通道存放到存储资源的三种格式语音文件库中。编码转换模块处理完一个语音信息后再接收下一个语音信息并开始相同的处理过程。所以通过利用留言的录音和听取的时间间隔，从媒体流传输模块接收语音信息后并不立即进行编码转换，而是先存起来，等收到编码控制消息，再逐一将单一格式的语音信息转换成三种不同格式的语音文件存储起来。等用户需要听取时，就将格式匹配的那份文件发送给用户。

5、下面通过理论分析进一步说明上述两种方法在系统容量方面的差别。

设定如下参数：

L：录音文件的平均时间长度；

T：从对一个用户录音完成到对另一用户开始放音的时间间隔；

N1：采用已有媒体处理方法的最大媒体通道路数；

N2：采用本发明的媒体处理方法的最大媒体通道路数。

当两种处理方法所采用的计算机系统资源完全相同时，忽略RTP传输能力的限制和多通道处理转换的处理开销，可得到已有媒体处理方法在处理录音文件的平均时间长度约为L/N1，这样在T内可完成的录音文件数目为TgN1/L，即 $N2=\left(\frac{T}{L}\right)N1$ 。显然，由于T>>L，因此本发明的媒体处理方法所获得的系统容量明显超过图6A方式。

在语音编码格式为G.723.1，CPU占用率为50％，CPU型号为PIII 1.3GHz，内存为512MHz的条件下，采用已有媒体处理方法的N1可达到16路。相同条件下，本发明的媒体处理方法的分析结果如下表所示：

图7以语音留言业务为实例，描述了媒体处理系统的一种处理工作流程。通过媒体资源控制模块，用户1和媒体流传输模块间建立起媒体通道。媒体资源控制模块向媒体流传输模块发“留言提示音”消息。存储资源将相应的语音文件送给媒体流传输模块。媒体流传输模块进行DTMF收号的同时将语音文件打包后发送给用户1。用户留言开始时，媒体流传输模块进行DTMF收号的同时，将留言信息存储到存储资源中未转换的区域。留言结束后，媒体通道被释放。媒体资源控制模块根据用户留言的优先级，向编码转换模块发“格式转换消息”。编码转换模块就开始一路一路的将留言信息转换成三种编码格式，然后再存储到存储资源中转换后资源的区域。在这个过程中，还可以再进行其它的录音和听音的任务。当用户2要听取这段留言时，用户2通过媒体资源控制模块与媒体流传输模块建立媒体通道。媒体资源控制模块向媒体流传输模块发“放留言”消息。存储资源在已转换区域找到需要的语音文件，传送给媒体流传输模块打包。媒体流传输模块在进行DTMF收号的同时，将留言发送给用户2。听完留言后，释放媒体通道。。

图7只是一种典型的语音留言业务的示例性说明，本领域普通技术人员可以理解，本发明使用的媒体处理系统及其处理方法，其具体实施的工作流程并不是唯一的，不同的业务间本身具有不同的工作流程，同一业务间也会因业务形式的个性化而具有不同的工作流程。在这些业务中，不偏于本发明思想的对本发明技术方案的各种改型将落入本发明权利要求所限定的保留范围内。

Claims (5)

1.一种适用于IP媒体服务器的媒体处理系统，其特征在于：

媒体处理系统(1)由媒体资源控制模块(1.1)、编码格式转换模块(1.2)、存储资源模块(1.3)和媒体流传输模块(1.4)四部分组成；

媒体资源控制模块(1.1)通过外部控制通道与媒体服务器的呼叫控制系统(2)连接，通过内部控制通道分别与编码格式转换模块(1.2)、存储资源模块(1.3)和媒体流传输模块(1.4)连接；编码格式转换模块(1.2)以非实时单通道串行方式通过数据通道从存储资源模块(1.3)中读取待转换的语音文件，再把已转换的语音文件通过数据通道送给存储资源模块(1.3)，保存在语音文件库中；媒体流传输模块(1.4)以实时多通道并发方式通过数据通道从媒体流传输模块(1.4)读取要发送的语音信息，并将接收到的语音信息通过数据通道存放到存储资源模块(1.3)；

所述的媒体资源控制模块(1.1)，是一种用于媒体资源的组织和管理的模块；

所述的媒体流传输模块(1.4)，是一种用于媒体流的发送和接收处理的模块；

所述的编码格式转换模块(1.2)，是一种用于语音数据的编码格式转换的模块；

所述的存储资源模块(1.3)，是一种用于语音数据的存取管理的模块。

2.按权利要求1所述的一种适用于IP媒体服务器的媒体处理系统，其特征在于媒体资源控制模块(1.1)：

媒体资源控制模块(1.1)由业务逻辑(1.1.1)、通道资源管理(1.1.2)和存储资源管理(1.1.3)三个功能部分组成；

媒体资源控制模块(1.1)将呼叫控制系统(2)发来的控制信息经控制通道读取到业务逻辑(1.1.1)；

其中控制信息包括建立、拆除放音、录音通道，建立双音多频传输通道，交由通道资源管理(1.1.2)处理；通道资源管理(1.1.2)将解析后的控制信息经控制通道传给媒体流传输模块(1.4)；

其中控制信息包括读取语音、存储语音以及对存储语音的编码格式转换控制信息交由存储资源管理(1.1.3)处理；存储资源管理(1.1.3)将编码控制信息经控制通道传给编码格式转换模块(1.2)，将读写控制信息经控制通道传给存储资源模块(1.3)。

3.按权利要求2所述的一种适用于IP媒体服务器的媒体处理系统，其特征在于媒体资源控制模块(1.1)的通道资源管理(1.1.2)状态流程是：

当没有建立任何数据流通道时，系统处于空闲状态(a)；

当建立通道的控制信息激活到来后，通道建立，系统处于激活状态(b)；

判断要求执行任务的类型，如果是要求放音，则经控制信道激活放音进程(c)，如果要求录音，则经控制信道激活录音进程(d)，如果是双音多频收号，则激活双音多频进程(e)；

当这三项任务中被激活的任务执行完以后，通过控制信道告知系统任务结束，回到空闲状态(a)。

4.按权利要求1所述的一种适用于IP媒体服务器的媒体处理系统，其特征在于编码格式转换模块(1.2)：

在媒体资源控制模块(1.1)的控制下，编码格式转换模块(1.2)完成编码格式的转换，以及与存储资源的信息交互；媒体资源控制模块(1.1)通过控制信道将控制信息传给编码格式转换模块(1.2)中的格式转换消息队列(1.2.1)；语音格式的转换分为两步，首先将语音信号还原成PCM16的编码格式，然后再对每一路PCM16信号分别转换成G.711、G.723.1和G.729三种语音格式；在编码格式转换模块(1.2)中还有两个选择开关；第一选择开关(1.2.2)判断从存储资源中读取的语音信号的编码格式类型，然后打开相应的开关还原成PCM16信号；还原后的数据都送到第二选择开关(1.2.3)；第二选择开关(1.2.3)接收完一段数据后，就将数据分别送到数据通道进行三种格式的转换；转换后的数据经数据通道送到存储资源模块(1.3)。

5.按权利要求1所述的一种适用于IP媒体服务器的媒体处理系统，其特征在于媒体流传输模块(1.4)：

媒体资源控制模块(1.1)通过两个控制通道将控制信息传递给媒体流传输模块(1.4)中的放音控制(1.4.1)和录音控制(1.4.2)；放音控制(1.4.1)通过控制通道指示轮询分块读取(1.4.3)，从存储资源模块(1.3)的数据通道中读取要播放的语音，再将读取的信息通过多通道传送给放音(1.4.4)；RTP协议栈(1.4.5)从放音(1.4.4)的多数据通道接收到语音后转换成RTP包，经通道传送给UDP接口模块(1.4.6)，打包成UDP包后，经通道发送到媒体网关/软终端(4)；

媒体流传输模块(1.4)从媒体网关/软终端(4)接收到语音信号，媒体资源控制模块(1.1)通过控制通道指示开始录音；UDP接口(1.4.6)将UDP包中的RTP包提取出来，经通道送到RTP协议栈(1.4.5)中，RTP协议栈(1.4.5)就对RTP包进行处理，提取语音数据发送到录音(1.4.7)的多通道上，录音(1.4.7)将各路语音经数据通道送到存储资源模块(1.3)保存；双音多频(1.4.8)将双音多频包转换成数字；

所述的RTP即实时传输协议，所述的UDP即用户数据报协议。

Images