CN100589484C - 媒体网关控制协议的承载***及其方法 - Google Patents
媒体网关控制协议的承载***及其方法 Download PDFInfo
- Publication number
- CN100589484C CN100589484C CN200510110889A CN200510110889A CN100589484C CN 100589484 C CN100589484 C CN 100589484C CN 200510110889 A CN200510110889 A CN 200510110889A CN 200510110889 A CN200510110889 A CN 200510110889A CN 100589484 C CN100589484 C CN 100589484C
- Authority
- CN
- China
- Prior art keywords
- media gateway
- transmission link
- mgcp
- mgc
- transmission
- 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
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明涉及通信协议的承载技术,公开了一种媒体网关控制协议的承载***及其方法,使得MGC和MGW间控制协议的承载实现更加可靠。本发明中,通过增加MGC和MGW之间的多IP地址通信的功能,可以在MGC和MGW间建立多条UDP或TCP传输链路承载媒体网关控制协议,如果一条TCP或UDP传输链路上发送的消息在预定时长内没有得到响应,则通过另一条TCP或UDP传输链路再次发送。此外还可以在各条TCP或UDP传输链路之间实现负荷分担。
Description
技术领域
本发明涉及通信协议的承载技术,特别涉及承载与控制分离的网络中通信协议的承载技术。
背景技术
随着通信技术的发展,通信网络也在向下一代网络(Next GenerationNetwork,简称“NGN”)迅速演进,其中,交换技术发展的趋势是业务控制和承载媒体相分离。通过业务控制和承载媒体的分离,用户可以自行配置和定义自己的业务特征而不必关心承载业务的网络形式以及终端类型,使得业务和应用的提供有较大的灵活性,从而满足用户不断发展更新的业务需求,也使得网络具备了可扩展性和快速部署新业务的能力,使网络运营商更具竞争力。
为了实现业务控制和承载媒体的分离,传统的交换机被划分为媒体网关控制器(Media Gateway Controller,简称“MGC”)和媒体网关(Media GateWay,简称“MGW”)两部分。其中,MGC用于实现呼叫状态的管理,以及对MGW承载资源的控制;MGW用于完成具体媒体流的建立、修改、释放和资源管理,可以将一种类型的网络中的媒体流转换为另一种网络所要求的格式,例如将电路交换网中的E1时隙转换为网间互联协议(Internet Protocol,简称“IP”)网络中的实时传输协议(Real-Time Transfer Protocol,简称“RTP”)流。
MGC和MGW之间可以使用H.248协议作为控制协议。其中,H.248协议由国际电信联盟-电信标准部(International Telecommunication UnionTelecommunication Standardization Sector,简称“ITU-T”)和互联网工程任务组(Internet Engineering Tast Force,简称“IETF”)共同制定,是一种承载控制协议,通常承载在异步传输模式(Asynchronous Transfer Mode,简称“ATM”)或IP网络上。当承载在ATM网络上时,H.248可以使用消息传输部分层3(宽带)(Message Transfer Part layer 3(broadband),简称“MTP3B”)、特定服务的面向连接协议(Service Specific Connection OrientedProtocol,简称“SSCOP”)/ATM适配层类型5(ATM Adaptation Layer type5,简称“AAL5”)、ALF/ALL5等协议作为底层信令承载;当承载在IP网络上时,H.248可以使用传输控制协议(Transfer Control Protocol,简称“TCP”)、用户数据报协议(User Datagram Protocol,简称“UDP”)、流控制传输协议(Stream Control Transmission Protocol,简称“SCTP”)等协议作为底层信令承载。
根据H.248.1协议,需要向MGW提供一个主MGC的名称或者地址,例如域名服务***(DOMAIN NAME SYSTEM,简称“DNS”)名称或者IP地址,此外,作为可选项,还可以向MGW提供零个或多个备用MGC的名字或者地址。MGW将向指定的MGC发送消息,MGC可从MGW的注册消息(Service Change)中获得MGW的地址。
IP网络作为承载网的传输成本最低,因此在实际组网中也使用得最多。在IP网络中,应用最普遍的传输层协议是面向连接的TCP协议和面向无连接的UDP协议。
当使用TCP作为H.248的传输层协议时,由于TCP是面向连接的协议,必须在MGC与MGW之间建立TCP连接,套接字(socket)编程接口要求使用TCP进行通信的双方,能够知道对方的IP地址和端口号,而通信也只能在四元组所标识的TCP连接中进行。其中,四元组为源IP地址、源端口号、目标IP地址、目标端口号。
TCP连接的典型建立过程是:MGC作为服务(Server)端在指定的IP地址和端口上进行监听(Listen);MGW根据自己的配置数据,选择本端的IP地址和端口号,向这个MGC监听地址发出TCP连接请求(Connect);MGC决定接受这个请求(Accept),向发送TCP连接请求的MGW的IP地址和端口号发出应答;MGW确认这个应答,TCP的三次握手完成,TCP连接建立。随后双方即可开始通信,MGW在这个连接上发出注册消息(ServiceChange)。
由于TCP是可靠传输协议,传送的信息必须得到对方的确认,如果超时得不到确认,就会重发这些信息。这样就造成一个问题,如果承载网质量不好,丢包严重,TCP连接的吞吐量和响应时间将迅速恶化。标准TCP实现是以往返时间来计算包的重传间隔的,并遵循指数退避的重传原则,即随着重传次数的增加,重传时间间隔越来越长。一个典型的TCP重传序列是:第一次重传发生在无应答帧的1.5秒后,以后的间隔是3秒、6秒、12秒、24秒、48秒、多个64秒,其中,64秒是最大重传间隔。从第1次重传到TCP放弃重传而中断连接,大约需要9分钟。此外,由于TCP协议是流传输协议,所有的包最后都被映射成TCP连接上无边界的流,前一个包无法传输成功,将导致后续的包都无法传输成功。TCP的这种特性对于因特网(Internet)浏览服务是适合的,但是对于负责呼叫信令控制的H.248来说,其实时性要求远远无法得到满足。
当使用UDP作为H.248的传输层协议时,由于UDP是无连接协议,因此MGC与MGW之间不必显式建立连接,只需要知道对方的IP地址和端口号,即可随时向对方发送信息。
但是由于UDP是不可靠传输协议,其面向无连接的特性也使得发送方无法获知对方的状态,即使对方宕机,也只能在多次重传失败后,推测对方已不可达。因此对于负责呼叫信令控制的H.248来说,其实时性要求也是无法得到满足的。
从通信设备本身的可靠性来说,采用分布式处理、将同一功能分配在多个负荷分担的实体上,有助于增强***的可靠性。例如使用多个IP通信接口板,分别拥有各自的IP地址,则一个通信接口板发生故障时,不致引起整个***对外通信的中断。这就要求在MGC和MGW之间支持多IP地址的通信。
对于多IP地址的通信,现有技术方案使用SCTP作为H.248的传输层协议。
SCTP协议允许在源端的多个IP地址(使用1个端口号),与目标端的多个IP地址(使用1个端口号)之间建立SCTP连接。当承载网络质量恶化,发生丢包时,SCTP会自动尝试备选的IP地址,这将改变IP包的路由选择策略,从而有可能避开局部的路由器故障,顺利到达目的地。
当H.248承载在SCTP协议上时,可以利用SCTP对多IP地址、端口号的支持,提高H.248信令传输的实时性和可靠性。
在实际应用中,上述方案存在以下问题:现有技术方案的协议实现比较复杂,开销较大,当MGW数量大时***资源无法承受,并且现有技术方案不支持使用MGCP协议作为MGC和MGW间的控制协议。
造成这种情况的主要原因在于,现有技术方案使用的SCTP协议实现和TCP、UDP协议相比更加复杂,协议开销大。而由于MGW的数量可能很大,甚至有可能达到百万以上,这时对于***资源的要求是难以满足的,此外,由于MGCP也可以作为MGC和MGW间的控制协议,而MGCP协议只能承载在UDP协议上,现有技术方案在这种场景下就无法使用。
发明内容
有鉴于此,本发明的主要目的在于提供一种媒体网关控制协议的承载***及其方法,使得MGC和MGW间控制协议的承载实现更简单,更节省开销和***资源,同时还可以支持MGCP协议的承载。
为实现上述目的,本发明提供了一种媒体网关控制协议的承载***,包含媒体网关控制器和归属于该媒体网关控制器的至少一个媒体网关,所述媒体网关控制器和所述媒体网关通过IP协议网络连接,所述媒体网关控制器还包含至少两个具有不同IP协议地址的通信接口,并利用这些通信接口分别和所述媒体网关建立至少两条用于承载所述控制协议的传输链路;
所述媒体网关控制器还用于监测各所述传输链路的状态,在发现传输链路故障时,尝试重建该传输链路,并选择其它状态正常的传输链路,以便传送媒体网关控制协议消息给所述媒体网关。
其中,所述媒体网关还根据***设置为所述媒体网关控制器配置至少两个IP协议地址,和所述媒体网关控制器间建立至少两条传输链路,在收到所述媒体网关控制协议消息时回复响应消息。
此外在所述***中,所述传输链路使用传输控制协议或用户数据报协议。
此外在所述***中,所述传输链路使用传输控制协议时,所述媒体网关控制器根据所述媒体网关的所述响应消息监测所述传输链路的状态,如果在一条传输链路上发送所述媒体网关控制协议消息后,在规定时间内没有收到所述媒体网关的响应消息,则判定该传输链路故障。
此外在所述***中,所述媒体网关控制器根据所述媒体网关的所述响应消息以及和所述媒体网关间的定时握手监测所述传输链路的状态,如果定时握手失败或者在同一传输链路上连续重发所述媒体网关控制协议消息超过门限,则判定该传输链路故障。
此外在所述***中,所述媒体网关控制器还为所述传输链路分配优先级,并优先使用优先级高的可用传输链路。
此外在所述***中,所述媒体网关控制器还根据负荷分担的原则,将不同呼叫的媒体网关控制协议消息分配到不同的传输链路上。
此外在所述***中,所述媒体网关还包含至少两个通信接口,所述媒体网关控制器和所述媒体网关的通信接口两两建立所述传输链路。
此外在所述***中,所述媒体网关控制协议为H.248协议或MGCP协议。
本发明还提供了一种媒体网关控制协议的承载方法,应用于上文所述的***,包含以下步骤:
媒体网关控制器或媒体网关通过一条当前正常的传输链路向对端发送媒体网关控制协议消息后,如果在预置长度的时间内没有收到回复的响应消息,则在其它正常的传输链路中选择一条再次发送该媒体网关控制协议消息。
其中,所述媒体网关控制器或媒体网关需要发送媒体网关控制协议消息时,从当前正常的各传输链路中随机选择一条发送。
通过比较可以发现,本发明的技术方案与现有技术的主要区别在于,通过增加MGC和MGW之间的多IP地址通信的功能,可以在MGC和MGW间建立多条UDP或TCP传输链路承载媒体网关控制协议,如果一条TCP或UDP传输链路上发送的消息在预定时长内没有得到响应,则通过另一条TCP或UDP传输链路再次发送。此外还可以在各条TCP或UDP传输链路之间实现负荷分担。
这种技术方案上的区别,带来了较为明显的有益效果,即首先,由于本发明方案中MGC和MGW间控制协议使用TCP或UDP承载,而TCP和UDP协议的开销大大小于SCTP协议,实现也更简单,因此可以大大减小协议开销和***资源的消耗。
第二,本发明方案可以在MGC和MGW间建立多条TCP或UDP传输链路,避免了单独使用单条TCP或UDP链路时可能出现的时延过大的情况,保证了MGC和MGW间控制协议消息传输的实时性和可靠性。
第三,本发明可以使用UDP承载MGC和MGW间的控制协议,因此不仅支持H.248协议,还可以支持MGCP协议,有效避免了现有技术使用SCTP协议承载无法支持MGCP协议的缺陷。
第四,负荷分担增强了***的可靠性。
附图说明
图1是根据本发明较佳实施方式的MGC和MGW间控制协议媒体网关控制协议承载***的组成示意图;
图2是根据本发明较佳实施方式的MGC和MGW间控制协议承载的流程图。
具体实施方式
为使本发明的目的、技术方案和优点更加清楚,下面将结合附图对本发明作进一步地详细描述。
和SCTP相比,TCP和UDP协议的应用更加广泛,协议实现更简单,***资源消耗也更少,本发明将MGC和MGW间的控制协议承载在TCP或UDP上,为了避免TCP或UDP协议传输的时延不可控和传输不可靠,本发明还在MGC上增加多IP地址通信的功能,并相应在MGW处为一个MGC配置多个IP地址,利用多IP地址通信的功能建立多条TCP或UDP传输链路保证MGC和MGW间控制协议承载的实时性和可靠性。
MGC和MGW间控制协议承载***包含MGC和至少一个归属于该MGC的MGW,MGC和MGW之间通过IP网络连接。
MGC包含多个具有不同IP地址的IP通信接口板,用于和归属于该MGC的MGW建立多条TCP或UDP传输链路,监测这些传输链路的状态,在当前使用的传输链路故障时,重建该传输链路,并选择另一条传输链路传送MGC和MGW间控制协议的消息。
当MGW和MGC之间建立TCP传输链路时,MGC根据MGW的响应消息监测TCP传输链路状态;当MGW和MGC之间建立UDP传输链路时,MGC根据MGW的响应消息以及和MGW之间的定时握手监测UDP传输链路。
MGC还可以根据负荷分担原则使用不同TCP或UDP传输链路传送不同呼叫的控制协议消息。
MGW用于根据***设置为其归属的MGC配置多个IP地址,在上电时建立多条TCP或UDP传输链路,在收到MGW的消息时回复响应消息。
为了提供更多的TCP或UDP传输链路以进一步提高消息传送的可靠性,MGW还可以包含多个具有不同IP地址的IP通信接口板,MGC还为其管辖的MGW保存多个IP地址,MGW的IP通信接口板和其归属MGC的IP通信接口板两两之间分别建立TCP或UDP传输链路。
本发明和MGC和MGW间控制协议承载***对应的MGC和MGW间控制协议承载方法包含以下步骤:
为MGC配置两个或两个以上IP通信接口板和对应的IP地址,并为归属于该MGC的MGW配置该MGC的两个或两个以上IP地址;
MGW上电时和归属MGC间建立两个或两个以上传输链路;
MGC使用传输链路发送控制协议消息给MGW;
MGC监测传输链路的状态,在传输链路状态异常时选择其它传输链路发送控制协议消息给MGW并重建状态异常的传输链路。
其中,传输链路的传输层协议为TCP或UDP。
为了更好的说明本发明方案,下面结合本发明的较佳实施方式来说明。
根据本发明较佳实施方式的MGC和MGW间控制协议承载***的组成如图1所示。
MGC和MGW间控制协议承载***包含MGC 10和至少一个归属于该MGC 10的MGW 20,MGC 10和MGW 20之间通过IP网络连接。
其中,MGC 10还包含两个IP通信接口板30-1和30-2,MGC 10用于提供现有技术中MGC的所有功能,还用于在其管辖的MGW上电时与该MGW建立多条传输链路,监测这些传输链路的状态,在当前使用的传输链路故障时,重建该传输链路,并选择另一条传输链路传送控制协议消息。其中,传输链路可以使用TCP协议或UDP协议,一个传输链路具有唯一的四元组,即MGC的IP地址、MG的端口号、MGW的IP地址以及MGW的端口号。需要说明的是,为了保证同一呼叫信令传送的顺序性,同一呼叫的控制协议消息在同一条传输链路上传送,除非该传输链路故障。
MGC 10和MGW 20间控制协议可以是H.248协议,传输链路可以使用TCP协议,TCP协议是一种面向连接的协议,传送的信息必须得到对方的确认,如果超时得不到确认,就会重发这些信息,为了保证控制协议消息的实时性和可靠性,本发明中MGC 10如果在规定时间内没有收到MGW 20的响应消息,则将些前使用的TCP传输链路设定为故障并进行重建,同时使用其它TCP传输链路重传控制协议消息。
MGC 10和MGW 20间控制协议也可以为H.248协议或MGCP协议,传输链路也可以使用UDP协议,MGC 10通过和MGW 20之间进行定时握手维护传输链路状态,如果定时握手失败或者在当前使用的UDP传输链路上多次重发控制协议消息后收不到响应,则将当前使用的UDP传输链路设定为故障并进行重建,同时使用其它UDP传输链路重传控制协议消息。其中,在当前使用UDP传输链路上多次重发控制协议消息后收不到响应是指,如果MGC10在该条UDP传输链路上发送控制协议消息后在规定时间内没有收到响应,则重发该消息,若在规定时间内仍没有收到响应,则重复上述操作直至重发次数超出设定次数。需要说明的是,UDP传输链路只是虚拟连接,与TCP连接不同,并不需要专用的连接建立和拆除过程。
MGW 20用于提供现有技术中MGW的所有功能,还用于根据***设置为其归属的MGC 10配置多个IP地址,在上电时建立多条传输链路,在收到MGC 10的消息时回复响应消息。其中,MGW 20尽量选择在收到消息的传输链路上回复响应消息。需要说明的是,本发明方案中MGW 20为其归属的MGC 10配置多个IP地址,多个IP地址对应的多条传输链路均连接到同一个归属MGC,当一条传输链路偶然中断时,还可以使用其它传输链路和MGC10连接,MGW 20和MGC 10之间的连接并没有中断,仍然可以保证消息的可靠传输,这与现有技术方案有本质区别。现有技术方案中,H.248协议虽然允许为同一MGW配置多个MGC的地址,但是这是用于多归属功能的,这些地址分属于不同的MGC,以便MGW发现自己归属的MGC崩溃之后,可以向另一备用MGC重新发起注册。MGW在多个MGC间倒换会引起业务的中断,这只是一种容灾措施,显然不适合用于信令承载网的偶然闪断。
在本发明较佳实施方式中,MGW 20还包含两个IP通信接口板30-3和30-4,这可以在MGC 10和MGW 20之间建立更多的传输链路,进一步提高MGC 10和MGW 20间控制协议消息传输的可靠性和实时性,本领域的普通技术人员理解,这并非必选项,由于MGC 10配置了多个IP通信接口板,已经可以在MGC 10和MGW 20之间建立多条传输链路,因此MGW 20也可以仅配置一个IP通信接口板。
基于本发明较佳实施方式,在本发明第四较佳实施方式中,MGC 10可以给传输链路分配优先级,并优先使用优先级高的可用传输链路;MGC 10也可以根据负荷分担的原则,将不同呼叫的控制协议消息分配到不同的传输链路上。
根据本发明较佳实施方式的MGC和MGW间控制协议承载的流程如图2所示。
首先进入步骤210,为MGC配置至少两个IP通信接口板和对应IP地址。其中,多个IP通信接口板对应多个IP地址,可以用来建立多个传输链路。
接着进入步骤220,为归属于该MGC的MGW配置该MGC的至少两个IP地址。需要说明的是,本发明方案归属于该MGC的MGW配置该MGC的至少多个IP地址,多个IP地址对应的多条传输链路均连接到同一个归属MGC,当一条传输链路偶然中断时,还可以使用其它传输链路和MGC 10连接,MGW和MGC之间的连接并没有中断,仍然可以保证消息的可靠传输,这与现有技术方案有本质区别,现有技术方案中,H.248协议虽然允许为同一MGW配置多个MGC的地址,但是这是用于多归属功能的,这些地址分属于不同的MGC,以便MGW发现自己归属的MGC崩溃之后,可以向另一备用MGC重新发起注册。MGW在多个MGC间倒换会引起业务的中断,这只是一种容灾措施,显然不适用于信令承载网的偶然闪断。
接着进入步骤230,在MGC和MGW间建立至少两条传输链路。其中,传输链路可以使用TCP协议或UDP协议,一个传输链路具有唯一的四元组,即MGC的IP地址、MG的端口号、MGW的IP地址以及MGW的端口号。本领域的普通技术人员理解,MGC和MGW间使用至少两条传输链路连接,相当于提供了一个冗余备份的机制,可以避免由于一条传输链路故障导致通信的中断。
接着进入步骤240,MGC使用传输链路发送控制协议消息给MGW。其中,MGC用来发送控制协议消息的传输链路可以由MGC根据传输链路的优先级选择,或者由MGC根据负荷分担的原则选择。负荷分担有多种方法,例如需要传输控制协议消息时,从当前可用的多条传输链路中随机选择一条,或者各传输链路根据编号依次轮流发送等等。需要说明的是,为了保证同一呼叫信令传送的顺序性,同一呼叫的控制协议消息在同一条传输链路上传送,除非该传输链路故障。
接着进入步骤250,判断当前发送控制协议消息的传输链路是否异常,如果是则进入步骤260,否则结束。如果在预置长度的时间内没有收到回复的响应消息,则可以认为当前发送控制协议消息的传输链路异常。
在步骤260中,MGC选择其它传输链路发送控制协议消息并重建异常的传输链路。其中,TCP传输链路的重建和现有技术相同,而UDP传输链路的重建可以通过定时握手实现。在现有技术中,重发都是在原传输链路上执行,而本发明中重发是在其它传输链路上执行。因为一个传输链路一旦发生了一次超时,下一次重传再发生超时的可能性远大于其它正常的传输链路,所以选择在其它正常的传输链路上进行重传可以有效地提高传输的实时性和可靠性。
虽然通过参照本发明的某些优选实施方式,已经对本发明进行了图示和描述,但本领域的普通技术人员应该明白,可以在形式上和细节上对其作各种改变,而不偏离本发明的精神和范围。
Claims (11)
1.一种媒体网关控制协议的承载***,包含媒体网关控制器和归属于该媒体网关控制器的至少一个媒体网关,所述媒体网关控制器和所述媒体网关通过IP协议网络连接,其特征在于,所述媒体网关控制器还包含至少两个具有不同IP协议地址的通信接口,并利用这些通信接口分别和所述媒体网关建立至少两条用于承载所述控制协议的传输链路;
所述媒体网关控制器还用于监测各所述传输链路的状态,在发现传输链路故障时,尝试重建该传输链路,并选择其它状态正常的传输链路,以便传送媒体网关控制协议消息给所述媒体网关。
2.根据权利要求1所述的媒体网关控制协议的承载***,其特征在于,所述媒体网关还根据***设置为所述媒体网关控制器配置至少两个IP协议地址,和所述媒体网关控制器间建立至少两条传输链路,在收到所述媒体网关控制协议消息时回复响应消息。
3.根据权利要求2所述的媒体网关控制协议的承载***,其特征在于,所述传输链路使用传输控制协议或用户数据报协议。
4.根据权利要求3所述的媒体网关控制协议的承载***,其特征在于,所述传输链路使用传输控制协议时,所述媒体网关控制器根据所述媒体网关的所述响应消息监测所述传输链路的状态,如果在一条传输链路上发送所述媒体网关控制协议消息后,在规定时间内没有收到所述媒体网关的响应消息,则判定该传输链路故障。
5.根据权利要求3所述的媒体网关控制协议的承载***,其特征在于,所述媒体网关控制器根据所述媒体网关的所述响应消息以及和所述媒体网关间的定时握手监测所述传输链路的状态,如果定时握手失败或者在同一传输链路上连续重发所述媒体网关控制协议消息超过门限,则判定该传输链路故障。
6.根据权利要求1至5中任一项所述的媒体网关控制协议的承载***,其特征在于,所述媒体网关控制器还为所述传输链路分配优先级,并优先使用优先级高的可用传输链路。
7.根据权利要求1至5中任一项所述的媒体网关控制协议的承载***,其特征在于,所述媒体网关控制器还根据负荷分担的原则,将不同呼叫的媒体网关控制协议消息分配到不同的传输链路上。
8.根据权利要求1至5中任一项所述的媒体网关控制协议的承载***,其特征在于,所述媒体网关还包含至少两个通信接口,所述媒体网关控制器和所述媒体网关的通信接口两两建立所述传输链路。
9.根据权利要求1至5中任一项所述的媒体网关控制协议的承载***,其特征在于,所述媒体网关控制协议为H.248协议或MGCP协议。
10.一种媒体网关控制协议的承载方法,应用于权利要求1所述的媒体网关控制协议的承载***,其特征在于,包含以下步骤:
媒体网关控制器或媒体网关通过一条当前正常的传输链路向对端发送媒体网关控制协议消息后,如果在预置长度的时间内没有收到回复的响应消息,则在其它正常的传输链路中选择一条再次发送该媒体网关控制协议消息。
11.根据权利要求10所述的媒体网关控制协议的承载方法,其特征在于,所述媒体网关控制器或媒体网关需要发送媒体网关控制协议消息时,从当前正常的各传输链路中随机选择一条发送。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN200510110889A CN100589484C (zh) | 2005-11-29 | 2005-11-29 | 媒体网关控制协议的承载***及其方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN200510110889A CN100589484C (zh) | 2005-11-29 | 2005-11-29 | 媒体网关控制协议的承载***及其方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN1893428A CN1893428A (zh) | 2007-01-10 |
CN100589484C true CN100589484C (zh) | 2010-02-10 |
Family
ID=37597943
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN200510110889A Expired - Fee Related CN100589484C (zh) | 2005-11-29 | 2005-11-29 | 媒体网关控制协议的承载***及其方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN100589484C (zh) |
Families Citing this family (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101272600B (zh) * | 2007-03-23 | 2012-12-12 | 华为技术有限公司 | 实现承载重建立的方法、及其相关设备 |
CN101309285B (zh) * | 2007-05-15 | 2012-09-05 | 华为技术有限公司 | 一种第二层控制的方法、装置及其*** |
CN101621476B (zh) * | 2009-08-17 | 2011-11-23 | 中兴通讯股份有限公司 | Diameter链路的建立方法和Diameter网元 |
CN102244687B (zh) * | 2010-05-13 | 2014-11-05 | 华为技术有限公司 | 获取多地址信息的方法、装置和*** |
CN104243396A (zh) * | 2013-06-07 | 2014-12-24 | 阿尔卡特朗讯公司 | 在第一端点与第二端点之间建立关联的方法及相关端点 |
CN104320273B (zh) * | 2014-10-22 | 2019-03-19 | 网易(杭州)网络有限公司 | 数据传输方法、设备及*** |
CN105847141A (zh) * | 2016-01-25 | 2016-08-10 | 乐卡汽车智能科技(北京)有限公司 | 在具有多个通信链路的通信设备上的通信方法及通信设备 |
CN112637054B (zh) * | 2019-10-08 | 2022-12-13 | ***通信集团浙江有限公司 | Ip承载网的组网优化方法、装置、计算设备和存储介质 |
CN114285792A (zh) * | 2021-12-20 | 2022-04-05 | 东土科技(宜昌)有限公司 | 一种基于冗余链路的数据传输方法及装置、设备、存储介质 |
-
2005
- 2005-11-29 CN CN200510110889A patent/CN100589484C/zh not_active Expired - Fee Related
Non-Patent Citations (4)
Title |
---|
一种基于CPCI总线的移动媒体网关设计与实现方案. 徐书华,黄本雄,徐丽娜.网络与通信,第5期. 2005 |
一种基于CPCI总线的移动媒体网关设计与实现方案. 徐书华,黄本雄,徐丽娜.网络与通信,第5期. 2005 * |
下一代网络中媒体网关控制协议-MGCP/H.248/MEGACO的研究. 刘伟彦,张顺颐.电信科学,第4期. 2005 |
下一代网络中媒体网关控制协议-MGCP/H.248/MEGACO的研究. 刘伟彦,张顺颐.电信科学,第4期. 2005 * |
Also Published As
Publication number | Publication date |
---|---|
CN1893428A (zh) | 2007-01-10 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN100589484C (zh) | 媒体网关控制协议的承载***及其方法 | |
US8743892B2 (en) | Method and system for dynamic gateway selection in an IP telephony network | |
Andreasen et al. | Media gateway control protocol (MGCP) version 1.0 | |
US7996543B2 (en) | Client-to-client direct RTP exchange in a managed client-server network | |
JP4208540B2 (ja) | インターネットプロトコルネットワークで負荷割当てボイスオーバーインターネットプロトコルトラフィックに対して分割されたファイアーウォールを使用するソフトスイッチ | |
US7817541B2 (en) | Method and system of providing redundancy in a network device | |
CN101257433B (zh) | 实现网络地址转换穿越的方法和*** | |
US7936750B2 (en) | Packet transfer device and communication system | |
EP1349347B1 (en) | Method and apparatus for redundant signaling links | |
JP3633546B2 (ja) | シグナリング中継システムおよびシグナリング中継方法 | |
US7860114B1 (en) | Method and system for dynamic gateway selection in an IP telephony network | |
EP2901651B1 (en) | Application layer session routing | |
CN101410820A (zh) | 无应用接收端参与的在发送端使用预订协议促进应用同步 | |
JP2005229273A (ja) | サーババックアップ装置 | |
US20040260824A1 (en) | Internet telephony call agent | |
CN101146100A (zh) | 一种基于传输协议sctp和dccp的sip网络电话实现方法 | |
US9281996B1 (en) | Method and system for dynamic gateway selection in an IP telephony network | |
EP1836824A1 (en) | Method and apparatus for controlling an sctp protocol instance | |
US8107465B1 (en) | Slim bandwidth reservation protocol over an IP network | |
Cisco | Cisco AS5400 - Cisco IOS Release 12.2 XB | |
Cisco | Cisco AS5350 - Cisco IOS Release 12.2 XB | |
Cisco | PRI Backhaul Using the Stream Control Transmission Protocol and the ISDN Q.921 User Adaptation Layer | |
WO2001078331A1 (en) | Communication system comprising a gateway device for handling connections | |
US7747672B1 (en) | Method and apparatus using lightweight RRQ for efficient recovery of a call signaling channel in gatekeeper-routed call signaling | |
JP6955170B2 (ja) | Rtp監視装置及びrtp監視方法 |
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 | ||
C17 | Cessation of patent right | ||
CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20100210 Termination date: 20121129 |