CN104660952A - 视频会议通信方法和系统 - Google Patents
视频会议通信方法和系统 Download PDFInfo
- Publication number
- CN104660952A CN104660952A CN201510096480.0A CN201510096480A CN104660952A CN 104660952 A CN104660952 A CN 104660952A CN 201510096480 A CN201510096480 A CN 201510096480A CN 104660952 A CN104660952 A CN 104660952A
- Authority
- CN
- China
- Prior art keywords
- network interface
- user side
- path
- user
- logical channel
- 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.)
- Granted
Links
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
- Telephonic Communication Services (AREA)
Abstract
一种视频会议通信方法和系统,该方法包括:获取第一用户端对应的第一网口;获取第二用户端对应的第二网口,其中第二用户端和第一用户端位于不同的网段或者不同运营商网络中;建立从第一网口到第二网口的第一转发路径和从第二网口到第二用户端的第二转发路径;按照第一转发路径将来自第一用户端的数据从第一网口转发到第二网口;按照第二转发路径将数据从第二网口转发到第二用户端。解决了现有跨网段或跨运营商网络的视频会议双方之间数据传输慢、实时性差的技术问题。本发明通过设置代理服务器建立专用转发路径提高了跨网段或跨运营商网络的视频会议双方之间的视音频数据转发速度。
Description
技术领域
本发明涉及视频会议实时传输技术领域。具体地说,涉及一种视频会议通信方法和系统。
背景技术
视频会议系统发展了数十年,到目前为止已经相当成熟和完善,但许多视频会议系统的应用环境都还是以部署在专网或局域网为主。随着互联网的进一步开发和开放,视频会议系统将开始被部署在包括专网、局域网和互联网等各种网络之上。如图1所示,会议系统中可能有位于各种网络环境的实体:通过运营商A接入的用户端(EndPoint)、通过运营商B接入的用户端、运营商C接入的用户端、192.168.*.*网段的用户端、10.*.*.*网段的用户端。而其中的视频会议代理服务器则需要负责接入整个会议系统中的多个点对点会议和多点会议。
而在中国国内,实际存在的多家不同的宽带接入运营商之间一直存在一些互通性差、跨网传输效率低下的问题,并且这些问题在短期之内无法彻底的、从运营商层级上得到解决。即便是排除国内多运营商之间网络互通差的问题,在实际的网络应用环境中,即使是所有终端都使用同一家运营商的网络也存在着速率不同的现象,如:使用城际网来进行接入和传输在效率上通常明显会比因特网高,使用局域网通常会比城际网和因特网效率高。为此,让这些运行在不同的网络环境的终端和用户进行网络互通并加速成为一个极其重要的课题,具备相当的研究意义。
当然,如果两条网络线路之间的数据传输不存在因跨网转发而导致传输速度慢及效率低的问题,该两条网络线路可由同一网口接入代理服务器。如图1中,两个位于不同网段(192.168.*.*网段和10.*.*.*网段)的用户端,因这两个网段之间的跨网数据转发不存在传输效率低下的问题,因此各用户端可由同一网口接入代理服务器。但是如果位于不同网段的用户端之间的跨网数据转发也存在传输效率低等问题,那么位于不同网段的用户端需要分别通过一个网口接入代理服务器(一个网段对应一个网口)。
目前为止,对跨网互通、跨网加速的研究主要集中的内容分发网络(CDN,Content Delivery Network)方面。然而CDN相对于视频会议之类的小型应用来说,其昂贵的价格、贵族式的服务并不是所有的用户都能使用得起。而且,CDN的主要应用领域为基于文件或者是基于可缓存的内容的分发,在诸如视频会议领域的实时视音频内容的分发与传输来讲,仍然存在着诸多改善的空间。
另外,针对类似图1所示的视频会议终端网络部署环境,虽然可以利用第三层交换技术虚拟局域网(VLAN)来实现跨网段及多运营商接入之间的通信,但那需要更换现有的部分网络设备,增加额外开销以及不可靠性。因此在此类应用场景中,本发明所要解决的技术问题是:在不需要额外的硬件成本的前提下,解决视频会议系统中位于多个网段及多个运营商接入的终端之间因网络传输原因而导致会议效果差的问题。
发明内容
为此,本发明所要解决的技术问题在于现有视频会议系统中位于多个网段及多个运营商接入的网络环境的终端之间因网络传输而导致视频会议的视音频数据传输速度慢的问题,从而提出一种通过设置代理服务器建立专用转发路径来提高数据转发速度的视频会议通信方法和系统。
为解决上述技术问题,本发明提供了如下技术方案:
一种视频会议通信方法,包括以下步骤:
获取第一用户端对应的第一网口;
获取第二用户端对应的第二网口,其中第二用户端和第一用户端位于不同的网段或者不同运营商网络中;
建立从第一网口到第二网口的第一转发路径和从第二网口到第二用户端的第二转发路径;
按照第一转发路径将来自第一用户端的数据从第一网口转发到第二网口;
按照第二转发路径将数据从第二网口转发到第二用户端。
优选地,获取第一用户端对应的第一网口的步骤包括:
接收第一用户端的注册请求;
根据接收第一用户端的注册请求的路径来确定第一用户端对应的第一网口。
优选地,在获取第一用户端对应的第一网口的步骤与建立第一转发路径的步骤之间,还包括:
生成针对第一用户端的第一转发路由,第一转发路由强制使所有发往第一用户端的数据全部发送给第一网口。
优选地,获取第二用户端对应的第二网口的步骤包括:
接收第二用户端的注册请求;
根据接收第二用户端的注册请求的路径来确定第二用户端对应的第二网口。
优选地,在获取第二用户端对应的第二网口的步骤与建立第二转发路径的步骤之间,还包括:
生成针对第二用户端的第二转发路由,第二转发路由强制使所有发往第二用户端的数据全部发送给第二网口。
优选地,建立第一转发路径和第二转发路径的步骤包括:
从第一网口接收第一用户端发送的打开逻辑通道请求;
将打开逻辑通道请求从第二网口发送给第二用户端;
从第二网口接收第二用户端发送的打开逻辑通道响应;
根据打开逻辑通道响应以及其从第二用户端发送到第二网口的传输路径创建第一转发规则,第一转发规则为将从第二网口接收到的且来自第一用户端的数据全部转发到第二用户端;
将从第二网口接收到的打开逻辑通道响应转发给第一网口;
根据打开逻辑通道响应以及其从第二网口发送到第一网口的传输路径创建第二转发规则,第二转发规则为将从第一网口接收到的且来自第一用户端的数据全部转发到第二网口;
按照第一转发规则建立从第二网口到第二用户端的第二转发路径,并且按照第二转发规则建立从第一网口到第二网口的第一转发路径。
优选地,还包括:
从第一网口接收第一用户端发送的呼叫挂断请求;
将呼叫挂断请求从第二网口转发给第二用户端;
从第二网口接收第二用户端发送的呼叫挂断确认回复;
删除第一转发规则;
将呼叫挂断确认回复转发给第一网口;
在第一网口接收到呼叫挂断确认回复后,删除第二转发规则;
将呼叫挂断确认回复转发给第一用户端。
一种视频会议通信系统,包括:
第一获取模块,获取第一用户端对应的第一网口;
第二获取模块,获取第二用户端对应的第二网口;
转发路径建立模块,建立从第一网口到第二网口的第一转发路径和从第二网口到第二用户端的第二转发路径;
第一转发模块,按照第一转发路径将来自第一用户端的数据从第一网口转发到第二网口;
第二转发模块,按照第二转发路径将数据从第二网口转发到第二用户端。
优选地,第一获取模块包括:
第一接收单元,接收第一用户端的注册请求;
第一确定单元,根据接收第一用户端的注册请求的路径来确定第一用户端对应的第一网口。
优选地,还包括:
第一转发路由生成模块,在第一获取模块获取第一用户端对应的第一网口与转发路径建立模块建立第一转发路径之间,生成针对第一用户端的第一转发路由,第一转发路由强制使所有发往第一用户端的数据全部发送给第一网口。
优选地,第二获取模块包括:
第二接收单元,接收第二用户端的注册请求;
第二确定单元,根据接收第二用户端的注册请求的路径来确定第二用户端对应的第二网口。
优选地,还包括:
第二转发路由生成模块,在第二获取模块获取第二用户端对应的第二网口与转发路径建立模块建立第二转发路径之间,生成针对第二用户端的第二转发路由,第二转发路由强制使所有发往第二用户端的数据全部发送给第二网口。
优选地,转发路径建立模块包括:
打开逻辑通道请求接收单元,从第一网口接收第一用户端发送的打开逻辑通道请求;
打开逻辑通道请求发送单元,将打开逻辑通道请求从第二网口发送给第二用户端;
打开逻辑通道响应接收单元,从第二网口接收第二用户端发送的打开逻辑通道响应;
第一转发规则创建单元,根据打开逻辑通道响应以及其从第二用户端发送到第二网口的传输路径创建第一转发规则,第一转发规则为将从第二网口接收到的且来自第一用户端的数据全部转发到第二用户端;
打开逻辑通道响应发送单元,将从第二网口接收到的打开逻辑通道响应转发给第一网口;
第二转发规则创建单元,根据打开逻辑通道响应以及其从第二网口发送到第一网口的传输路径创建第二转发规则,第二转发规则为将从第一网口接收到的且来自第一用户端的数据全部转发到第二网口;
转发路径建立单元,按照第一转发规则建立从第二网口到第二用户端的第二转发路径,并且按照第二转发规则建立从第一网口到第二网口的第一转发路径。
优选地,还包括:
呼叫挂断请求接收单元,从第一网口接收第一用户端发送的呼叫挂断请求;
呼叫挂断请求发送单元,将呼叫挂断请求从第二网口转发给第二用户端;
呼叫挂断确认回复接收单元,从第二网口接收第二用户端发送的呼叫挂断确认回复;
第一删除单元,删除第一转发规则;
第一呼叫挂断确认回复发送单元,将呼叫挂断确认回复转发给第一网口;
第二删除单元,在第一网口接收到呼叫挂断确认回复后,删除第二转发规则;
第二呼叫挂断确认回复发送单元,将呼叫挂断确认回复转发给第一用户端。
本发明的上述技术方案相比现有技术具有以下优点:
1.本发明提供的视频会议通信方法和系统,在不增加额外的网络设备情况下,利用一个代理服务器生成专用转发路径。在视频会议双方位于不同网段或者不同运营商网络中时,该专用转发路径使得数据的跨网转发直接在代理服务器一端完成,而数据在代理服务器与用户端之间的转发始终是以用户端对应的网络来传输的。从而在跨网段或者跨运营商网络的视频会议双方之间建立了一个视音频数据专用传输路径,极大地提高了该视频会议双方之间的数据传输速度,并减少数据传输的丢包率。
2.本发明提供的视频会议通信方法和系统,在用户端向代理服务器注册成功后,在代理服务器一侧会生成针对该用户端的转发路由,该转发路由强制使所有发往该用户端的数据全部走与该用户端对应的网口,解决了某些代理服务器因被NAT设备(防火墙、路由器等)规则限制而只能接收数据但不能发送数据的问题。
附图说明
图1是现有视频会议用户端的网络场景示意图;
图2是本发明实施例的一种视频会议系统结构示意图;
图3是本发明实施例的一种视频会议通信方法流程图;
图4是本发明实施例中用户端注册和呼叫过程示意图、信令与码流传输示意图;
图5是本发明实施例中用户端注册过程示意图;
图6是本发明实施例的建立转发路径过程流程图;
图7是本发明实施例中逻辑通道操作过程示意图;
图8是本发明实施例的一种视频会议通信系统框图。
具体实施方式
为了使本技术领域的人员更好地理解本发明的内容,下面结合附图和实施例对本发明所提供的技术方案作进一步的详细描述。
实施例1
图2示出了本发明实施例的视频会议系统结构示意图,作为视频会议双方的第一用户端和第二用户端分别位于不同网段或不同运营商网络中,其中,可以是第一用户端位于第一运营商的网络中、而第二用户端位于第二运营商的网络中,也可以是第一用户端位于第一网段的网络中、而第二用户端位于第二网段的网络中,还可以是第一用户端位于某一运营商的网络中、而第二用户端位于某一网段的网络中。视频会议双方通过代理服务器建立了双方之间的专用数据转发路径,其中该代理服务器拥有多张网卡,用于接入各运营商的网络,并为每张网卡分配相应运营商的公网IP地址;另外,还需要在该代理服务器上分配和配置各个网段的IP地址,用于接入位于不同网段的用户端。然后,各用户端需要根据本地实际接入的网络(可能是位于某一运营商的网络中,也可能是位于某一网段中),注册到服务器上与其接入网络相对应的IP地址(网口)上。本实施例中第一用户端和第二用户端,也即视频会议的用户端,可以是标准视频会议中的会议终端(MT)或多点控制器(MCU)等。在数据转发过程中,跨网段或跨运营商网络的过程由代理服务器来完成,而用户端到代理服务器之间的数据转发是由该用户端所对应的网络来完成的,从而加快了跨网段或跨运营商网络的视频会议双方之间的数据转发速度。对于代理服务器来说,不管接入其的用户端是跨网段还是跨运营商网络,其对用户端之间数据转发的处理方式是一样的。
如图3所示,本实施例提供了一种视频会议通信方法,包括以下步骤:
S11:获取第一用户端对应的第一网口。具体地获取过程为:代理服务器首先接收第一用户端的注册请求,然后根据接收第一用户端的注册请求的路径来确定第一用户端对应的第一网口。或者,也可以通过发送其他路由探测包给代理服务器,来获取第一用户端对应的网口。
S12:获取第二用户端对应的第二网口,其中第二用户端和第一用户端位于不同的网段或者不同运营商网络中。具体地获取过程为:代理服务器首先接收第二用户端的注册请求,然后根据接收第二用户端的注册请求的路径来确定第二用户端对应的第二网口。同样地,也可以通过发送其他路由探测包给代理服务器,来获取第二用户端对应的网口。
S13:建立从第一网口到第二网口的第一转发路径和从第二网口到第二用户端的第二转发路径,从而使得第一用户端能够向第二用户端发送数据。相应地,当第二用户端需要向第一用户端发送数据时,还需要建立从第二网口到第一网口的第三转发路径和从第一网口到第一用户端的第四转发路径。
S14:按照第一转发路径将来自第一用户端的数据从第一网口转发到第二网口。相应地,当第二用户端向第一用户端发送数据时,则是按照第三转发路径将来自第二用户端的数据从第二网口转发到第一网口。
S15:按照第二转发路径将数据从第二网口转发到第二用户端。相应地,当第二用户端向第一用户端发送数据时,则是按照第四转发路径将来自第二用户端的数据从第一网口转发到第一用户端。
本实施例提供的视频会议通信方法,在不增加额外的网络设备情况下,利用一个代理服务器生成专用转发路径。在视频会议双方位于不同网段或者不同运营商网络中时,该专用转发路径使得数据的跨网转发直接在代理服务器一端完成,而数据在代理服务器与用户端之间的转发始终是以用户端对应的网络来传输的。从而在跨网段或者跨运营商网络的视频会议双方之间建立了一个视音频数据专用传输路径,极大地提高了该视频会议双方之间的数据传输速度,而且减少数据传输的丢包率。
优选地,在步骤S11获取第一用户端对应的第一网口与步骤S13建立第一转发路径之间,还包括:
S01:生成针对第一用户端的第一转发路由,第一转发路由强制使所有发往第一用户端的数据全部发送给第一网口。
同样优选地,在步骤S12获取第二用户端对应的第二网口之后、且在步骤S13建立第二转发路径之前,还包括:
S02:生成针对第二用户端的第二转发路由,第二转发路由强制使所有发往第二用户端的数据全部发送给第二网口。
通过步骤S01和步骤S02中生成针对用户端的转发路由,可以防止某些代理服务器被NAT设备(防火墙、路由器等)规则限制,而使得其只能接收数据而不能将其接收的数据转发出去。该转发路由强制使所有发往该用户端的数据全部发往与该用户端对应的网口,这样就能将从一个用户端接收到的最终目的地是另一个用户端的数据发送到目的地用户端。并且,所有发往目的地用户端的数据在出代理服务器后直接走与该用户端对应的网络,从而保证了视频会议双方的视音频数据的传输速度。
本实施例中,上述步骤S11、S12、S01、S02是在用户端向代理服务器注册过程来完成的。要实现视频会议中视音频数据的转发,其用户端必须向代理服务器进行注册,因此本实施例可直接通过用户端的注册过程来确定其在服务器上对应的网口,就不用另外发送路由探测包来确定用户端对应的网口了。在注册之前,各用户端须先知道自己的网络接入运营商以及代理服务器上对应该运营商的IP地址,或者自己所在的网段以及代理服务器上对应该网段的IP地址,然后根据该IP地址向代理服务器发起注册请求。注册过程和内容以TCP方式进行传输。如图4所示,具体的注册过程如下:
1)用户端发起RRQ(Regis ter Request,注册请求)。
2)代理服务器收到注册请求后,判断该请求内容数据是否合法有效,同时根据代理服务器上收到该注册请求的网口确定发送该注册请求的用户端所对应的网口。具体地,如图5所示,代理服务器在收到一个注册请求时,可以知道该注册请求所对应的用户端的多项相关信息,包括:本地地址信息,即用户端自身的IP和端口(可能为一个局域网IP)、及该用户端的H.323Alias ID;该注册请求的来源地址信息,即用户端出网的路由器上的NAT IP及端口;目的地址信息,即代理服务器上收到该注册请求的网口的IP及端口。本实施例中,第一用户端自身地址为AddrA1,第一用户端出网地址为AddrA2,代理服务器上接收到注册请求的地址为AddrA3,代理服务器上接收到注册请求的网口为EthA;第二用户端自身地址为AddrB1,第二用户端出网地址为AddrB2,代理服务器上接收到注册请求的地址为AddrB3,代理服务器上接收到注册请求的网口为EthB。其中,若第一用户端具备公网IP,则AddrA1与AddrA2相等;若第二用户端具备公网IP,则AddrB1与AddrB2相等。那么,确定第一用户端在代理服务器上所对应的网口即为EthA、第二用户端在代理服务器上所对应的网口即为EthB。
3a)若判定该注册请求无效,返回注册失败。
3b)若判定该注册请求有效,代理服务器开始自动生成针对注册请求用户端的转发路由,该转发路由即为:强制使所有发往AddrA2(或AddrB2)(若该用户端具备公网IP,也即AddrA1或AddrB1)的数据全部先发送给网口EthA(或EthB)。在后续的视音频数据传输阶段,该转发路由使得所有发往该注册请求用户端的数据全部发往该用户端所对应的网口。
4a)若生成转发路由失败,返回注册失败。
4b)若生成转发路由成功,返回注册成功。
用户端在收到代理服务器的注册成功响应后,将开启一个定时器,定时向服务器进行注册保活,即发送心跳包。
在上述步骤S13中,第一转发路径和第二转发路径是通过呼叫过程建立的,具体是通过呼叫过程中的逻辑通道协商操作建立的。呼叫的建立与结束以TCP方式进行传输,且与注册过程共用同一个TCP连接。在进行此步骤前,必须先确保用户端已经成功地在代理服务器上完成注册。执行呼叫时,主呼方用户端(第一用户端)的呼叫目的地址是代理服务器,在发送到代理服务器的呼叫请求中包含其真正呼叫的被呼方用户端(第二用户端)信息。如图4所示,呼叫过程具体如下:
1)主呼方用户端发送呼叫请求到代理服务器,其中,这个呼叫请求所使用的协议可以为任意格式,可以是标准H.323的协议格式,也可以是其他的自定义协议格式;
2)代理服务器从主呼方用户端所对应的第一网口收到呼叫请求;
3)代理服务器对收到的呼叫请求内容进行解析和核验,并根据呼叫相关信息(如:Socket句柄信息,及呼叫请求所携带的主、被呼方信息等)判断该请求是否合法有效;
4a)若判定该呼叫请求为无效的呼叫请求,代理服务器将直接给主呼方用户端返回呼叫失败;
4b)若判定该呼叫请求合法有效,再提取3)中解析得出的被呼方用户端信息,对被呼方用户端的注册状态进行检验;
5a)若被呼方用户端未在服务器上注册,代理服务器将直接给主呼方用户端返回呼叫失败;
5b)若检测到被呼方用户端(第二用户端)也在代理服务器上注册并存活,就把这个来自主呼方用户端的呼叫请求转发到被呼方用户端所对应的网口;
6)被呼方用户端收到代理服务器转发过来的呼叫请求,可自行决定是接受呼叫,还是拒绝该呼叫;
7)被呼方用户端的呼叫响应(无论是接受还是拒绝)都将沿着呼叫请求的路径返回。
上述整个呼叫过程至少需要包括设置(SETUP)、连接(CONNECT)、主从判断(MasterSlaveDetermination)、终端能力集(terminalCapabilitySet)协商等多个请求命令或者步骤来完成。
如图6和7所示,逻辑通道的协商决定了视频会议双方之间的数据转发规则,在单个成功的逻辑通道请求中将创建两个转发规则,而转发规则将直接关系数据转发。通过逻辑通道协商操作建立第一转发路径和第二转发路径的步骤,即步骤S13具体包括:
S131:代理服务器从第一网口接收第一用户端(主呼方用户端)发送的打开逻辑通道请求。代理服务器解析该打开逻辑通道请求后可以知道该打开逻辑通道请求所对应的主呼方用户端的RTP/RTCP视音频包发送地址,假定分别为AddrRTPA和AddrRTCPA,此为主呼方用户端向被呼方用户端发送视音频数据的源地址,同时也是主呼方用户端接收视音频数据的地址。
S132:代理服务器将打开逻辑通道请求从第二网口发送给第二用户端(被呼方用户端)。具体地,代理服务器首先将该打开逻辑通道请求转发到被呼方用户端所对应的第二网口,然后将打开逻辑通道请求从第二网口转发给被呼方用户端。被呼方用户端接收该打开逻辑通道请求后,根据打开逻辑通道请求中的参数决定是否接受主呼方用户端的打开逻辑通道请求,并回复打开逻辑通道响应给代理服务器的第二网口。
S133:代理服务器从第二网口接收被呼方用户端发送的打开逻辑通道响应。若打开逻辑通道响应为允许,解析该打开逻辑通道响应后可知道被呼方用户端将接收来自主呼方用户端的RTP/RTCP视音频包的地址,假定分别为AddrRTPB和AddrRTCPB,此为主呼方用户端向被呼方用户端发送视音频数据的目的地址,即被呼方用户端接收视音频数据的地址,同时也是被呼方用户端发送视音频数据的地址。
S134:根据打开逻辑通道响应以及其从第二用户端(被呼方用户端)发送到第二网口的传输路径创建第一转发规则,第一转发规则为将从第二网口接收到的且来自第一用户端(主呼方用户端)的数据全部转发到第二用户端
(被呼方用户端)。具体地,如果该打开逻辑通道响应为允许,代理服务器将自动创建视音频RTP/RTCP第一转发规则:用于把在第二网口上收到的且实际来源为AddrRTPA/AddrRTCPA(即作为主呼方用户端的第一用户端)的RTP/RTCP视音频包全部转发到AddrRTPB和AddrRTCPB(即作为被呼方用户端的第二用户端),该RTP/RTCP视音频包实际是从主呼方用户端对应的第一网口转发给第二网口的;若打开逻辑通道响应为拒绝,直接进入步骤S135。
S135:代理服务器将从第二网口接收到的打开逻辑通道响应转发给打开逻辑通道请求方(即作为主呼方用户端的第一用户端)所对应的第一网口。
S136:根据打开逻辑通道响应以及其从第二网口发送到第一网口的传输路径创建第二转发规则,第二转发规则为将从第一网口接收到的且来自第一用户端的数据全部转发到第二网口。具体地,若打开逻辑通道响应为允许,代理服务器将再自动创建一个视音频RTP/RTCP第二转发规则:用于把在第一网口上接收到的且实际来源为AddrRTPA和AddrRTCPA(即作为主呼方用户端的第一用户端)的RTP/RTCP视音频包,全部转发到第二网口;若打开逻辑通道响应为拒绝,则代理服务器将直接把该打开逻辑通道响应转发给主呼方用户端(即第一用户端)。
S137:按照第一转发规则建立从第二网口到第二用户端的第二转发路径,并且按照第二转发规则建立从第一网口到第二网口的第一转发路径。
本实施例中,通过逻辑通道协商操作建立了上述两个转发规则,进而建立了步骤S137中所述的两个转发路径,该两个转发路径即相当于在代理服务器上建立了一个专供跨网段或者跨运营商网络的视频会议双方的视音频数据使用的传输通道,由代理服务器来实现视音频数据的跨网转发,从而解决了因不同网络的互通性差、跨网传输效率低而导致视频会议双方的视音频数据传输慢、实时性差的问题,提高了跨网段或者跨运营商网络的视频会议双方之间的数据传输速度。
上述是第一用户端作为主呼方用户端、第二用户端作为被呼方用户端时,建立两个转发路径的具体过程。而视频会议是双向的视音频交互,那么反向的,被呼方用户端(第二用户端)向主呼方用户端(第一用户端)打开逻辑通道的过程,也同上面的主呼方用户端向被呼方用户端打开逻辑通道的过程,具体过程如下:
1)被呼方用户端向代理服务器上与其对应的第二网口发送打开逻辑通道请求,代理服务器从第二网口接收被呼方用户端发送的打开逻辑通道请求;
2)代理服务器首先将打开逻辑通道请求转发至主呼方用户端所对应第一网口,然后将第一网口收到的打开逻辑通道请求转发给主呼方用户端,主呼方用户端接收该打开逻辑通道请求后根据该打开逻辑通道请求参数决定是否接受请求,并回复打开逻辑通道响应给第一网口;
3)代理服务器从第一网口收到主呼方用户端的打开逻辑通道响应。
4)若上述打开逻辑通道响应为允许,代理服务器则自动创建视音频RTP/RTCP第三转发规则:用于把在第一网口上收到的且实际来源为AddrRTPB和AddrRTCPB(即被呼方)的RTP/RTCP视音频包全部转发到AddrRTPA和AddrRTCPA(也即主呼方),该RTP/RTCP视音频包实际是从被呼方用户端对应的第二网口转发给第一网口的;
5)代理服务器将该打开逻辑通道响应转发至被呼方用户端所对应的第二网口;
6)代理服务器的第二网口接收到第一网口转发过来的打开逻辑通道响应后,若该打开逻辑通道响应为允许,则代理服务器将自动创建视音频RTP/RTCP第四转发规则:用于把在第二网口上收到的且实际来源为AddrRTPB和AddrRTCPB的RTP/RTCP视音频包全部转发到第一网口,最后代理服务器将该打开逻辑通道响应发送给被呼方用户端;
7)按照第三转发规则建立从第一网口到第一用户端的第四转发路径,并且按照第四转发规则建立从第二网口到第一网口的第三转发路径。
如上述步骤S14和S15,视音频数据按照上述四个转发路径在视频会议双方之间快速转发。即相当于视音频数据在视频会议双方之间的转发是通过专用通道的,因此与现有技术中跨运营商网络或跨网段的视音频数据传输相比其传输速度很快。其中,视频会议数据以UDP方式进行传输,视频会议数据传输协议与一般的H.323或者是SIP视频会议遵循同样的协议标准,也即用RTPover UDP协议来进行传输,再加上RTCP来做传输控制和传输服务质量(QoS)控制。
另外,为了实现按上述方法进行视音频数据传输,本实施例将数据流划分为信令和码流两类,其中,信令主要包括用户端注册过程中的请求以及响应、呼叫过程中的请求以及响应、打开逻辑通道操作过程中的请求以及响应,而码流主要包括视频会议进行中的视音频数据。数据流的传输方式有TCP和UDP两种。其中,信令是以TCP方式进行传输的,所有的信令传输共用一个TCP的长连接;而码流是用UDP辅以RTP的载荷来进行传输的,同时会利用RTCP与之配套以利于码流实时传输的控制。如图4所示。
对于用户端来说,视音频数据的传输与信令部分一致的地方是:用户端发送的数据其目的地永远是代理服务器上与该用户端对应的那个网口,且用户端所接收的数据其来源地也将一直是代理服务器上与该用户端对应的那个网口。
转发路由的生成由注册及呼叫信令所使用的TCP长连接在其注册时生成。UDP(RTP/RTCP)视音频数据的转发规则是根据逻辑通道协商中的打开逻辑通道请求及其响应的IP及端口来生成。视音频数据转发功能是利用RAW_SOCKET来实现,通过修改UDP头的来源地址信息,以配合RTP/RTCP数据的转发规则来进行转发。
另外,在视频会议进行中,还包括视频会议挂断的过程,视频会议挂断的原因有以下几种:
1)主呼方用户端挂断;
2)被呼方用户端挂断;
3)代理服务器手动强制挂断;
4)网闸(Gatekeeper)因流量或授权触发DRQ强拆导致视频会议挂断;
5)会议双方的往返延迟(Round Trip Delay)超时导致挂断。
其中,主呼方用户端(例如,第一用户端)挂断的过程包括:
1)主呼方用户端(例如,第一用户端)发送呼叫挂断请求到代理服务器的第一网口,代理服务器从第一网口接收该呼叫挂断请求;
2)代理服务器将从第一网口上接收到的呼叫挂断请求首先转发给第二网口,并从第二网口转发给被呼方用户端(例如,第二用户端);
3)被呼方用户端(例如,第二用户端)对接收到的呼叫挂断请求进行确认,并发送呼叫挂断确认回复给第二网口,代理服务器从第二网口接收呼叫挂断确认回复;
4)代理服务器从第二网口接收到被呼方用户端(例如,第二用户端)的呼叫挂断确认回复后,将删除在逻辑通道协商过程中创建的第一转发规则,因视频会议是双向的视音频交互,那么相应地,此时也将删除在逻辑通道协商过程中创建的第四转发规则;
5)代理服务器将该呼叫挂断确认回复转发给第一网口;
6)代理服务器在第一网口接收到该呼叫挂断确认回复后,将删除在逻辑通道协商过程中创建的第二转发规则,同上,此时也将删除第三转发规则;
7)代理服务器将该呼叫挂断确认回复转发给主呼方用户端(例如,第一用户端)。
另外,被呼方用户端(例如,第二用户端)挂断的过程包括:
1)被呼方用户端(例如,第二用户端)发送呼叫挂断请求到代理服务器的第二网口,代理服务器从第二网口接收该呼叫挂断请求;
2)代理服务器将从第二网口上接收到的呼叫挂断请求首先转发给第一网口,并从第一网口转发给主呼方用户端(例如,第一用户端);
3)主呼方用户端(例如,第一用户端)对接收到的呼叫挂断请求进行确认,并发送呼叫挂断确认回复给第一网口,代理服务器从第一网口接收呼叫挂断确认回复;
4)代理服务器从第一网口接收到主呼方用户端(例如,第一用户端)的呼叫挂断确认回复后,将删除在逻辑通道协商过程中创建的第二转发规则和第三转发规则;
5)代理服务器将该呼叫挂断确认回复转发给第二网口;
6)代理服务器在第二网口接收到该呼叫挂断确认回复后,将删除在逻辑通道协商过程中创建的第一转发规则和第四转发规则;
7)代理服务器将该呼叫挂断确认回复转发给被呼方用户端(例如,第二用户端)。
本实施例中,还包括用户端注销的过程,触发用户端注销有四种情况:
1)注册所对应的TCP socket连接异常断开;
2)用户端主动发送注销命令;
3)代理服务器超时未收到用户端的保活数据包,从而注销;
4)代理服务器强制注销某一用户端。
用户端注销的结果:代理服务器将删除该用户端的相关信息,包括该用户端的记录、与该用户端相对应的转发路由。
实际应用中,视频会议的用户端可能会位于各种不同的网络环境,视频会议通信方法需要适用于多种不同的网络场景,本实施例提供的视频会议通信方法适用的网络场景包括:
1)会议双方位于不同的宽带运营商线路,且主呼方和被呼方的网络都是私网;
2)会议双方位于不同的宽带运营商线路,且主呼方位于私网,被呼方位于公网;
3)会议双方位于不同的宽带运营商线路,且主呼方位于公网,被呼方位于私网;
4)会议双方位于不同的宽带运营商线路,且主呼方和被呼方都位于公网。
针对上述网络场景,利用本实施例提供的视频会议数据转发的方法进行视频会议双方之间的视音频数据转发时,主呼方和被呼方注册于代理服务器不同的网口,代理服务器将分别创建针对主呼方和被呼方的2个强制转发路由以及4个转发规则。其中,“私网”表示位于路由交换设备后面、位于NAT后面的局域网环境;“公网”表示是一个Internet可以直接访问到的网络环境。
实施例2
如图8所示,本实施例提供了一种视频会议通信系统,包括:
第一获取模块M1,获取第一用户端对应的第一网口;
第二获取模块M2,获取第二用户端对应的第二网口;
转发路径建立模块M3,建立从第一网口到第二网口的第一转发路径和从第二网口到第二用户端的第二转发路径;
第一转发模块M4,按照第一转发路径将来自第一用户端的数据从第一网口转发到第二网口;
第二转发模块M5,按照第二转发路径将数据从第二网口转发到第二用户端。
本实施例提供的视频会议通信系统,在不增加额外的网络设备情况下,利用一个代理服务器生成专用转发路径。在视频会议双方位于不同网段或者不同运营商网络中时,该专用转发路径使得数据的跨网转发直接在代理服务器一端完成,而数据在代理服务器与用户端之间的转发始终是以用户端对应的网络来传输的。从而在跨网段或者跨运营商网络的视频会议双方之间建立了一个视音频数据专用传输路径,极大地提高了该视频会议双方之间的数据传输速度,而且减少数据传输的丢包率。
具体地,第一获取模块M1包括:
第一接收单元,接收第一用户端的注册请求;
第一确定单元,根据接收第一用户端的注册请求的路径来确定第一用户端对应的第一网口。
具体地,第二获取模块M2包括:
第二接收单元,接收第二用户端的注册请求;
第二确定单元,根据接收第二用户端的注册请求的路径来确定第二用户端对应的第二网口。
代理服务器在收到一个注册请求时,可以知道发送该注册请求的用户端的相关信息,包括用户端自身的地址及其出网的地址、代理服务器收到该注册请求的网口。
优选地,上述系统还包括:
第一转发路由生成模块,在第一获取模块获取第一用户端对应的第一网口与转发路径建立模块建立第一转发路径之间,生成针对第一用户端的第一转发路由,第一转发路由强制使所有发往第一用户端的数据全部发送给第一网口。
优选地,上述系统还包括:
第二转发路由生成模块,在第二获取模块获取第二用户端对应的第二网口与转发路径建立模块建立第二转发路径之间,生成针对第二用户端的第二转发路由,第二转发路由强制使所有发往第二用户端的数据全部发送给第二网口。
为了防止某些代理服务器被限制,而使得其只能接收数据而不能将其接收的数据转发出去。本实施例中,在用户端向代理服务器注册成功后,在代理服务器一侧会由转发路由生成模块生成针对该用户端的转发路由,该转发路由强制使所有发往该用户端的数据全部走与该用户端对应的网口。并且,所有发往该用户端的数据在出代理服务器后直接走与该用户端对应的网络,从而保证了视频会议双方的视音频数据的传输速度。
优选地,转发路径建立模块M3包括:
打开逻辑通道请求接收单元,从第一网口接收第一用户端发送的打开逻辑通道请求;
打开逻辑通道请求发送单元,将打开逻辑通道请求从第二网口发送给第二用户端;
打开逻辑通道响应接收单元,从第二网口接收第二用户端发送的打开逻辑通道响应;
第一转发规则创建单元,根据打开逻辑通道响应以及其从第二用户端发送到第二网口的传输路径创建第一转发规则,第一转发规则为将从第二网口接收到的且来自第一用户端的数据全部转发到第二用户端;
打开逻辑通道响应发送单元,将从第二网口接收到的打开逻辑通道响应转发给第一网口;
第二转发规则创建单元,根据打开逻辑通道响应以及其从第二网口发送到第一网口的传输路径创建第二转发规则,第二转发规则为将从第一网口接收到的且来自第一用户端的数据全部转发到第二网口;
转发路径建立单元,按照第一转发规则建立从第二网口到第二用户端的第二转发路径,并且按照第二转发规则建立从第一网口到第二网口的第一转发路径。
上述系统通过逻辑通道的协商来创建第一转发规则和第二转发规则,从而按照第一转发规则来建立第二转发路径、按照第二转发规则来建立第一转发路径。第一用户端通过代理服务器发送打开逻辑通道请求给第二用户端后,只有第二用户端确认允许建立逻辑通道并代理服务器在第二网口接收到该打开逻辑通道响应时才会创建第二网口到第二用户端之间的第一转发规则。只有在第一网口接收到从第二网口转发过来的该打开逻辑通道响应时,代理服务器才会创建第一网口到第二网口之间的第二转发规则。
另外地,该视频会议通信系统还包括视频会议挂断模块,具体包括:
呼叫挂断请求接收单元,从第一网口接收第一用户端发送的呼叫挂断请求;
呼叫挂断请求发送单元,将呼叫挂断请求从第二网口转发给第二用户端;
呼叫挂断确认回复接收单元,从第二网口接收第二用户端发送的呼叫挂断确认回复;
第一删除单元,删除第一转发规则;
第一呼叫挂断确认回复发送单元,将呼叫挂断确认回复转发给第一网口;
第二删除单元,在第一网口接收到呼叫挂断确认回复后,删除第二转发规则;
第二呼叫挂断确认回复发送单元,将呼叫挂断确认回复转发给第一用户端。
上述视频会议挂断模块用于在视频会议结束时,主呼方用户端主动挂断视频会议。
显然,上述实施例仅仅是为清楚地说明所作的举例,而并非对实施方式的限定。对于所属领域的普通技术人员来说,在上述说明的基础上还可以做出其它不同形式的变化或变动。这里无需也无法对所有的实施方式予以穷举。而由此所引伸出的显而易见的变化或变动仍处于本发明创造的保护范围之中。
Claims (14)
1.一种视频会议通信方法,其特征在于包括以下步骤:
获取第一用户端对应的第一网口;
获取第二用户端对应的第二网口,其中所述第二用户端和所述第一用户端位于不同的网段或者不同运营商网络中;
建立从所述第一网口到所述第二网口的第一转发路径和从所述第二网口到所述第二用户端的第二转发路径;
按照所述第一转发路径将来自所述第一用户端的数据从所述第一网口转发到所述第二网口;
按照所述第二转发路径将所述数据从所述第二网口转发到所述第二用户端。
2.如权利要求1所述的方法,其特征在于,所述获取第一用户端对应的第一网口的步骤包括:
接收所述第一用户端的注册请求;
根据接收所述第一用户端的注册请求的路径来确定所述第一用户端对应的第一网口。
3.如权利要求1所述的方法,其特征在于,在所述获取第一用户端对应的第一网口的步骤与所述建立第一转发路径的步骤之间,还包括:
生成针对所述第一用户端的第一转发路由,所述第一转发路由强制使所有发往第一用户端的数据全部发送给所述第一网口。
4.如权利要求1所述的方法,其特征在于,所述获取第二用户端对应的第二网口的步骤包括:
接收所述第二用户端的注册请求;
根据接收所述第二用户端的注册请求的路径来确定所述第二用户端对应的第二网口。
5.如权利要求1所述的方法,其特征在于,在所述获取第二用户端对应的第二网口的步骤与所述建立第二转发路径的步骤之间,还包括:
生成针对所述第二用户端的第二转发路由,所述第二转发路由强制使所有发往第二用户端的数据全部发送给所述第二网口。
6.如权利要求1-5中任一项所述的方法,其特征在于,所述建立第一转发路径和第二转发路径的步骤包括:
从所述第一网口接收所述第一用户端发送的打开逻辑通道请求;
将所述打开逻辑通道请求从所述第二网口发送给所述第二用户端;
从所述第二网口接收所述第二用户端发送的打开逻辑通道响应;
根据所述打开逻辑通道响应以及其从所述第二用户端发送到所述第二网口的传输路径创建第一转发规则,所述第一转发规则为将从所述第二网口接收到的且来自所述第一用户端的数据全部转发到所述第二用户端;
将从所述第二网口接收到的所述打开逻辑通道响应转发给所述第一网口;
根据所述打开逻辑通道响应以及其从所述第二网口发送到所述第一网口的传输路径创建第二转发规则,所述第二转发规则为将从所述第一网口接收到的且来自所述第一用户端的数据全部转发到所述第二网口;
按照所述第一转发规则建立从所述第二网口到所述第二用户端的第二转发路径,并且按照所述第二转发规则建立从所述第一网口到所述第二网口的第一转发路径。
7.如权利要求6所述的方法,其特征在于,还包括:
从所述第一网口接收所述第一用户端发送的呼叫挂断请求;
将所述呼叫挂断请求从所述第二网口转发给所述第二用户端;
从所述第二网口接收所述第二用户端发送的呼叫挂断确认回复;
删除所述第一转发规则;
将所述呼叫挂断确认回复转发给所述第一网口;
在所述第一网口接收到所述呼叫挂断确认回复后,删除所述第二转发规则;
将所述呼叫挂断确认回复转发给所述第一用户端。
8.一种视频会议通信系统,其特征在于包括:
第一获取模块,获取第一用户端对应的第一网口;
第二获取模块,获取第二用户端对应的第二网口;
转发路径建立模块,建立从所述第一网口到所述第二网口的第一转发路径和从所述第二网口到所述第二用户端的第二转发路径;
第一转发模块,按照所述第一转发路径将来自所述第一用户端的数据从所述第一网口转发到所述第二网口;
第二转发模块,按照所述第二转发路径将所述数据从所述第二网口转发到所述第二用户端。
9.如权利要求8所述的系统,其特征在于,所述第一获取模块包括:
第一接收单元,接收所述第一用户端的注册请求;
第一确定单元,根据接收所述第一用户端的注册请求的路径来确定所述第一用户端对应的第一网口。
10.如权利要求8所述的系统,其特征在于,还包括:
第一转发路由生成模块,在所述第一获取模块获取所述第一用户端对应的所述第一网口与所述转发路径建立模块建立第一转发路径之间,生成针对所述第一用户端的第一转发路由,所述第一转发路由强制使所有发往第一用户端的数据全部发送给所述第一网口。
11.如权利要求8所述的系统,其特征在于,所述第二获取模块包括:
第二接收单元,接收所述第二用户端的注册请求;
第二确定单元,根据接收所述第二用户端的注册请求的路径来确定所述第二用户端对应的第二网口。
12.如权利要求8所述的系统,其特征在于,还包括:
第二转发路由生成模块,在所述第二获取模块获取所述第二用户端对应的所述第二网口与所述转发路径建立模块建立第二转发路径之间,生成针对所述第二用户端的第二转发路由,所述第二转发路由强制使所有发往第二用户端的数据全部发送给所述第二网口。
13.如权利要求8-12中任一项所述的系统,其特征在于,所述转发路径建立模块包括:
打开逻辑通道请求接收单元,从所述第一网口接收所述第一用户端发送的打开逻辑通道请求;
打开逻辑通道请求发送单元,将所述打开逻辑通道请求从所述第二网口发送给所述第二用户端;
打开逻辑通道响应接收单元,从所述第二网口接收所述第二用户端发送的打开逻辑通道响应;
第一转发规则创建单元,根据所述打开逻辑通道响应以及其从所述第二用户端发送到所述第二网口的传输路径创建第一转发规则,所述第一转发规则为将从所述第二网口接收到的且来自所述第一用户端的数据全部转发到所述第二用户端;
打开逻辑通道响应发送单元,将从所述第二网口接收到的所述打开逻辑通道响应转发给所述第一网口;
第二转发规则创建单元,根据所述打开逻辑通道响应以及其从所述第二网口发送到所述第一网口的传输路径创建第二转发规则,所述第二转发规则为将从所述第一网口接收到的且来自所述第一用户端的数据全部转发到所述第二网口;
转发路径建立单元,按照所述第一转发规则建立从所述第二网口到所述第二用户端的第二转发路径,并且按照所述第二转发规则建立从所述第一网口到所述第二网口的第一转发路径。
14.如权利要求13所述的系统,其特征在于,还包括:
呼叫挂断请求接收单元,从所述第一网口接收所述第一用户端发送的呼叫挂断请求;
呼叫挂断请求发送单元,将所述呼叫挂断请求从所述第二网口转发给所述第二用户端;
呼叫挂断确认回复接收单元,从所述第二网口接收所述第二用户端发送的呼叫挂断确认回复;
第一删除单元,删除所述第一转发规则;
第一呼叫挂断确认回复发送单元,将所述呼叫挂断确认回复转发给所述第一网口;
第二删除单元,在所述第一网口接收到所述呼叫挂断确认回复后,删除所述第二转发规则;
第二呼叫挂断确认回复发送单元,将所述呼叫挂断确认回复转发给所述第一用户端。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201510096480.0A CN104660952B (zh) | 2015-03-04 | 2015-03-04 | 视频会议通信方法和系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201510096480.0A CN104660952B (zh) | 2015-03-04 | 2015-03-04 | 视频会议通信方法和系统 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN104660952A true CN104660952A (zh) | 2015-05-27 |
CN104660952B CN104660952B (zh) | 2018-06-08 |
Family
ID=53251594
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201510096480.0A Active CN104660952B (zh) | 2015-03-04 | 2015-03-04 | 视频会议通信方法和系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN104660952B (zh) |
Cited By (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN107172378A (zh) * | 2017-04-19 | 2017-09-15 | 苏州科达科技股份有限公司 | 多媒体会议系统、网守服务器及路由配置方法 |
CN107682384A (zh) * | 2016-08-01 | 2018-02-09 | 中兴通讯股份有限公司 | 虚拟桌面组播控制方法、终端、代理终端及云桌面服务器 |
CN108347622A (zh) * | 2018-03-06 | 2018-07-31 | 腾讯科技(深圳)有限公司 | 多媒体数据推送方法、装置、存储介质及设备 |
CN108881798A (zh) * | 2017-12-29 | 2018-11-23 | 北京视联动力国际信息技术有限公司 | 一种利用桥接服务器进行跨视联网会议方法和系统 |
CN110022458A (zh) * | 2018-01-08 | 2019-07-16 | 北京视联动力国际信息技术有限公司 | 一种监控处理方法和装置 |
CN110300277A (zh) * | 2018-03-21 | 2019-10-01 | 北京视联动力国际信息技术有限公司 | 一种基于视联网的数据转发方法及装置 |
CN111083572A (zh) * | 2019-11-28 | 2020-04-28 | 武汉兴图新科电子股份有限公司 | 基于多平台网络监测动态调整媒体传输的方法 |
CN111163040A (zh) * | 2018-11-08 | 2020-05-15 | 浙江宇视科技有限公司 | 一种重协商的会话重建方法及装置 |
WO2021012780A1 (zh) * | 2019-07-22 | 2021-01-28 | 中兴通讯股份有限公司 | 一种视频会议控制方法及装置 |
WO2021047513A1 (zh) * | 2019-09-10 | 2021-03-18 | 中兴通讯股份有限公司 | 一种视频会议通信方法、装置以及计算机可读存储介质 |
CN112804478A (zh) * | 2021-04-07 | 2021-05-14 | 浙江华创视讯科技有限公司 | 一种视频会议服务器,及数据处理方法、装置 |
Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1523834A (zh) * | 2003-02-20 | 2004-08-25 | ��Ϊ��������˾ | Ip网络业务质量保证方法及系统 |
US20070297423A1 (en) * | 2000-04-06 | 2007-12-27 | The Distribution Systems Research Institute | Terminal-to-terminal communication connection control method using IP transfer network |
CN101188582A (zh) * | 2006-11-17 | 2008-05-28 | 中兴通讯股份有限公司 | 穿越异构网络进行h.323终端通讯的系统和方法 |
CN101662375A (zh) * | 2008-08-27 | 2010-03-03 | 中兴通讯股份有限公司 | 基于多媒体会议的交互方法、多媒体会议系统 |
CN101753329A (zh) * | 2009-12-25 | 2010-06-23 | 深圳华为通信技术有限公司 | 呼叫建立的方法、装置和系统 |
CN101867586A (zh) * | 2010-06-29 | 2010-10-20 | 中兴通讯股份有限公司 | 实现会议电视系统跨网段信令互通的方法及系统 |
US20140344913A1 (en) * | 2012-01-17 | 2014-11-20 | IPalive AB | Device, software module, system or business method for global real-time |
-
2015
- 2015-03-04 CN CN201510096480.0A patent/CN104660952B/zh active Active
Patent Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20070297423A1 (en) * | 2000-04-06 | 2007-12-27 | The Distribution Systems Research Institute | Terminal-to-terminal communication connection control method using IP transfer network |
CN1523834A (zh) * | 2003-02-20 | 2004-08-25 | ��Ϊ��������˾ | Ip网络业务质量保证方法及系统 |
CN101188582A (zh) * | 2006-11-17 | 2008-05-28 | 中兴通讯股份有限公司 | 穿越异构网络进行h.323终端通讯的系统和方法 |
CN101662375A (zh) * | 2008-08-27 | 2010-03-03 | 中兴通讯股份有限公司 | 基于多媒体会议的交互方法、多媒体会议系统 |
CN101753329A (zh) * | 2009-12-25 | 2010-06-23 | 深圳华为通信技术有限公司 | 呼叫建立的方法、装置和系统 |
CN101867586A (zh) * | 2010-06-29 | 2010-10-20 | 中兴通讯股份有限公司 | 实现会议电视系统跨网段信令互通的方法及系统 |
US20140344913A1 (en) * | 2012-01-17 | 2014-11-20 | IPalive AB | Device, software module, system or business method for global real-time |
Cited By (18)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN107682384A (zh) * | 2016-08-01 | 2018-02-09 | 中兴通讯股份有限公司 | 虚拟桌面组播控制方法、终端、代理终端及云桌面服务器 |
CN107172378A (zh) * | 2017-04-19 | 2017-09-15 | 苏州科达科技股份有限公司 | 多媒体会议系统、网守服务器及路由配置方法 |
CN107172378B (zh) * | 2017-04-19 | 2019-10-01 | 苏州科达科技股份有限公司 | 多媒体会议系统、网守服务器及路由配置方法 |
CN108881798A (zh) * | 2017-12-29 | 2018-11-23 | 北京视联动力国际信息技术有限公司 | 一种利用桥接服务器进行跨视联网会议方法和系统 |
CN108881798B (zh) * | 2017-12-29 | 2019-05-17 | 视联动力信息技术股份有限公司 | 一种利用桥接服务器进行跨视联网会议方法和系统 |
CN110022458A (zh) * | 2018-01-08 | 2019-07-16 | 北京视联动力国际信息技术有限公司 | 一种监控处理方法和装置 |
CN108347622A (zh) * | 2018-03-06 | 2018-07-31 | 腾讯科技(深圳)有限公司 | 多媒体数据推送方法、装置、存储介质及设备 |
CN108347622B (zh) * | 2018-03-06 | 2020-06-30 | 腾讯科技(深圳)有限公司 | 多媒体数据推送方法、装置、存储介质及设备 |
CN110300277A (zh) * | 2018-03-21 | 2019-10-01 | 北京视联动力国际信息技术有限公司 | 一种基于视联网的数据转发方法及装置 |
CN110300277B (zh) * | 2018-03-21 | 2021-01-01 | 视联动力信息技术股份有限公司 | 一种基于视联网的数据转发方法及装置 |
CN111163040B (zh) * | 2018-11-08 | 2022-06-14 | 浙江宇视科技有限公司 | 一种重协商的会话重建方法及装置 |
CN111163040A (zh) * | 2018-11-08 | 2020-05-15 | 浙江宇视科技有限公司 | 一种重协商的会话重建方法及装置 |
WO2021012780A1 (zh) * | 2019-07-22 | 2021-01-28 | 中兴通讯股份有限公司 | 一种视频会议控制方法及装置 |
CN112291501A (zh) * | 2019-07-22 | 2021-01-29 | 中兴通讯股份有限公司 | 一种视频会议控制方法及装置 |
CN112291501B (zh) * | 2019-07-22 | 2023-04-21 | 中兴通讯股份有限公司 | 一种视频会议控制方法及装置 |
WO2021047513A1 (zh) * | 2019-09-10 | 2021-03-18 | 中兴通讯股份有限公司 | 一种视频会议通信方法、装置以及计算机可读存储介质 |
CN111083572A (zh) * | 2019-11-28 | 2020-04-28 | 武汉兴图新科电子股份有限公司 | 基于多平台网络监测动态调整媒体传输的方法 |
CN112804478A (zh) * | 2021-04-07 | 2021-05-14 | 浙江华创视讯科技有限公司 | 一种视频会议服务器,及数据处理方法、装置 |
Also Published As
Publication number | Publication date |
---|---|
CN104660952B (zh) | 2018-06-08 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN104660952A (zh) | 视频会议通信方法和系统 | |
CN114866521B (zh) | 会议服务器 | |
CN113014562B (zh) | 用于建立媒体会话的方法和装置 | |
TWI408936B (zh) | 網路穿透方法及網路通訊系統 | |
US7447804B2 (en) | System and method for multi-telecommunication over local IP network | |
US7173928B2 (en) | System and method for establishing channels for a real time streaming media communication system | |
CN105376299B (zh) | 一种网络通信方法、设备及网络附属存储设备 | |
EP0848527A1 (en) | Method of transferring connection management information in world wide web requests and responses | |
US6449284B1 (en) | Methods and means for managing multimedia call flow | |
JP2005086467A (ja) | セッション制御装置、情報通信端末、サーバ、及び端末 | |
WO2007036160A1 (fr) | Appareil, systeme et procede assurant la communication entre un client et un serveur | |
WO2006082576A2 (en) | A method and apparatus for server-side nat detection | |
CN108306986B (zh) | 多类型媒体数据网络地址转换穿越方法、终端及系统 | |
CN102215276A (zh) | 一种视频监控系统及媒体穿越网络地址转换设备的方法 | |
JP3666654B2 (ja) | インターネット通信方法{AmethodforanInternetCommunication} | |
TW201729568A (zh) | 網路系統及建立資料連線的方法 | |
WO2012000364A1 (zh) | 实现会议电视系统跨网段信令互通的方法及系统 | |
CN104168302B (zh) | 设备操控实现方法、系统和代理网关 | |
JP3928664B2 (ja) | アドレス変換装置、メッセージ処理方法および装置 | |
US20090052446A1 (en) | Communications Interface | |
JP2003046530A (ja) | アドレス空間の異なるipネットワーク間の通信方法およびグローバルipアドレスを持つ装置 | |
JP3928663B2 (ja) | アドレス変換装置、メッセージ処理方法および装置 | |
KR20070061036A (ko) | 홈네트워크 간 미디어 공유 장치 및 그 방법 | |
JP3928662B2 (ja) | アドレス変換装置、メッセージ処理方法および装置 | |
JP2005039803A (ja) | ゲートウエイ及び方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |