CN100586107C - 传输实时传输协议报文的方法和通讯设备 - Google Patents

传输实时传输协议报文的方法和通讯设备 Download PDF

Info

Publication number
CN100586107C
CN100586107C CN200710121887A CN200710121887A CN100586107C CN 100586107 C CN100586107 C CN 100586107C CN 200710121887 A CN200710121887 A CN 200710121887A CN 200710121887 A CN200710121887 A CN 200710121887A CN 100586107 C CN100586107 C CN 100586107C
Authority
CN
China
Prior art keywords
communication apparatus
conversation
rtp message
rtp
message identification
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.)
Active
Application number
CN200710121887A
Other languages
English (en)
Other versions
CN101132366A (zh
Inventor
宋海宾
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
New H3C Technologies Co Ltd
Original Assignee
Hangzhou H3C Technologies Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Hangzhou H3C Technologies Co Ltd filed Critical Hangzhou H3C Technologies Co Ltd
Priority to CN200710121887A priority Critical patent/CN100586107C/zh
Publication of CN101132366A publication Critical patent/CN101132366A/zh
Application granted granted Critical
Publication of CN100586107C publication Critical patent/CN100586107C/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本发明公开了一种传输实时传输协议RTP报文的方法,包括:第一通讯设备为自身与第二通讯设备之间的第一通话和第二通话分别分配第一RTP报文标识和第二RTP报文标识,并用第一RTP报文标识标记第一通话的RTP报文,用第二RTP报文标识标记第二通话的RTP报文,将经过标记的第一通话的RTP报文和第二通话的RTP报文合并成具有一个头部信息的复合RTP报文后,发送至第二通讯设备。本发明公开了一种传输RTP报文的通讯设备。本发明的技术方案不仅提高了传输RTP报文过程中的带宽利用率,还节省了端口资源。

Description

传输实时传输协议报文的方法和通讯设备
技术领域
本发明涉及基于IP网络的语音传输(VoIP,Voice over Internet Protocol)技术领域,尤指一种传输实时传输协议(RTP,Real Time Transport Protocol)报文的方法和通讯设备。
背景技术
目前,在VoIP系统中,每路通话都有自己独立的媒体通道用于承载媒体信息,且每一路媒体通道由媒体信息收发双方的IP地址及端口号进行标识。
图1是现有技术中的VoIP系统组网示意图。在图1中,VoIP网关1(VoIPGW-1)的IP地址为192.168.1.1,VoIP网关2(VoIP GW-2)的IP地址为192.168.1.2,VoIP网关通过不同的端口与电话终端相连,且VoIP GW-1上的号码为82770001、82770002和82770003的三部电话终端分别与VoIP GW-2上的号码为68120001、681270002和68120003的三部电话终端分别进行通话。这样有三个媒体通道,可以用通话终端双方的所属VoIP网关的IP地址以及通话终端双方所连接的端口号区分不同的媒体通道。
在图1所示的VoIP系统中,每一路通话的建立都需要先进行媒体协商。目前,使用初始化会话协议(SIP:RFC3261)作为VoIP信令实现媒体协商,且具体媒体协商过程是通过消息体(BODY)实现的,消息体使用会话描述协议(SDP:RFC2327)。图2是现有技术在VoIP系统中建立通话时的媒体协商流程图。如图2所示,VoIP GW-1和VoIP GW-2经过“Invite”、“180Ring”、“200OK”和“Ack”消息的协商后,建立媒体通道,其中每个消息的SDP部分如下:
①Invite的SDP部分
v=0
o=Quidway 1073741840 1073741840 IN IP4 100.1.1.56
s=Sip Call
c=IN IP4 100.1.1.56
t=00
m=audio 16400RTP/AVP 18 8 0 4
a=rtpmap:18G729/8000
a=rtpmap:8PCMA/8000
a=rtpmap:0PCMU/8000
a=rtpmap:4G723/8000
②180Ring的SDP部分
v=0
o=Quidway 1073741846 1073741846 IN IP4 100.1.1.6
s=Sip Call
c=IN IP4 100.1.1.6
t=00
m=audio 16400RTP/AVP 18
a=rtpmap:18G729/8000
③200Ok的SDP部分
v=0
o=Quidway 1073741848 1073741848 IN IP4 100.1.1.6
s=Sip Call
c=IN IP4 100.1.1.6
t=00
m=audio 16400 RTP/AVP 18
a=rtpmap:18G729/8000
④Ack无SDP部分
在上述消息的SDP部分中,通过c=IN IP4IP address来指示本端VoIPGW使用的媒体通道中的IP地址,m=audio port-num RTP/AVP 18指明对应电话终端所使用的端口号。在同一个VoIP GW中,一个端口号只能给一路通话使用。
通过图2所示的媒体协商流程后,即在通信双方之间建立了媒体通道,可以在所建立的媒体通道上传输实时的媒体信息。目前,在IP网络上进行媒体信息传输的方式是:将实时媒体信息按很小的时间间隔分割成一个个承载媒体信息的RTP报文在IP网络上传输。RTP协议是基于用户数据报协议(UDP,User Datagram Protocol)之上的实时传输协议,根据TCP/IP协议的分层原理,在IP网络上传输的RTP报文除了承载媒体信息外还必须添加一些额外的头部信息才能在IP网络上传输。图3是现有技术中的RTP报文的格式示意图。如图3所示,一个RTP报文除了x字节的媒体数据外,还包括:14个字节的以太网首部、20个字节的IP首部、8个字节的UDP首部以及12个字节的RTP首部,共54字节的头部信息。当使用G.729编码格式时,x=30,即每发送一个84字节的RTP报文,其中就包含了与媒体信息无关的54个字节的额外开销,只有30个字节是媒体数据,表明语音信息静负荷带宽利用率才为30/84=35.7%左右,而其它64.3%的信息是与语音信息无关的其它信息。
因此,现有的在VoIP网络中传输RTP报文的技术中,带宽利用率很低。
发明内容
本发明提供了一种传输RTP报文的方法,该方法不仅提高了传输RTP报文过程中的语音信息静负荷带宽利用率,还节省了端口资源。
本发明还提供了一种传输RTP报文的通讯设备,该通讯设备不仅提高了传输RTP报文过程中的语音信息静负荷带宽利用率,还节省了端口资源。
为达到上述目的,本发明的技术方案具体是这样实现的:
本发明公开了一种传输RTP报文的方法,该方法包括:
第一通讯设备为第一通话分配第一RTP报文标识,为第二通话分配第二RTP报文标识,并将第一RTP报文标识和第一通话的对应关系以及第二RTP报文标识和第二通话的对应关系通知第二通讯设备;其中,所述第一通话和第二通话均为第一通讯设备和第二通讯设备之间的通话,且第一RTP报文标识和第二RTP报文标识不同;
第一通讯设备用第一RTP报文标识标记第一通话的RTP报文,用第二RTP报文标识标记第二通话的RTP报文,并将经过标记的第一通话的RTP报文和第二通话的RTP报文合并成具有一个头部信息的复合RTP报文后,发送至第二通讯设备;
第二通讯设备根据第一通讯设备通知的第一RTP报文标识和第一通话的对应关系以及第二RTP报文标识和第二通话的对应关系,区别出所接收的复合RTP报文中的不同通话的RTP报文。
本发明还公开了一种传输RTP报文的通讯设备,该通讯设备包括:分配模块和合并模块,其中,
分配模块,用于为自身所在通讯设备和对端通讯设备之间的第一通话分配第一RTP报文标识、为第二通话分配第二RTP报文标识,并将第一RTP报文标识和第一通话的对应关系以及第二RTP报文标识和第二通话的对应关系通知对端通讯设备和合并模块;其中,第一RTP报文标识和第二RTP报文标识不相同;
合并模块,用于利用第一RTP报文标识标记第一通话的RTP报文,利用第二RTP报文标识标记第二通话的RTP报文,并将经过标记的第一通话的RTP报文和第二通话的RTP报文合并成具有一个头部信息的复合RTP报文后,发送至对端通讯设备。
由上述技术方案可见,本发明这种将两个通讯设备之间的多路通话的RTP报文合并成具有一个头部信息的复合RTP报文在所述两个通讯设备之间进行传输的技术方案,不仅提高了传输RTP报文过程中的语音信息静负荷带宽利用率,还节省了端口资源。
附图说明
图1是现有技术中的VoIP系统组网示意图;
图2是现有技术在VoIP系统中建立通话时的媒体协商流程图;
图3是现有技术中的RTP报文的格式示意图;
图4是本发明实施例一种传输RTP报文的方法的流程图;
图5是本发明实施例的场景示意图;
图6是本发明实施例中1号线建立通话后的复合RTP报文的格式示意图,包括图6(a)和图6(b);
图7是本发明实施例中2号线建立通话后的复合RTP报文的格式示意图,包括图7(a)和图7(b);
图8是本发明实施例一种传输RTP报文的网关的内部结构和外部连接示意图。
具体实施方式
在本发明实施例中,通过媒体协商将两个VoIP网关之间多路通话的RTP报文合并成一个复合RTP报文进行传输,提高了RTP报文中媒体数据所占的比重,同时又不增加延时。
图4是本发明实施例一种传输RTP报文的方法的流程图。如图4所示包括以下步骤:
步骤401,第一通讯设备为第一通话分配第一RTP报文标识,为第二通话分配第二RTP报文标识,并将第一RTP报文标识和第一通话的对应关系以及第二RTP报文标识和第二通话的对应关系通知第二通讯设备;其中,所述第一通话和第二通话均为第一通讯设备和第二通讯设备之间的通话,且第一RTP报文标识和第二RTP报文标识不同。
步骤402,第一通讯设备用第一RTP报文标识标记第一通话的RTP报文,用第二RTP报文标识标记第二通话的RTP报文,并将经过标记的第一通话的RTP报文和第二通话的RTP报文合并成具有一个头部信息的复合RTP报文后,发送至第二通讯设备。
步骤403,第二通讯设备根据第一通讯设备通知的RTP报文标识和各路通话之间的对应关系,区别出所接收的复合RTP报文中的不同通话的RTP报文。
上述流程中,将两路通话的RTP报文合并成具有一个头部信息的复合RTP报文后,复合RTP报文中头部信息所占的比重非常小,因此提高了传输RTP报文过程中的语音信息静负荷带宽利用率。另外,复合RTP报文的传输只需要一对端口,这相对于现有技术中每一路通话占用一对端口的方案,还节省了端口资源。
为使本发明的目的、技术方案及优点更加清楚明白,以下例举较佳实施例,对本发明进一步详细说明。
图5是本发明实施例的场景示意图。如图5所示,A、B两地通过VoIPGW-A和VoIP GW-B相连,VoIP GW-A的IP地址为192.168.1.1,VoIP GW-B的IP地址为192.168.1.2,且VoIP GW-A和VoIP GW-B之间有三路通话,分别是:
82770001与68120001通话    1号线
82770002与68120002通话    2号线
82770003与68120003通话    3号线
在图5所示的场景中通讯设备是VoIP网关。
在本发明实施例中,利用SDP的属性域标识同一个端口号上被复用的RTP报文,即SDP的属性域的不同值标识一个复合RTP报文中包含的不同RTP报文。SDP的属性域的格式为“a=<attribute>:<value>”,按照属性域格式在本发明实施例中添加这样一个属性:
a=mutilrtp:rtp-identification
其中,mutilrtp是该属性域的名称;rtp-identification该属性域的值,是一个数字标识,取值范围为0~255,用于标识同一个端口号上被复用的各RTP报文。
下面基于图5,以发起通话的VoIP GW-A是否知道上述三路通话的对端网关为同一个网关为例,分为两种情况来介绍本发明的技术方案。
方案一:VoIP GW-A已知上述三路通话的对端网关为同一个网关VoIPGW-B,且已知VoIP GW-B支持RTP的复合,这可以通过配置实现。
假设1号线先开始通话,则VoIP GW-A和VoIP GW-B的媒体协商流程图同图2中所示,VoIP GW-A和VoIP GW-B分别为1号线通话分配端口号和RTP报文标识,并通过媒体协商过程中的媒体协商消息告知对方,其中,各个媒体协商消息的SDP部分如下:
①Invite的SDP部分:
v=0
o=Quidway 1073741840 1073741840 IN IP4 100.1.1.56
s=Sip Call
c=IN IP4 100.1.1.56
t=00
a=mutilrtp:1
m=audio 16400RTP/AVP 18 8 0 4
a=rtpmap:18G729/8000
a=rtpmap:8PCMA/8000
a=rtpmap:0PCMU/8000
a=rtpmap:4G723/8000
②180Ring的SDP部分:
v=0
o=Quidway 1073741846 1073741846 IN IP4 100.1.1.6
s=Sip Call
c=IN IP4 100.1.1.6
t=00
a=mutilrtp:50
m=audio 16400RTP/AVP 18
a=rtpmap:18G729/8000
③200Ok的SDP部分:
v=0
o=Quidway 1073741848 1073741848 IN IP4 100.1.1.6
s=Sip Call
c=IN IP4 100.1.1.6
t=00
a=mutilrtp:50
m=audio 16400RTP/AVP 18
a=rtpmap:18G729/8000
④Ack无SDP部分
其中,VoIP GW-A向VoIP GW-B发送的“Invite”消息中的属性域为:“a=mutilrtp:1”,并且m=audio 16400RTP/AVP 18 8 0 4,即表示要在编号为16400的端口上进行RTP复用,且当前用户的RTP报文,即1号线的终端82770001的RTP报文在VoIP GW-A发送给VoIP GW-B的复合RTP报文中用“1”标识。而VoIP GW-B向VoIP GW-A发送的“180Ring”和“200OK”消息中的属性域为:“a=mutilrtp:50”,并且m=audio 16400RTP/AVP 18,表示要在编号为16400的端口上进行RTP复用,且当前用户的RTP报文,即1号线的终端68120001的RTP报文在VoIP GW-B发送给VoIP GW-A的复合RTP报文中用“50”标识。
这样,1号线的通话建立后,VoIP GW-A发送给VoIP GW-B的复合RTP报文以及VoIP GW-B发送给VoIP GW-A的复合RTP报文分别如图6(a)和图6(b)所示。
图6所示的复合RTP报文包括:以太网首部、IP首部、UDP首部和RTP首部等头部信息外,还包括:预定长度的1号线路的RTP报文标识,预定长度的1号线路媒体数据长度和x1字节的1号线路的媒体数据。在本实施例中取上述预定长度为1个字节,即一个字节的1号线路的RTP报文标识和一个字节的1号线路媒体数据长度。此时,在复合RTP报文中加入“数据长度”的数据结构是因为当复合RTP报文复合了多路RTP报文时,可以根据各路RTP报文的数据长度,确定各路RTP报文的起始位置。
接着2号线开始通话,VoIP GW-A和VoIP GW-B的媒体协商流程同图2中所示,VoIP GW-A和VoIP GW-B分别为2号线通话分配端口号和RTP报文标识,并通过媒体协商过程中的媒体协商消息告知对方,其中各个媒体协商消息的SDP部分如下
①Invite的SDP部分
v=0
o=Quidway 1073741840 1073741840 IN IP4 100.1.1.56
s=Sip Call
c=IN IP4 100.1.1.56
t=00
a=mutilrtp:2
m=audio 16400RTP/AVP 18 8 0 4
a=rtpmap:18G729/8000
a=rtpmap:8PCMA/8000
a=rtpmap:0PCMU/8000
a=rtpmap:4G723/8000
②180Ring的SDP部分
v=0
o=Quidway 1073741846 1073741846 IN IP4 100.1.1.6
s=Sip Call
c=IN IP4 100.1.1.6
t=00
a=mutilrtp:51
m=audio 16400RTP/AVP 18
a=rtpmap:18G729/8000
③200Ok的SDP部分
v=0
o=Quidway 1073741848 1073741848 IN IP4 100.1.1.6
s=Sip Call
c=IN IP4 100.1.1.6
t=00
a=mutilrtp:51
m=audio 16400RTP/AVP 18
a=rtpmap:18G729/8000
④Ack无SDP部分
其中,VoIP GW-A向VoIP GW-B发送的“Invite”消息中的属性域为:“a=mutilrtp:2”,并且m=audio 16400RTP/AVP 18 8 0 4,表示要在编号为16400的端口上进行RTP复用,且当前用户的RTP报文,即2号线终端82770002的RTP报文在VoIP GW-A发送给VoIP GW-B的复合RTP报文中用“2”标识。而VoIP GW-B向VoIP GW-A发送的“180Ring”和“200OK”消息中的属性域为:“a=mutilrtp:51”,并且m=audio 16400RTP/AVP 18,表示要在编号为16400的端口上进行RTP复用,且当前用户的RTP报文,即2号线终端68120002的RTP报文在VoIP GW-B发送给VoIP GW-A的复合RTP报文中用“51”标识。
这样,2号线的通话建立后,VoIP GW-A发送给VoIP GW-B的复合RTP报文以及VoIP GW-B发送给VoIP GW-A的复合RTP报文分别如图7(a)和图7(b)所示。
图7所示的复合RTP报文包括:以太网首部、IP首部、UDP首部和RTP首部等头部信息外,还包括:一个字节的1号线路的RTP报文标识,一个字节的1号线路媒体数据长度、x1字节的1号线路的媒体数据、一个字节的2号线路的RTP报文标识,一个字节的2号线路媒体数据长度和x2字节的2号线路的媒体数据。
接着3号线开始通话,其协商过程如2号线的协商过程,只是“Invite”消息中的属性域为:“a=mutilrtp:3”,而“180Ring”和“200OK”消息中的属性域为:“a=mutilrtp:52”。3号线通话建立后,复合RTP包文中添加了3号线的RTP报文。需要复合更多条线路的情况以此类推。
VoIP GW-A和VoIP GW-B根据所接收的复合RTP报文中的RTP报文标识区分不同线路的数据,并发送给相应的终端。
需要说明的是,VoIP GW-A和VoIP GW-B可以为同一路通话分配相同的RTP报文标识。例如,在上述实施例中,VoIP GW-A为1号线的通话分配RTP报文标识“1”时,VoIP GW-B也可以为1号线的通话分配RTP报文标识“1”。
方案二:VoIP GW-A不知道上述三路通话的对端网关为同一个网关VoIP GW-B。
仍假设1号线先开始通话,则VoIP GW-A和VoIP GW-B的媒体协商流程同图2中所示,VoIP GW-A和VoIP GW-B分别为1号线通话分配端口号和RTP报文标识,并通过媒体协商过程中的媒体协商消息告知对方,其中,各个媒体协商消息的SDP部分如下:
①Invite的SDP部分:
v=0
o=Quidway 1073741840 1073741840 IN IP4 100.1.1.56
s=Sip Call
c=IN IP4 100.1.1.56
t=00
a=mutilrtp:1
m=audio 16400RTP/AVP 18 8 0 4
a=rtpmap:18G729/8000
a=rtpmap:8PCMA/8000
a=rtpmap:0PCMU/8000
a=rtpmap:4G723/8000
②180Ring的SDP部分:
v=0
o=Quidway 1073741846 1073741846 IN IP4 100.1.1.6
s=Sip Call
c=IN IP4 100.1.1.6
t=00
a=mutilrtp:50
m=audio 16400RTP/AVP 18
a=rtpmap:18G729/8000
③200Ok的SDP部分:
v=0
o=Quidway 1073741848 1073741848 IN IP4 100.1.1.6
s=Sip Call
c=IN IP4100.1.1.6
t=00
a=mutilrtp:50
m=audio 16400RTP/AV P 18
a=rtpmap:18G729/8000
④Ack无SDP部分
其中,VoIP GW-A发送的“Invite”消息中的属性域为:“a=mutilrtp:1”,表示要在编号为16400的端口上进行RTP复用,且当前用户的RTP报文,即终端82770001的RTP报文在VoIP GW-A发送的复合RTP报文中用“1”标识。如果对方VoIP GW,即VoIP GW-B支持RTP复用,则VoIP GW-B向VoIP GW-A发送的“180Ring”和“200OK”消息中的属性域为:“a=mutilrtp:50”,表示要在编号为16400的端口上进行RTP复用,且当前用户的RTP报文,即终端68120001的RTP报文在VoIP GW-B发送给VoIPGW-A的复合RTP报文中用“50”标识。如果VoIP GW-B不支持RTP复用,则VoIP GW-B向VoIP GW-A发送的“180Ring”和“200OK”消息中不添加属性域“a=mutilrtp:rtp-identification”,则进入普通的RTP互通,即进入现有技术中的每一路通话的RTP报文通过一对端口单独进行传输的过程。
这样,1号线的通话建立后,VoIP GW-A发送给VoIP GW-B的复合RTP报文以及VoIP GW-B发送给VoIP GW-A的复合RTP报文分别如图6(a)和图6(b)所示。
接着2号线开始通话,VoIP GW-A和VoIP GW-B的媒体协商流程同图2中所示,其各个消息的SDP部分如下
①Invite的SDP
v=0
o=Quidway 1073741840 1073741840 IN IP4 100.1.1.56
s=Sip Call
c=IN IP4 100.1.1.56
t=00
a=mutilrtp:2
m=audio 16402RTP/AVP 18 8 0 4
a=rtpmap:18G729/8000
a=rtpmap:8PCMA/8000
a=rtpmap:0PCMU/8000
a=rtpmap:4G723/8000
②180Ring的SDP部分
v=0
o=Quidway 1073741846 1073741846 IN IP4 100.1.1.6
s=Sip Call
c=IN IP4 100.1.1.6
t=00
a=mutilrtp:51
m=audio 16400RTP/AVP 18
a=rtpmap:18G729/8000
③200Ok
v=0
o=Quidway 1073741848 1073741848 IN IP4 100.1.1.6
s=Sip Call
c=IN IP4 100.1.1.6
t=00
a=mutilrtp:51
m=audio 16400RTP/AVP 18
a=rtpmap:18G729/8000
④Ack
v=0
o=Quidway 1073741840 1073741840 IN IP4 100.1.1.56
s=Sip Call
c=IN IP4 100.1.1.56
t=00
a=mutilrtp:2
m=audio 16400RTP/AVP 18804
a=rtpmap:18G729/8000
其中,由于VoIP GW-A不知道当前通话,即2号线的对方VoIP网关是VoIP GW-B,也不知道对方VoIP网关是否支持RTP复用,因此,VoIP GW-A发送的“Invite”消息中的属性域为:“a=mutilrtp:2”,但本段端口号是16402,表示要在编号为16402的端口上进行RTP复用,且当前用户的RTP报文,即终端82770002的RTP报文在VoIP GW-A发送的复合RTP报文中用“2”标识。
在本实施例中,2号线的对方VoIP GW仍为VoIP GW-B,因此VoIPGW-B接收到Invite消息后,从其中的IP地址获知对方仍为1号线路的VoIPGW-A,可以进行RTP复用,因此,VoIP GW-B向VoIP GW-A发送的“180Ring”和“200OK”消息中的属性域为:“a=mutilrtp:51”,端口号为16400,表示要在编号为16400的端口上进行RTP复用,且当前用户的RTP报文,即终端68120002的RTP报文在VoIP GW-B发送给VoIP GW-A的复合RTP报文中用“51”标识。如果接收到“Invite”消息的VoIP GW不是VoIP GW-B,且该VoIP GW不支持RTP复用,则该VoIP GW向VoIP GW-A发送的“180Ring”和“200OK”消息中不添加属性域“a=mutilrtp:rtp-identification”,则进入现有技术中的每一路通话的RTP报文通过一对端口单独进行传输的过程。
VoIP GW-A接收到“180Ring”和“200OK”消息后,从其中的IP地址获知对方仍为1号线路的VoIP GW-B,可以进行RTP复用,则VoIP GW-A向VoIP GW-B发送的“ACK”消息中添加属性域“a=mutilrtp:2”,且将端口号更改为1号线所用的端口16400,表示要在编号为16400的端口上对1号线和2号线的RTP报文进行复合。
这样,2号线的通话建立后,VoIP GW-A发送给VoIP GW-B的复合RTP报文以及VoIP GW-B发送给VoIP GW-A的复合RTP报文分别如图7(a)和图7(b)所示。
3号线的通话建立过程同2号线的通话建立过程,更多线路的通话建立过程以此类推。
VoIP GW-A和VoIP GW-B根据所接收的复合RTP报文中的RTP报文标识区分不同线路的数据,并发送给相应的终端。
通过上述两种方案可以在两个网关之间有多路通话时,实现RTP复用。
在上述两种方案中,当需要拆线时,即有线路结束通话时,不需要进行SDP媒体协商,只要通话双方所接入的VoIP网关在发送的复合RTP报文中删除该线路的相应数据即可,如,删除该线路的RTP报文标识,数据长度标识,和媒体数据;如果整个复合RTP只有一路通话,且该通话也结束时,删除整个复合RTP即可。
这样便实现了1、2、3号线的RTP报文在VoIP GW-A和VoIP GW-B之间的一对端口上的复用,不仅提高了带宽的利用率,且节省了网关上的端口资源。
前面提到过,在现有技术中,当使用G.729编码格式时,一个RTP报文包含54字节的头部信息和30字节的媒体数据,因此一个RTP报文共有54+30=84字节,那么当每一路通话的每一端每20毫秒发送一个RTP报文,即每秒发送50个RTP报文时,由于每个字节包含8个比特,因此每一路通话的带宽为:84×50×8=33600bit/s。则3路通话的带宽是3×33600=100800bit/s。而使用本发明实施例中的复合RTP方案后,3路通话的复合RT报文中包括54字节的头部信息,以及每路通话的30字节数据、1个字节的RTP报文标识和1个字节的数据长度标识,则3路通话的带宽是:
(54+3×(30+1+1))×50×8=60000bit/s
可见采用本发明的技术方案后可节约(100800-60000)/100800=59%的带宽。并且复合的通话路数越多,所节省的带宽的比例越高。
另外,在现有技术中每路通话占用不同的端口对,而在本发明中,将多路通话的RTP报文合并后通过一对端口传输的方案,可以节省端口资源。
基于上述实施例,下面给出本发明一种传输RTP报文的通讯设备的结构示意图。
图8是本发明实施例一种传输RTP报文的通讯设备的内部结构和外部连接示意图。如图8所示,该通讯设备包括:分配模块801和合并模块802,其中:
分配模块801,用于为自身所在通讯设备和对端通讯设备之间的第一通话分配第一RTP报文标识、为第二通话分配第二RTP报文标识,并将第一RTP报文标识和第一通话的对应关系以及第二RTP报文标识和第二通话的对应关系通知对端通讯设备和合并模块802;其中,第一RTP报文标识和第二RTP报文标识不相同;
合并模块802,用于利用第一RTP报文标识标记第一通话的RTP报文,利用第二RTP报文标识标记第二通话的RTP报文,并将经过标记的第一通话的RTP报文和第二通话的RTP报文合并成具有一个头部信息的复合RTP报文后,发送至对端通讯设备。
在图8中,分配模块801,进一步用于接收对端通讯设备发送的包含第三RTP报文标识和第一通话的对应关系以及第四RTP报文标识和第二通话的对应关系的通知,并将该通知发送给自身所在通讯设备和对端通讯设备之间的P报文,并根据分配模块801所发送的通知内容,区别出所接收的复合RTP报文中的不同通话的RTP报文。
在图8中,合并模块801,在将经过标记的第一通话的RTP报文和第二通话的RTP报文合并成具有一个头部信息的复合RTP报文时,还可以进一步用于在复合RTP报文中标记所合并的每个RTP报文的数据长度。
图8中的通讯设备可以是VoIP网关。
综上所述,本发明实施例这种将两个通讯设备之间的多路通话的RTP报文合并成具有一个头部信息的复合RTP报文在所述两个通讯设备的一对端口之间进行传输的技术方案,不仅提高了传输RTP报文过程中的语音信息静负荷带宽利用率,还节省了端口资源。
以上所述,仅为本发明的较佳实施例而已,并非用于限定本发明的保护范围,凡在本发明的精神和原则之内所做的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。

Claims (11)

1、一种传输实时传输协议RTP报文的方法,其特征在于,该方法包括:
第一通讯设备为第一通话分配第一RTP报文标识,为第二通话分配第二RTP报文标识,并将第一RTP报文标识和第一通话的对应关系以及第二RTP报文标识和第二通话的对应关系通知第二通讯设备;其中,所述第一通话和第二通话均为第一通讯设备和第二通讯设备之间的通话,且第一RTP报文标识和第二RTP报文标识不同;
第一通讯设备用第一RTP报文标识标记第一通话的RTP报文,用第二RTP报文标识标记第二通话的RTP报文,并将经过标记的第一通话的RTP报文和第二通话的RTP报文合并成具有一个头部信息的复合RTP报文后,发送至第二通讯设备;
第二通讯设备根据第一通讯设备通知的第一RTP报文标识和第一通话的对应关系以及第二RTP报文标识和第二通话的对应关系,区别出所接收的复合RTP报文中的不同通话的RTP报文。
2、如权利要求1所述的方法,其特征在于,该方法进一步包括:
第二通讯设备为第一通话分配第三RTP报文标识,为第二通话分配第四RTP报文标识,并将第三RTP报文标识和第一通话的对应关系以及第四RTP报文标识和第二通话的对应关系通知第一通讯设备;其中,第三RTP报文标识和第四RTP报文标识不同;
第二通讯设备用第三RTP报文标识标记第一通话的RTP报文,用第四RTP报文标识标记第二通话的RTP报文,并将经过标记的第一通话的RTP报文和第二通话的RTP报文合并成具有一个头部信息的复合RTP报文后,发送至第一通讯设备;
第一通讯设备根据第二通讯设备通知的第三RTP报文标识和第一通话的对应关系以及第四RTP报文标识和第二通话的对应关系,区别出所接收的复合RTP报文中的不同通话的RTP报文。
3、如权利要求2所述的方法,其特征在于,
所述第一通讯设备将第一RTP报文标识和第一通话的对应关系通知第二通讯设备包括:第一通讯设备在第一通话的媒体协商过程中将第一RTP报文标识发送给第二通讯设备;
所述第二通讯设备将第三RTP报文标识和第一通话的对应关系通知第一通讯设备包括:第二通讯设备在第一通话的媒体协商过程中将第三RTP报文标识发送给第一通讯设备;
所述第一通讯设备将第二RTP报文标识和第二通话的对应关系通知第二通讯设备包括:第一通讯设备在第二通话的媒体协商过程中将第二RTP报文标识发送给第二通讯设备;
所述第二通讯设备将第四RTP报文标识和第二通话的对应关系通知第一通讯设备包括:第二通讯设备在第二通话的媒体协商过程中将第四RTP报文标识发送给第一通讯设备。
4、如权利要求3所述的方法,其特征在于,
所述第一通讯设备在第一通话的媒体协商过程中将第一RTP报文标识发送给第二通讯设备包括:在第一通话的媒体协商过程中,第一通讯设备将第一RTP报文标识设置在Invite消息的会话描述协议SDP部分的属性域中,并发送该Invite消息至第二通讯设备;
所述第二通讯设备在第一通话的媒体协商过程中将第三RTP报文标识发送给第一通讯设备包括:在第一通话的媒体协商过程中,第二通讯设备将第三RTP报文标识设置在180Ring和/或200OK消息的SDP部分的属性域中,并发送该180Ring和/或200OK消息至第一通讯设备;
所述第一通讯设备在第二通话的媒体协商过程中将第二RTP报文标识发送给第二通讯设备包括:在第二通话的媒体协商过程中,第一通讯设备将第二RTP报文标识设置在Invite消息的SDP部分的属性域中,并发送该Invite消息至第二通讯设备;
所述第二通讯设备在第二通话的媒体协商过程中将第四RTP报文标识发送给第一通讯设备包括:在第二通话的媒体协商过程中,第二通讯设备将第四RTP报文标识设置在180Ring和/或200OK消息的SDP部分的属性域中,并发送该180Ring和/或200OK消息至第一通讯设备。
5、如权利要求2所述的方法,其特征在于,当第一通讯设备和第二通讯设备之间建立第一通话后,由第一通讯设备发起第二通话时,该方法进一步包括:第一通讯设备根据第二通话的媒体协商过程确定第二通话的对端通讯设备是第二通讯设备。
6、如权利要求5所述的方法,其特征在于,所述第一通讯设备根据第二通话的媒体协商过程确定第二通话的对端通讯设备是第二通讯设备包括:
第一通讯设备为第二通话分配端口,该端口不同于发送第一通话的RTP报文的端口,并将所分配端口的端口号通过携带自身地址的Invite消息发送出去;
第二通讯设备根据所接收的Invite消息中的地址判断出是第一通讯设备发送的之后,为第二通话分配第一通话所用的端口,并将所分配端口的端口号通过携带自身地址的180Ring和/或200OK消息发送给第一通讯设备;
第一通讯设备根据所接收的180Ring和/或200OK消息中的地址判断出对端通讯设备是第二通讯设备,将第二通话所用的端口更改为第一通话所用的端口,并将该端口的端口号通过ACK消息发送给第二通讯设备。
7、如权利要求1所述的方法,其特征在于,第一通讯设备将经过标记的第一通话的RTP报文和第二通话的RTP报文合并成具有一个头部信息的复合RTP报文时,该方法进一步包括:在复合RTP报文中还标记所合并的每个RTP报文的数据长度。
8、如权利要求2至7中任一项所述的方法,其特征在于,该方法进一步包括:当第一通话和第二通话中的任一路通话结束时,第一通讯设备和第二通讯设备从各自发送给对方的复合RTP报文中删除已结束的通话的相应信息。
9、一种传输RTP报文的通讯设备,其特征在于,该通讯设备包括:分配模块和合并模块,其中,
分配模块,用于为自身所在通讯设备和对端通讯设备之间的第一通话分配第一RTP报文标识、为第二通话分配第二RTP报文标识,并将第一RTP报文标识和第一通话的对应关系以及第二RTP报文标识和第二通话的对应关系通知对端通讯设备和合并模块;其中,第一RTP报文标识和第二RTP报文标识不相同;
合并模块,用于利用第一RTP报文标识标记第一通话的RTP报文,利用第二RTP报文标识标记第二通话的RTP报文,并将经过标记的第一通话的RTP报文和第二通话的RTP报文合并成具有一个头部信息的复合RTP报文后,发送至对端通讯设备。
10、如权利要求9所述的通讯设备,其特征在于,
所述分配模块,进一步用于接收对端通讯设备发送的包含第三RTP报文标识和第一通话的对应关系以及第四RTP报文标识和第二通话的对应关系的通知,并将该通知发送给合并模块;
所述合并模块,进一步用于接收对端通讯设备发送的复合RTP报文,并根据分配模块所发送的通知内容,区别出所接收的复合RTP报文中的不同通话的RTP报文。
11、如权利要求9所述的通讯设备,其特征在于,
所述合并模块,在将经过标记的第一通话的RTP报文和第二通话的RTP报文合并成具有一个头部信息的复合RTP报文时,进一步用于在复合RTP报文中标记所合并的每个RTP报文的数据长度。
CN200710121887A 2007-09-17 2007-09-17 传输实时传输协议报文的方法和通讯设备 Active CN100586107C (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN200710121887A CN100586107C (zh) 2007-09-17 2007-09-17 传输实时传输协议报文的方法和通讯设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN200710121887A CN100586107C (zh) 2007-09-17 2007-09-17 传输实时传输协议报文的方法和通讯设备

Publications (2)

Publication Number Publication Date
CN101132366A CN101132366A (zh) 2008-02-27
CN100586107C true CN100586107C (zh) 2010-01-27

Family

ID=39129495

Family Applications (1)

Application Number Title Priority Date Filing Date
CN200710121887A Active CN100586107C (zh) 2007-09-17 2007-09-17 传输实时传输协议报文的方法和通讯设备

Country Status (1)

Country Link
CN (1) CN100586107C (zh)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101252534B (zh) * 2008-03-28 2010-06-02 清华大学 通过链路层报文合并提高移动自组织网络通信容量的方法
EP2785001B1 (en) 2013-03-27 2017-09-27 Unify GmbH & Co. KG Method of negotiation of media between a source communication device and a destination communication device for multiplexing multiple media types on an IP transport address, a computer program product for executing the method, and a source communication device for negotiating of the media between the source communication device and a destination communication device
CN104836811A (zh) * 2015-05-26 2015-08-12 武汉兴图新科电子股份有限公司 一种保持传输数据完整的通信端口复用方法
CN104994035B (zh) * 2015-07-13 2018-06-12 宁波尚为信息技术有限公司 一种基于北斗短报文通信的数据传输方法
CN110572708A (zh) * 2019-09-16 2019-12-13 武汉兴图新科电子股份有限公司 一种高性能接收rtp复用流的方法

Also Published As

Publication number Publication date
CN101132366A (zh) 2008-02-27

Similar Documents

Publication Publication Date Title
CN1685691B (zh) 在媒体网关控制器之间传输呼叫控制参数的方法
EP1192773B1 (en) Method and system for exchanging information between multimedia network nodes
US20080312923A1 (en) Active Speaker Identification
CN100574467C (zh) 一种带宽控制方法和终端设备
CN104506523B (zh) 一种智能终端VoIP的呼叫转接方法
EP2130346B1 (en) Media stream setup in a group communication system
CN100586107C (zh) 传输实时传输协议报文的方法和通讯设备
US20050047423A1 (en) Protocol interworking framework
CN102547416A (zh) 一种手机与电视分载媒体的方法
CN109889534B (zh) 一种融合IP网络与LTE网络的VoIP通话方法
CN101257435B (zh) 基于nat-pt的sip应用层网关的实现方法
CN100583814C (zh) 一种实现多媒体业务nat穿越的方法
CN104660546B (zh) 一种基于ssrc的收发rtp包的方法
CN101360057B (zh) 一种路由处理的方法、ims业务处理的方法及相关设备
CN102801725B (zh) Sip音视频会议中进行音视频媒体传输的方法
CN102271137A (zh) 一种媒体服务器
CN101867575B (zh) 一种跨网元的媒体发夹连接方法和系统
US20060062251A1 (en) Session data and setting method thereof in a sychronous wireless communication system
CN101150538A (zh) 一种收发即时多媒体信息的方法和装置
WO2009036801A1 (en) Methods and arrangements for a telecommunications system
CN101064680B (zh) 一种实现多媒体呼叫业务的方法、系统及装置
CN101119212B (zh) 通过信令适配实体传输isdn用户-用户应用信息的方法
CN100571189C (zh) 在网络中实现设备间通讯的方法
CN100499720C (zh) 一种提供多速率数据信息承载业务的实现方法
CN101258717B (zh) 媒体网关系统与实现媒体网关内部呼叫的方法

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
CP03 Change of name, title or address
CP03 Change of name, title or address

Address after: 310052 Binjiang District Changhe Road, Zhejiang, China, No. 466, No.

Patentee after: Xinhua three Technology Co., Ltd.

Address before: 310053 Hangzhou hi tech Industrial Development Zone, Zhejiang province science and Technology Industrial Park, No. 310 and No. six road, HUAWEI, Hangzhou production base

Patentee before: Huasan Communication Technology Co., Ltd.