CN105100957A - 基于sip负载均衡实现高清视频多链路传输的方法 - Google Patents
基于sip负载均衡实现高清视频多链路传输的方法 Download PDFInfo
- Publication number
- CN105100957A CN105100957A CN201410196709.3A CN201410196709A CN105100957A CN 105100957 A CN105100957 A CN 105100957A CN 201410196709 A CN201410196709 A CN 201410196709A CN 105100957 A CN105100957 A CN 105100957A
- Authority
- CN
- China
- Prior art keywords
- sip
- packet
- load
- video
- link
- 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.)
- Pending
Links
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
能高效传输高清视频信息的基于SIP负载均衡实现高清视频多链路传输的方法,包括:将SIP负载均衡器部署在视频传送网络中;SIP负载均衡器接收客户端的视频通道建立请求,根据链路的负载信息,选择合适的链路,建立新的视频通道;RTP数据包在客户端和SIP代理服务器间直接访问,不经过SIP负载均衡器;SIP负载均衡器其硬件包括CPU、网络端口、内存和磁盘存储器,其软件包括:网络模块、健康检查模块、负载信息采集模块、负载均衡计算模块、会话保持模块,数据包修改模块和配置管理模块。本发明适合高清视频网络传输。
Description
技术领域
本发明涉及网络通信领域,尤其涉及一种负载均衡系统及高清视频传输实现链路负载均衡的方法。
背景技术
随着经济和技术的快速发展,因特网(Internet)以其丰富的资源,个性化的服务以及方便的交互性,给人们的工作与生活带来了巨大的方便与可喜的变化。远程视频监控是其中的一个得到广泛的应用项目,特别是在交通、公共场所、公安部门、学校、家庭保安等等领域是如此。视频技术发展到高清时代,人们不再满足于传统的远程视频监控,而是需要更进步的高清视频远程监控。高清视频数据量大,占用大量带宽,单个网络带宽成为了多条高清视频传输的瓶颈,无法满足现代视频监控的要求。
多条链路的并联使用是带宽不足的一个有效解决方案。在远程的两个局部网间是一个有光纤相链接的主干道。光纤可以传送众多不同频率的光波,不同频率的光波形成了不同的链路。光纤分路器是用来实现光波能量的分路和合路的器件,将一根光纤中传输的光能量按照既定的比例分配给两根或者是多根光纤,或者将多根光纤中传输的光能量合成到一根光纤中。光纤分路器的技术使得多条链路的并联部署成为了可能。
通用的负载均衡的技术实现了数据包在不同的链路中同时传输。视频传输协议有其特殊性,基于IP协议(InternetProtocol,网间互连协议)的简单链路负载均衡或者基于四层UDP的负载均衡均不能充分利用视频传输协议的特殊性以实现更优化的负载均衡。
SIP协议(SessionInitiationProtocol,会话发起协议),在RFC3261有详细说明。SIP协议在语音、视频的IP网络中广泛应用。SIP协议定义了在视频头及视频客户端间如何建立、修改、终止通信会话以及如何协调通信参数。SIP协议与会话描述协议SDP(SessionDescriptionProtocol)一起建立通信会话。
图1是现行典型的远程视频会话网络部署拓扑图。根据RFC3261协议,当Alice客户端与Bob视频头利用SIP协议建立视频会话(Session)时,其视频建立流程如下:
Alice客户端发送一个INVITE请求到SIP代理服务器,要求与Bob视频头会话:
INVITEsip:bobbiloxi.comSIP/2.0
Via:SIP/2.0/UDPpc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards:70
To:Bob<sip:bobbiloxi.com>
From:Alice<sip:aliceatlanta.com>;tag=1928301774
Call-ID:a84b4c76e66710pc33.atlanta.com
CSeq:314159INVITE
Contact:<sip:alicepc33.atlanta.com>
Content-Type:application/sdp
Content-Length:142
(Alice'sSDP协议数据)
SIP代理服务器转发INVITE请求给Bob视频头,Bob视频头接收会话请求,发送下面同意(200OK)数据包回来给SIP代理服务器,SIP代理服务器转发给Alice客户端:
SIP/2.0200OK
Via:SIP/2.0/UDPserver10.biloxi.com;branch=z9hG4bKnashds8;received=192.0.2.3
Via:SIP/2.0/UDPbigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2
Via:SIP/2.0/UDPpc33.atlanta.com;branch=z9hG4bK776asdhds;received=192.0.2.1
To:Bob<sip:bobbiloxi.com>;tag=a6c85cf
From:Alice<sip:aliceatlanta.com>;tag=1928301774
Call-ID:a84b4c76e66710pc33.atlanta.com
CSeq:314159INVITE
Contact:<sip:bob192.0.2.4>
Content-Type:application/sdp
Content-Length:131
(Bob'sSDP协议数据)
这样,成功建立了视频会话。
RTP/RTCP协议全称分别是Real‐timeTransportProtocol/RTPControlProtocol,在RFC3550有详细说明。RTP协议(Real‐timeTransportProtocol,实时传输协议)为语音、视频在IP网络传输中定义了标准的数据包格式。在点与点之间传输视频流数据,视频会话会话成功建立后,根据SIP定义的源地址和目标地址,RTP协议数据包在视频头,两个代理服务器,及客户端间传输。RTCP协议(RTPControlProtocol,实时传输控制协议)的作用是QoS控制,传输数据统计以及多视频流的协调控制。图2是现行典型的远程视频会话建立时RTP协议数据包的流程图。
在远程监控实际部署中,前、后置SIP代理服务器是必须的,其目的是隔离共用网络云(PublicCloud)和私云(PrivateCloud),或者公共网和局部网。互联网上,两个局部网间的光纤构成了多条链路,因特网支持这种重复链路部署。
路由器连接了两个或者多个不同的IP网络。当一个数据包从一个网络收到时,根据数据包的目标地址和路由表发送到下一个输出网络。路由器只是选择一条链路,不具备根据带宽智能选路功能。应用交付平台系统中的核心设备负载均衡就是根据链路的检测结果,经过计算可以智能选路。负载均衡技术是建立在现有网络结构之上,提供了一种更为有效使用网络传输高清视频的方法。
本方法的核心发明就是在Alice客户端和Bob视频头中间,部署一个SIP协议的应用负载均衡器,这负载均衡器在现有的网络中解决了高清视频传输单一带宽的瓶颈问题。
发明内容
本发明要解决高清视频传输因数据量大而占用大量带宽,导致单个网络带宽难以传输多条高清视频通信,因而无法满足现代视频监控的要求的问题,为此提供本发明的基于SIP负载均衡实现高清视频多链路传输的方法,本方法能在网格中高效传输高清视频信息。
为解决上述问题,本发明采用的技术方案其特殊之处在于包括以下步骤:
将SIP负载均衡器部署在多条链路的视频传送网络中,
所述SIP负载均衡器接收客户端的视频通道建立请求,根据链路的负载信息,选择合适的链路,建立新的视频通道,
所述选择合适的链路是通过修改SIP/INVITE数据包中的FROM/TO/CONTACT头来实现的,
RTP数据包在客户端和SIP代理服务器间直接访问,不经过SIP负载均衡器;
所述SIP负载均衡器由以下硬件和软件构成:
所述硬件包括CPU、网络端口、内存和磁盘存储器;
所述软件为:
网络模块,负责接收,发送数据包;
健康检查模块,检查SIP代理服务器的运行状态;
负载信息采集模块,收集每条链路的负载现状作为选路计算的依据;
负载均衡计算模块,通过计算选择最优化途径;
会话保持模块,保证同一个客户端的相关的数据包发送到同一条途径,以保证会话的完整性;
数据包修改模块,完成SIP协议数据包的修改;
配置管理模块,供负载均衡器管理员管理和配置系统参数。
本发明中所述SIP负载均衡器通过修改SIP协议数据包实现RTP负载均衡。
所述SIP负载均衡器收集链路的RTP负载信息。
所述SIP负载均衡器支持多链路的流量并行传输。
本发明所述RTP协议数据包不经过负载均衡器。
本发明中所述链路中部署SIP代理服务器,用于RTP数据包流量的负载均衡,包括以下步骤:
读取SIP协议数据包;
解析SIP协议数据包中的源地址,From,To,Contact,Call‐ID协议头;
修改SIP协议数据包中的源地址,From,To,Contact,Call‐ID协议头;
发送SIP协议数据包。
所述SIP负载均衡器从网络中读取SIP协议数据包并解析特殊的协议头,从中获取特定的信息用于负载均衡链路选择的计算依据。
所述SIP负载均衡器在读取的SIP协议数据包中修改特定的协议头,并发送修改后的数据包。
附图说明
图1是现行典型的远程视频会话网络部署拓扑图;
图2是现行典型的远程视频会话建立时RTP协议数据包的流程图;
图3是本发明中的SIP负载均衡器在视频网络中的部署拓扑图;
图4是本发明的SIP负载均衡器的系统架构图;
图5是本发明的SIP负载均衡逻辑程序中视频链路选择逻辑设计流程;
图6是本发明的SIP代理服务器健康检查模块的逻辑设计流程图;
图7是本发明的视频会话建立请求流程图;
图8是本发明的视频会话建立同意请求流程图;
图9是本发明的RTP数据包的传输流程图。
具体实施方式
本发明是通过以下方式实现的:
本发明包括SIP负载均衡器,以及前置SIP代理服务器、后置SIP代理服务器和与SIP代理服务器相连接的多条链路。SIP负载均衡器接收到客户端的INVITE请求后,进行SIP数据包分析,之后,根据处理结果及每条链路的负载信息,计算出一个可用的链路,然后把INVITE请求修改后发送给这条链路上的SIP代理服务器。
图3是本发明中的SIP负载均衡器在视频网络中的部署拓扑图。
图4是本发明中的SIP负载均衡器的系统架构图。所述的负载均衡器是一个硬件设备,包括CPU、网络端口、内存及存储硬件等。通用的工控机可以作为硬件设备载体。其软件架构包括配置管理模块、网络模块、SIP代理服务器健康检查模块、负载信息采集模块、负载均衡计算模块、会话保持模块及数据包修改模块。其中配置管理模块是负载均衡器管理员管理和配置系统参数的模块;网络模块负责接收,发送数据包;健康检查模块检查SIP代理服务器的运行状态;负载信息采集模块收集每条链路的负载现状作为选路计算的依据;负载均衡计算模块通过计算选择最优化途径;会话保持模块的功能是保证同一个客户端的相关的数据包发送到同一条途径,以保证会话的完整性;数据包修改模块完成SIP协议的修改。
图5是本发明中的SIP负载均衡逻辑程序中最核心的视频链路选择逻辑设计流程。负载均衡器的网络模块收到一个SIP数据包后,数据包修改模块解析此数据包,得到Call‐ID或者Callee字符串,会话保护模块查询负载均衡会话保持希哈表(HashTable),同一个Call‐ID字符串表明这些UDP数据包属于同一个会话。同一个会话的SIP数据包必须选择同一个链路。新的Call‐ID代表新的会话,新的会话根据这个流程图计算出新的链路,并且生成新的会话保持数据结构,记录其在会话保持希哈表中。图5并展示了各模块之间的关联关系。
负载均衡的基本概念是策略、会话保持和健康检查。选路策略有多种:简单循环,加权循环,链路最少流量,最少会话数等,本发明描述的方法都可适合。会话保持也有多种:Call‐ID,Callee,源地址等,本发明描述的方法都可适合。
图6是本发明中的SIP代理服务器健康检查模块的逻辑设计流程图。如果SIP代理服务器处于离线状态,SIP负载均衡器在视频选路时不选择此链路。因而多链路的备份功能就可以实现,整个视频系统具备高可靠性。链路健康检查的协议有多种:ICMP,SIPMESSAGE心跳等,本发明描述的方法都可适合。
结合本发明,视频会话建立的过程及负载均衡对数据包的修改在以下的过程中进行说明。
图7是本发明中的视频会话建立请求流程图。当Alice客户端对Bob视频头请求建立会话时,下面步骤描述了流程及本发明的数据包修改方案。以下是描述了会话建立时数据包修改过程,但是这个修改过程同样也应用于会话断开等交易过程。
为了描述方便,各部件赋予了一个IP地址。Alice客户端地址是172.16.1.202,负载均衡器地址是172.16.1.203,后置SIP代理服务器地址是172.16.1.200/172.16.1.201,前置SIP代理服务器地址是192.168.2.200/192.168.2.201,Bob视频头地址是192.168.2.202。
第701步:Alice客户端(172.16.1.202)视频会话请求(INVITE)数据包送到SIP负载均衡器(172.16.1.203)。
INVITEsip:bob172.16.1.203SIP/2.0
Via:SIP/2.0/UDP172.16.1.202;branch=z9hG4bK776asdhds
Max-Forwards:70
To:Bob<sip:bob172.16.1.203>
From:Alice<sip:alice172.16.1.202>;tag=1928301774
Call-ID:a84b4c76e66710172.16.1.202
CSeq:1INVITE
Contact:<sip:alice172.16.1.202>
Content-Type:application/sdp
Content-Length:142
v=0
o=alice00INIP4172.16.1.202
s=Play
c=INIP4172.16.1.202
t=00
m=video55000RTP/AVP969897
a=recvonly
a=rtpmap:96PS/90000
a=rtpmap:98MPEG4/90000
a=rtpmap:97H264/90000
y=0000000106
f=v//2//4//25//1//a//1//8//1
第702步:当两个链路都在线时,采用负载均衡简单循环的策略,智能选择了第一条链路(172.16.1.201),SIP负载均衡器(172.16.1.203)修改请求(INVITE)数据包。修改FROM/CONTACT头,原来的地址(172.16.1.202)代替为(172.16.1.203);修改TO头,原来的地址(172.16.1.203)代替为(172.16.1.201)。然后将修改后的数据包送到后置SIP代理服务器(172.16.1.201)。如果负载均衡选择第二条链路(172.16.1.202),那么TO头中需要把原来的地址(172.16.1.203)代替为(172.16.1.202),然后将修改后的数据包送到后置SIP代理服务器(172.16.1.200)。SDP中的o/c值不必修改。
INVITEsip:bob172.16.1.201SIP/2.0
Via:SIP/2.0/UDP172.16.1.201;branch=z9hG4bK776asdhds
Max-Forwards:70
To:Bob<sip:bob172.16.1.201>
From:Alice<sip:alice172.16.1.203>;tag=1928301774
Call-ID:a84b4c76e66710172.16.1.202
CSeq:1INVITE
Contact:<sip:alice172.16.1.201>
Content-Type:application/sdp
Content-Length:142
v=0
o=alice00INIP4172.16.1.202
s=Play
c=INIP4172.16.1.202
t=00
m=video55000RTP/AVP969897
a=recvonly
a=rtpmap:96PS/90000
a=rtpmap:98MPEG4/90000
a=rtpmap:97H264/90000
y=0000000106
f=v//2//4//25//1//a//1//8//1
第703步:后置SIP代理服务器(172.16.1.201)同样将修改SIP数据包发送到相匹配的前置SIP代理服务器(192.168.2.201)。后置SIP代理服务器从私云(PrivateCloud)转发代理RTP数据包到公共云(PublicCloud),因而需要修改SDP的o/c值。后置SIP代理服务器(172.16.1.201)修改FROM/CONTACT头,原来的地址(172.16.1.203)代替为(172.16.1.201);修改TO头,原来的地址(172.16.1.201)代替为(192.168.2.201);修改SDP的o/c地址,原来的(172.16.1.202)代替为(172.16.1.201)。然后将修改后的数据包送到前置SIP代理服务器(192.168.2.201)。修改后的数据包为:
INVITEsip:bob192.168.2.201SIP/2.0
Via:SIP/2.0/UDP192.168.2.201;branch=z9hG4bK776asdhds
Max-Forwards:70
To:Bob<sip:bob192.168.2.201>
From:Alice<sip:alice172.16.1.201>;tag=1928301774
Call-ID:a84b4c76e66710172.16.1.202
CSeq:1INVITE
Contact:<sip:alice172.16.1.201>
Content-Type:application/sdp
Content-Length:142
v=0
o=alice00INIP4172.16.1.201
s=Play
c=INIP4172.16.1.201
t=00
m=video55000RTP/AVP969897
a=recvonly
a=rtpmap:96PS/90000
a=rtpmap:98MPEG4/90000
a=rtpmap:97H264/90000
y=0000000106
f=v//2//4//25//1//a//1//8//1
第704步:前置SIP代理服务器(192.168.2.201)从公共云(PublicCloud)转发代理RTP数据包到私云(PrivateCloud)中,因而需要修改SDP的o/c值。前置SIP代理服务器(192.168.2.201)修改FROM/CONTACT头,原来的地址(172.16.1.201)代替为(192.168.2.201);修改TO头,原来的地址(192.168.2.201)代替为(192.168.2.202);修改SDP的o/c地址,原来的(172.16.1.201)代替为(192.168.2.201)。然后将修改后的数据包送到Bob视频头(192.168.2.202)。修改后的数据包为:
INVITEsip:bob192.168.2.202SIP/2.0
Via:SIP/2.0/UDP192.168.2.202;branch=z9hG4bK776asdhds
Max-Forwards:70
To:Bob<sip:bob192.168.2.202>
From:Alice<sip:alice192.168.2.201>;tag=1928301774
Call-ID:a84b4c76e66710172.16.1.202
CSeq:1INVITE
Contact:<sip:alice192.168.2.201>
Content-Type:application/sdp
Content-Length:142
v=0
o=alice00INIP4192.168.2.201
s=Play
c=INIP4192.168.2.201
t=00
m=video55000RTP/AVP969897
a=recvonly
a=rtpmap:96PS/90000
a=rtpmap:98MPEG4/90000
a=rtpmap:97H264/90000
y=0000000106f=v//2//4//25//1//a//1//8//1
当Bob视频头同意建立会话时,Bob视频头需要送“SIP/2.0200OK”数据包给Alice客户端,下面步骤描述了该流程及本发明的数据包修改方案。图8是本发明的视频会话建立同意请求流程图。
第801步:Bob视频头(192.168.2.202)返回数据包到前置SIP代理服务器(192.168.2.201)。
SIP/2.0200OK
Via:SIP/2.0/UDP
192.168.2.201:5060;branch=z9hG4bK76
From:<sip:alice192.168.2.201:5060>;tag=1928301774
To:<sip:bob192.168.2.202:5060>;tag=21600
Call-ID:a84b4c76e66710172.16.1.202
CSeq:1INVITE
Contact:<sip:bob192.168.2.202:5060>
Content-Type:application/sdp
User-agent:kedacom
Content-Length:223
v=0
o=bob00INIP4192.168.2.202
s=Play
c=INIP4192.168.2.202
t=00
m=video1026RTP/AVP969897
a=sendonly
a=rtpmap:96PS/90000
a=rtpmap:98H264/90000
a=rtpmap:97MPEG4/90000
y=0000000038
第802步:前置SIP代理服务器(192.168.2.201)修改SIP数据包返回到相匹配的后置SIP代理服务器(172.16.1.201)。SDP协议(SessionDescriptionProtocol,会话描述协议)中的c/o需要修改。前置SIP代理服务器(192.168.2.201)修改FROM/CONTACT头,原来的地址(192.168.2.201)代替为(172.16.1.201);修改TO头,原来的地址(192.168.2.202)代替为(192.168.2.201);修改SDP的o/c地址,原来的(192.168.2.202)代替为(192.168.2.201)。然后将修改后的数据包送到后置SIP代理服务器(172.16.1.201)。修改后的数据包为:
SIP/2.0200OK
Via:SIP/2.0/UDP
192.168.2.201:5060;branch=z9hG4bK76
From:<sip:alice172.16.1.201:5060>;tag=1928301774
To:<sip:bob192.168.2.201:5060>;tag=21600
Call-ID:a84b4c76e66710172.16.1.202
CSeq:1INVITE
Contact:<sip:bob192.168.2.201:5060>
Content-Type:application/sdp
User-agent:kedacom
Content-Length:223
v=0
o=bob00INIP4192.168.2.201
s=Play
c=INIP4192.168.2.201
t=00
m=video1026RTP/AVP969897
a=sendonly
a=rtpmap:96PS/90000
a=rtpmap:98H264/90000
a=rtpmap:97MPEG4/90000
y=0000000038
第803步:后置SIP代理服务器(172.16.1.201)修改SIP数据包返回到相匹配的负载均衡器(172.16.1.203)。同样SDP协议中的c/o需要修改。后置SIP代理服务器(192.168.1.201)修改FROM/CONTACT头,原来的地址(172.16.1.201)代替为(172.16.1.203);修改TO头,原来的地址(192.168.2.201)代替为(172.16.1.201);修改SDP的o/c地址,原来的(192.168.2.201)代替为(172.16.1.201)。然后将修改后的数据包送到SIP负载均衡器(172.16.1.203)。修改后的数据包为:
SIP/2.0200OK
Via:SIP/2.0/UDP172.16.1.203:5060;branch=z9hG4bK76
From:<sip:alice172.16.1.203:5060>;tag=1928301774
To:<sip:bob172.16.1.201:5060>;tag=21600
Call-ID:a84b4c76e66710172.16.1.202
CSeq:1INVITE
Contact:<sip:bob172.16.1.203:5060>
Content-Type:application/sdp
User-agent:kedacom
Content-Length:223
v=0
o=bob00INIP4172.16.1.201
s=Play
c=INIP4172.16.1.201
t=00
m=video1026RTP/AVP969897
a=sendonly
a=rtpmap:96PS/90000
a=rtpmap:98H264/90000
a=rtpmap:97MPEG4/90000
y=0000000038
第804步:SIP负载均衡器(172.16.1.203)返回SIP数据包到Alice客户端(172.16.1.202),没有修改SDP数据。SIP负载均衡器(172.16.1.203)修改FROM/CONTACT头,原来的地址(172.16.1.203)代替为(172.16.1.202);修改TO头,原来的地址(172.16.1.203)代替为(172.16.1.202)。然后将修改后的数据包送到Alice客户端(172.16.1.202)。修改后的数据包为:
SIP/2.0200OK
Via:SIP/2.0/UDP172.16.1.203:5060;branch=z9hG4bK76
From:<sip:alice172.16.1.202:5060>;tag=1928301774
To:<sip:bob172.16.1.203:5060>;tag=21600
Call-ID:a84b4c76e66710172.168.1.202
CSeq:1INVITE
Contact:<sip:bob172.16.1.202:5060>
Content-Type:application/sdp
User-agent:kedacom
Content-Length:223
v=0
o=bob00INIP4172.16.1.201
s=Play
c=INIP4172.16.1.201
t=00
m=video1026RTP/AVP969897
a=sendonly
a=rtpmap:96PS/90000
a=rtpmap:98H264/90000
a=rtpmap:97MPEG4/90000
y=0000000038
Alice客户端的视频请求(INVITE)数据包包含了SDP协议,经过SIP负载均衡链路选路后,对应的前、后置SIP代理服务器把SIP代理服务器的地址改写到SDP协议中。Bob视频头跟据SDP协议中的地址把视频RTP数据包送到对应的前置SIP代理服务器。前置SIP代理服务器根据视频会话信息通过对应的链路,把RTP数据包传输到对应的后置SIP代理服务器。后置SIP代理服务器直接发送到对应的Alice客户端。本发明实现了RTP数据包不经过SIP负载均衡直接在客户端和SIP代理服务器间传送,提高数据传输效率。图9是RTP数据包的传输流程图。
总结:
本发明公开的SIP负载均衡实现高清视频多链路传输的方法具备了以下创新功能:
1、通过负载均衡分配多条链路的方法解决了高清视频在单一SIP代理服务器网关导致的流量瓶颈的问题。
2、在多条链路SIP负载均衡中,RTP视频数据包的传输不经过负载均衡,提高了负载均衡的运行效率。
Claims (8)
1.基于SIP负载均衡实现高清视频多链路传输的方法,其特征在于,包括以下步骤:
将SIP负载均衡器部署在多条链路的视频传送网络中;
所述SIP负载均衡器接收客户端的视频通道建立请求,根据链路的负载信息,选择合适的链路,建立新的视频通道;
所述选择合适的链路是通过修改SIP/INVITE数据包中的FROM/TO/CONTACT头来实现的;
RTP数据包在客户端和SIP代理服务器间直接访问,不经过SIP负载均衡器;
所述SIP负载均衡器由以下硬件和软件构成:
所述硬件包括CPU、网络端口、内存和磁盘存储器;
所述软件为:
网络模块,负责接收,发送数据包;
健康检查模块,检查SIP代理服务器的运行状态;
负载信息采集模块,收集每条链路的负载现状作为选路计算的依据;
负载均衡计算模块,通过计算选择最优化途径;
会话保持模块,保证同一个客户端的相关的数据包发送到同一条途径,以保证会话的完整性;
数据包修改模块,完成SIP协议数据包的修改;
配置管理模块,供负载均衡器管理员管理和配置系统参数。
2.根据权利要求1所述的方法,其特征在于,SIP负载均衡器通过修改SIP协议数据包实现RTP负载均衡。
3.根据权利要求1所述的方法,其特征在于,SIP负载均衡器收集链路的RTP负载信息。
4.根据权利要求1所述的方法,其特征在于,SIP负载均衡器支持多链路的流量并行传输。
5.根据权利要求1所述的方法,其特征在于,RTP协议数据包不经过负载均衡器。
6.根据权利要求1所述的方法,其特征在于所述链路中部署SIP代理服务器,用于RTP数据包流量的负载均衡,包括以下步骤:
读取SIP协议数据包;
解析SIP协议数据包中的源地址,From,To,Contact,Call‐ID协议头;
修改SIP协议数据包中的源地址,From,To,Contact,Call‐ID协议头;
发送SIP协议数据包。
7.根据权利要求6所述的方法,其特征在于所述SIP负载均衡器从网络中读取SIP协议数据包并解析特殊的协议头,从中获取特定的信息用于负载均衡链路选择的计算依据。
8.根据权利要求7所述的方法,其特征在于所述SIP负载均衡器在读取的SIP协议数据包中修改特定的协议头,并发送修改后的数据包。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201410196709.3A CN105100957A (zh) | 2014-05-09 | 2014-05-09 | 基于sip负载均衡实现高清视频多链路传输的方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201410196709.3A CN105100957A (zh) | 2014-05-09 | 2014-05-09 | 基于sip负载均衡实现高清视频多链路传输的方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN105100957A true CN105100957A (zh) | 2015-11-25 |
Family
ID=54580335
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201410196709.3A Pending CN105100957A (zh) | 2014-05-09 | 2014-05-09 | 基于sip负载均衡实现高清视频多链路传输的方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN105100957A (zh) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109587450A (zh) * | 2018-12-20 | 2019-04-05 | 北京明朝万达科技股份有限公司 | 视频数据传输方法和系统 |
CN110611548A (zh) * | 2018-06-15 | 2019-12-24 | 中兴通讯股份有限公司 | 数据传输方法、设备、发送设备、接收设备及存储介质 |
CN110913010A (zh) * | 2019-12-05 | 2020-03-24 | 杭州东信北邮信息技术有限公司 | 一种sip业务集群系统及实现方法 |
US10616136B2 (en) | 2018-04-19 | 2020-04-07 | Microsoft Technology Licensing, Llc | Utilization based dynamic resource allocation |
CN114928661A (zh) * | 2022-05-31 | 2022-08-19 | 杭州迪普科技股份有限公司 | 会话保持方法和装置 |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040172464A1 (en) * | 2000-07-28 | 2004-09-02 | Siddhartha Nag | End-to-end service quality for latency-intensive internet protocol (IP) applications in a heterogeneous, multi-vendor environment |
CN101815079A (zh) * | 2009-02-24 | 2010-08-25 | 北京邮电大学 | 基于sip的服务器集群发布服务信息的方法及系统 |
-
2014
- 2014-05-09 CN CN201410196709.3A patent/CN105100957A/zh active Pending
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040172464A1 (en) * | 2000-07-28 | 2004-09-02 | Siddhartha Nag | End-to-end service quality for latency-intensive internet protocol (IP) applications in a heterogeneous, multi-vendor environment |
CN101815079A (zh) * | 2009-02-24 | 2010-08-25 | 北京邮电大学 | 基于sip的服务器集群发布服务信息的方法及系统 |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10616136B2 (en) | 2018-04-19 | 2020-04-07 | Microsoft Technology Licensing, Llc | Utilization based dynamic resource allocation |
CN110611548A (zh) * | 2018-06-15 | 2019-12-24 | 中兴通讯股份有限公司 | 数据传输方法、设备、发送设备、接收设备及存储介质 |
CN110611548B (zh) * | 2018-06-15 | 2022-09-09 | 中兴通讯股份有限公司 | 数据传输方法、设备、发送设备、接收设备及存储介质 |
CN109587450A (zh) * | 2018-12-20 | 2019-04-05 | 北京明朝万达科技股份有限公司 | 视频数据传输方法和系统 |
CN110913010A (zh) * | 2019-12-05 | 2020-03-24 | 杭州东信北邮信息技术有限公司 | 一种sip业务集群系统及实现方法 |
CN110913010B (zh) * | 2019-12-05 | 2021-12-31 | 杭州东信北邮信息技术有限公司 | 一种sip业务集群系统及实现方法 |
CN114928661A (zh) * | 2022-05-31 | 2022-08-19 | 杭州迪普科技股份有限公司 | 会话保持方法和装置 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7996543B2 (en) | Client-to-client direct RTP exchange in a managed client-server network | |
CN105100957A (zh) | 基于sip负载均衡实现高清视频多链路传输的方法 | |
US9357076B2 (en) | Load balancing of distributed media agents in a conference system | |
US9614687B2 (en) | Dynamic configuration of a conference system with distributed media agents | |
CN102571856B (zh) | 一种中转节点的选择方法、设备和系统 | |
CN100479415C (zh) | 一种实现数据通讯的系统及其方法 | |
CN103797769A (zh) | 基于服务受控会话的流拦截器 | |
US20180337862A1 (en) | Communications methods and apparatus | |
Montazerolghaem et al. | OpenSIP: Toward software-defined SIP networking | |
US8639844B2 (en) | System for establishing a media stream | |
CN102301681A (zh) | 经过网络地址转换(nat)设备的媒体流传输 | |
CN103200102B (zh) | 一种业务路由方法、装置和系统 | |
CN111435922B (zh) | 一种带宽共享方法 | |
CN102025594A (zh) | Nat环境下的路由动态调整方法和系统 | |
CN103916382B (zh) | 基于sip媒体能力重协商的nat穿越方法、代理服务器和系统 | |
CN109361606A (zh) | 一种报文处理系统及网络设备 | |
CN101197772B (zh) | 实现媒体面多路径的方法、装置和系统 | |
Karl et al. | Multimedia optimized routing in OpenFlow networks | |
CN101453349B (zh) | 一种处理实时流媒体协议的方法及系统 | |
CN101114985B (zh) | 编解码转换系统及方法 | |
CN104994067A (zh) | Sip网络访问rtsp监控网络的系统及方法 | |
Khlifi et al. | VoIP and NAT/firewalls: issues, traversal techniques, and a real-world solution | |
CN103516729A (zh) | 一种流媒体传输方法以及系统 | |
Al Farizky | Routing protocol RIPng, OSPFv3, and EIGRP on IPv6 for video streaming services | |
CN102752331B (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 | ||
WD01 | Invention patent application deemed withdrawn after publication |
Application publication date: 20151125 |
|
WD01 | Invention patent application deemed withdrawn after publication |