CN101005448A - 一种VoIP网关传输媒体流的方法 - Google Patents

Abstract

本发明提供了一种VoIP网关传输媒体流的方法，以RTP报文的格式传输媒体流，且发送端的DSP芯片或软件模块采集的媒体流直接传送至接收端的DSP芯片或软件模块。本发明克服了现有VoIP媒体流传输要跨越物理层、数据链路层、网络层、传输层、Socket层到达DSP编解码模块，程序运行效率相当低的不足，提供一种低开销的媒体流传输方法，使VoIP网关设备可以采用性能较低的CPU，从而降低制造成本。

Description

一种VoIP网关传输媒体流的方法

技术领域

本发明属于VoIP的网络应用领域，特别是涉及一种在VoIP网关中传输媒体流的方法。

技术背景

VoIP(Voice over Internet Protocol)是指将模拟的声音讯号经过压缩与封包之后，以数据封包的形式在IP网络的环境进行语音讯号的传输，通俗来说也就是互联网电话、网络电话或者简称IP电话的意思。VoIP的基本原理是：通过语音的压缩算法对语音数据编码进行压缩处理，然后把这些语音数据按TCP/IP标准进行打包，经过IP网络把数据包送至接收地，再把这些语音数据包串起来，经过解压处理后，恢复成原来的语音信号，从而达到由互联网传送语音的目的。VoIP技术是目前互联网应用领域的一个热门话题，成为2006年全球互联网与电子商务十大趋势之一。

常用的VoIP网关设备包括接入网关(AG，Access Gateway)，综合接入设备(IAD，Integrated Access Device)，中继媒体网关(TMG，Trunking Media Gateway)等，绝大部分设备采用的DSP芯片(数字信号处理芯片)不具备媒体流传输能力。为满足VoIP网关的媒体传输能力和呼叫处理能力要求，设计人员经常采用处理性能较强的中央处理器(CPU)。但这样做会带来成本上升，以及硬件总线频率升高导致系统不稳定的弊端。

在VoIP系统中，媒体流编码后以UDP报文的格式发送。UDP是一个非面向连接的不可靠的数据传输协议，IP首部和UDP首部长度固定，IP首部没有额外的选项，这样在网络接口驱动层，知道UDP报文的源IP地址、目的IP地址、源端口、目的端口信息就可以分析UDP报文，实现UDP报文的解包和组包。基于这种原理，一些高端DSP芯片不仅实现了媒体流的编解码功能，而且集成了媒体流的收发功能，从而解决了超高密度端口设备的CPU处理瓶颈。此外媒体流发送报文的源端口和接收报文的目的端口由网关自身决定，因此可以预留端口用于传输媒体流。

现有RTP报文正常传输路径如附图1左半部分所示，媒体流传输要跨越物理层、数据链路层、网络层、传输层、Socket层到达DSP编解码模块，程序运行效率相当低。如果在网络接口驱动实现RTP报文的收发处理功能，同时保证其余报文的处理过程不变，系统性能将大幅改善。

发明内容

本发明的目的在于克服现有技术的不足，提供一种低开销的媒体流传输方法，使VoIP网关设备可以采用性能较低的CPU，从而降低制造成本。

为了实现上述发明目的，本发明采用的技术方案如下：

一种VoIP网关传输媒体流的方法，以RTP报文的格式传输媒体流，且发送端的DSP芯片或软件模块采集的媒体流直接传送至接收端的DSP芯片或软件模块。

本发明将媒体流绕过数据链路层、网络层、传输层、Socket层，直接发送至接收端，提升了运行效率。

上述技术方案中，所述发送端的网络接口驱动模块设置一个识别模块，所述识别模块对进入发送端物理层的报文进行识别过滤，对不属于所确定媒体流RTP报文格式的，则识别模块不做任何处理，该报文经过正常的TCP/IP协议栈处理，而对属于所确定媒体流RTP报文格式的，则识别模块直接将该报文发送至接收端。

本发明通过VoIP呼叫控制协议对传输过程的发送端和接收端的网络地址、传输端口进行协商，所述VoIP呼叫控制协议采用SIP、或Megaco/H.248、或MGCP、或H.323。

所述识别模块根据VoIP呼叫控制协议所协定的RTP端口范围，如果收到的报文的端口在此范围内，则识别该报文为媒体流RTP报文。

本发明的发送端收到媒体流RTP报文后，还根据报文的目的端口号匹配媒体流通道号。

发送端的将媒体流RTP报文封装“物理地址头/IP头/UDP头”后，通过网络驱动接口发送至接收端。

本发明还根据媒体流RTP报文的源地址和端口，结合VoIP呼叫控制协议协商的对端地址信息，判断是否要执行地址守护处理，所述的对端地址信息，包括媒体流传输过程的发送端和接收端，且由于传输过程为双向，端设备通常都是既作为发送端，又作为接收端；所述的地址守护处理，就是判断呼叫控制协议中的对端地址和媒体端口与接收的RTP报文中的源IP地址及源UDP端口是否一致，如果不一致，说明对端发送的报文经过了NAT/防护墙或特殊网络，设备把RTP报文直接送到VoIP协议协商得到的对端地址和端口，这些RTP将会被丢弃。为了解决这个问题，当发现地址或端口不匹配时，修改相关程序，则将RTP报文发送到接收报文中的源IP地址及源端口。

由此可见，本发明的技术方案巧妙实现了媒体流绕过网络协议栈传输，与现有技术相比，具有以下明显优越之处：

1、降低了低中密度媒体网关设备对CPU处理能力要求，从而可以降低系统的整体制造成本。

2、采用该技术，媒体网关设备容易实现堆叠功能，客户可以根据需要先购买一定数量的设备，以后扩容时堆叠设备即可，而用户网络拓扑不发生变化。

附图说明

图1为本发明的原理示意图，其中左半部分为现有RTP格式的传输原理图，右半部分为本发明的媒体流RTP格式报文传输示意图；

图2为呼叫控制协议会话发起端的配置示意图：

图3为呼叫控制协议会话接收端的配置示意图；

图4为本发明的传输过程示意图。

具体实施方式

下面结合附图对本发明做进一步的说明。

本发明的原理示意图如附图1的右半部分所示，发送端的驱动程序模块设置有一识别模块，俗称之为“绕过网络协议栈模块”，网络数据流进入物理层后，绕过网络协议栈模块识别该数据流是否为本发明所确定传输的VoIP媒体流，并将该媒体流直接传送至接收端的DSP编码解码模块。

进入系统的报文首先进行过滤，如果报文不属于本发明的RTP报文，绕过网络协议栈模块不做处理。如果报文属于本发明所确定的RTP报文，则对其进行处理，处理过程如下：

1、RTP报文为UDP报文，由于VoIP呼叫控制协议(SIP、Megaco/H.248、MGCP、H.323)协商媒体流参数时，端对端会话中的任意一端的媒体流端口是自身决定的，本实施例以SIP(会话初始化协议)为例，会话发起方的配置如附图2所示，在SDP(会话描述协议)的“Media Port”规定了媒体流端口为13000，会话应答方的配置如附图3所示，在SDP(会话描述协议)的“Media Port”规定了媒体流端口为17762。因此可以规定RTP端口属于某一范围，例如13000～14000，如果收到的UDP报文的端口在此范围内，该报文为RTP报文。

2、呼叫控制协议协商过程能够获取当前激活的RTP端口号，如附图2中的INVITE信令中的“Media Port”规定了媒体流端口为13000，附图3中的200应答信令中“Media Port”规定了媒体流端口为17762。

3、如果接收UDP报文的目的端口号与当前激活的某个RTP端口匹配，该报文属于系统需要的RTP报文，经过“绕过网络协议栈模块”处理后直接将报文递交媒体流解码模块处理；否则该报文将走正常的TCP/IP协议栈处理流程。

上述处理过程中，收到的报文如果为RTP报文，根据UDP报文的目的端口号匹配媒体流通道号。

收到的报文如果为RTP报文，还需要根据报文的源地址和端口，结合VoIP协议协商的对端地址信息(通过呼叫控制协议，可以获取对端RTP报文的接收地址，如附图2和附图3中“ConnectionInformation”中的地址以及“Media Port”中的端口)，判断是否要执行地址守护处理。这里所说的地址守护处理，就是判断呼叫控制协议中的对端地址(Connection Information)和媒体端口(Media Port)与接收RTP报文中的源IP地址及源UDP端口是否一致。如果两者不一致，说明对端发送的报文经过了NAT/防护墙或特殊网络，设备把RTP报文直接送到VoIP协议协商得到的对端地址和端口，这些RTP将会被丢弃。为了解决这个问题，当发现地址或端口不匹配时，修改相关程序，使RTP报文发送到接收报文中的源IP地址及源端口，这样处理后，RTP报文一般可以到达对端设备。

媒体流编码模块产生的RTP报文封装适当的“物理地址头/IP头/UDP头”后，通过网络驱动接口发送到对端设备。

为了正确组包，还必须从VoIP信令协商结果中获取报文的对端地址。保证对端物理地址、IP头等信息与TCP/IP协议栈中的相关信息保持一致。

本发明可以用来传输语音、T.38，也可以扩展传输任何使用UDP封装的媒体流。且由于系统性能的提升，本发明可以实现媒体网关设备堆叠，这样多台低密度端口设备可以堆叠成为一台高密度端口设备，从逻辑上看，这些设备从属于一台设备。其中一台充当主设备，负责所有设备的信令处理以及该设备的媒体流处理；其余设备仅负责媒体流的传输以及主从设备的通信。

下面以SIP协议会话接收方(IAD：220.96.25.22)为例，介绍VOIP呼叫控制协议报文、RTP报文在TCP/IP协议栈中的传输过程，如附图4所示：

1、所有的SIP报文不绕过TCP/IP协议栈传输，即还采用现有的TCP/IP协议栈传输；

2、SIP信令协商成功后，RTP报文绕过TCP/IP协议栈传输；

3、由于IP电话机(192.168.1.1)在私网内，IAD执行地址守护处理后，修改发送RTP报文的对端地址和端口为220.96.25.25:32568；

4、当IAD执行挂机处理后，接收的RTP报文不绕过TCP/IP协议栈传输。

Claims (7)

1、一种VoIP网关传输媒体流的方法，其特征在于以RTP报文的格式传输媒体流，且发送端的DSP芯片或软件模块采集的媒体流直接传送至接收端的DSP芯片或软件模块。

2、根据权利要求1所述的VoIP网关传输媒体流的方法，其特征在于所述发送端的网络接口驱动模块设置一个识别模块，所述识别模块对进入发送端物理层的报文进行识别过滤，对不属于所确定媒体流PRT报文格式的，则识别模块不做任何处理，对属于所确定媒体流PRT报文格式的，则识别模块直接将该报文发送至接收端。

3、根据权利要求2所述的VoIP网关传输媒体流的方法，其特征在于通过VoIP呼叫控制协议对传输过程的发送端和接收端的网络地址、传输端口进行协商，所述VoIP呼叫控制协议采用SIP、或Megaco/H.248、或MGCP、或H.323。

4、根据权利要求3所述的VoIP网关传输媒体流的方法，其特征在于所述识别模块根据VoIP呼叫控制协议所协定的RTP端口范围，如果收到的报文的端口在此范围内，则识别该报文为媒体流RTP报文。

5、根据权利要求2或3或4所述的VoIP网关传输媒体流的方法，其特征在于发送端收到媒体流RTP报文后，还根据报文的目的端口号匹配媒体流通道号。

6、根据权利要求5所述的VoIP网关传输媒体流的方法，其特征在于所述发送端的将媒体流RTP报文封装“物理地址头/IP头/UDP头”后，通过网络驱动接口发送至接收端。

7、根据权利要求6所述的VoIP网关传输媒体流的方法，其特征在于还根据媒体流RTP报文的源地址和端口，结合VoIP呼叫控制协议协商的对端地址信息，判断是否要执行地址守护处理；

所述的地址守护处理，就是判断呼叫控制协议中的对端地址和媒体端口与接收的RTP报文中的源IP地址及源UDP端口是否一致，如果不一致，则将RTP报文发送到接收报文中的源IP地址及源端口。

Images