|
|
联系名舞台 |
|
深圳公司地址:深圳市福田区振华路45号汽车大厦618
手机:13823516468
客服QQ:138866318
E-mail:mwtaudio@163.com |
|
|
|
|
|
分布式视频会议系统 |
发布时间:2020-5-16 13:41:26 |
|
浏览次数:
次 |
|
|
|
|
分布式视频会议系统
视频会议系统是目前疫情时期企事业交流之中的一个重要组成部分。电路交换网络中的视频会议系统已有较成熟的模型,如ITU的H.320标准等,但分组交换网(包括Ethernet、Internet等)的使用正日益普及,新的解决方案必须着重考虑如何利用这种网络来实现视讯系统。
本文提出的方案并不针对某种具体网络,而是根据Internet上多点视频会议系统的需要设计的。它充分利用了分组交换网多播功能和高带宽特点,是基于RTP协议的分布式多点会议系统,端主机是支持IP多播的Solaris 2.x系统,具有以下特点:
每个节点的数据通过多播到达其他节点。
音频和视频的合成由端主机完成。
不使用参考时钟实现发送/接收编解码器的良好同步,对分组抖动和丢失有较好控制。
动态流控机制允许视频压缩器根据网络状态调整发送率。
采用一种适合IP网络并能穿越防火墙的目录服务体系。
分布式视频会议系统的关键技术
会议系统的控制和数据传送
这是集中式方案中MCU的主要功能,在分布式系统中,MCU的功能可由网络和/或端节点来实现。在我们的方案中,数据传送主要利用了分布式网络的多播功能,不少控制功能都由端主机和网络共同实现。
带宽的有效使用和服务质量保证
分组交换网的复用机制可有效利用带宽,但也可能导致报文抖动甚至丢失。Internet大部分还未实现服务质量(QoS)保证,传统应用中通常由较高层TCP/IP协议来保证可靠传输。TCP用重传机制实现可靠传输,其内部流控机制根据确认包动态调整发送率。对于实时会议,重传导致的延迟是无法忍受的,因此传输层协议使用不具有可靠传输和内部流控制的UDP,而端到端同步和流控的任务则转嫁到视频会议系统上。
目录服务功能
Internet不像电路交换网,它没有统一的寻址机制,另外还存在防火墙和地址不公开的问题,因此目录服务是分布式会议系统中要解决的重点问题。
分布式多点视频会议系统的具体实现方案
整体结构
该系统的主要硬件如下:
音频/视频捕捉/回放卡。声音、图像和数据作为不同的流进行传送,接收者可选择从某个源只接收声音,这对于没有图像处理功能的端节点特别有用,用静默检测避免不发言时发送音频流。
Codec和DSP(数字信号处理器)卡。DSP根据端用户的选择合成视频和音频源,它还具有屏蔽时钟不同步、声音/图像不同步和分组丢失等功能。卡上还有一个Ethernet网卡,会议系统可直接连到LAN上,无需CPU的参与。音频/视频捕捉/回放卡和Codec/DSP卡之间有直接接口,可绕过系统总线,节省CPU时间。
传输层协议的选择
由于UDP不提供端到端可靠传输,出现了基于UDP、专为实时通信提供传输层服务的RTP协议。尽管RTP本身不实现服务质量保证,但它提供的多路复用、顺序号、时标、监控及对IP多播的灵活接口对我们设计的多播、同步、会话数据加密、动态流控、目录服务、安全穿越防火墙等方法非常重要。RTP是一个开放协议,为上层应用提供了充分的灵活性。但RTP的组成部分之一RTCP(实时传输控制协议)提供的松散管理和监控功能还不能满足我们所需的控制和管理功能(如动态获取和分发多播地址、分发会话密钥等),所以我们采用H.323的集中管理模型。
网络的多播
多播在现有网络中实现的并不多,在这种情形下,我们认为实现多播的途径可有以下几中:
使用实现了DVMRP的交换式以太网Hub,通过Hub之间的Tunnel功能在Internet上构造多播网络。
在Internet上以传统方式进行分组的复制和转发,端系统通过为每个目的节点复制和转发分组的方式来模拟多播。
当数据从实现多播的局域网向未实现的局域网发送时,使用RTP的Translator模拟多播功能。我们使用的是第三种,为了实现更方便的地址分配和安全保密功能,还需具有动态、分布式和安全特性的目录服务的配合。
压缩数据流的合成
在分布式系统中,网络的多播功能使每个端节点可同时接收多个源的图像和声音,而合成由端系统实现。为了降低开销,我们的合成是对压缩视频流进行的。压缩视频流的合成算法也是当前的研究热点,我们的算法利用了以下事实;几乎所有的标准视频压缩数据都包含一系列独立的由预定义分隔符分隔的编码组,通过检查分隔符可将压缩数据流分成像素区域。将各段压缩数据与像素区域对应起来后,就可根据用户设置来重新组装这些数据。
会话的保密
接收方发起的多播使得发送方无法控制接收数据的用户,局域网的广播性质使得局域网上任何主机都有可能监听会话,因此有必要对会话数据加密。可以用会话初始协议分发会话密钥,也可用RTP会话配置文件保存会话密钥(这种方法安全性低)。为了防止已知明文攻击,每个消息中应加入一次性且不可预测的信息。RTP报头的时标字段为我们提供了这个机制,而加密RTCP报文之前应在要加密的报文前添加一个随机数。
时钟同步和声音/视频同步
点到点连接中接收方根据数据到达速率实现与服务方的同步。
分布式多点会议中有多个发送/接收对需同步,这种方案就不适合了。我们设计了一种简单有效的方法解决时钟不同步和同一源的声音/图像不同步问题。该方法使用了RTP提供的时标,可简单概括为:静音抑制音频数据包的发送。声音在接收端以接收方的音频时钟回放,音频时钟的不同步在静默期间被抵消。音频/视频的同步是在每个音频突发的开始时刻,通过丢弃一些延迟的视频帧或者重用一些视频帧实现的。此机制不需回放时钟与捕捉时钟的同步,它能达到预期性能是基于以下事实:
突发平均持续时间相对静默持续时间较短;
捕捉端和回放端时钟的不同步较小。这两点使音频/视频的同步在较短的突发持续期间内不可能漂移很多。我们对不同源数据流之间的顺序关系没有采取任何控制。随着RMP(可靠多点发送协议)等协议在群组通信中的使用,我们将对这种顺序进行控制。
IP网目录服务目录服务在集中和分布式会议中都很重要。电路交换网中节点由固定号码标识,分组交换网中节点由IP地址来标识。异质网络中,ATM节点由E.164标识,POTS和ISDN节点由电话号码标识,Internet节点由IP地址标识,如果目录服务能将会议参加者的名字转换成其物理地址,将带来很大方便。在移动通信中,会议参加者可能从不同地方接入Internet,使用动态地址,目录服务更显得必要。如果防火墙内的用户不想暴露自己的IP地址,目录服务的功能将更复杂。
Internet域名服务系统(DNS)是一种分布式目录服务解决方案,但普通的DNS系统不支持动态分配的IP地址。动态IP地址查询方案要求有一个实时登记机制获取用户登录时动态分配的IP地址。目前已有的实时登记协议有SDP、LDAP、安全动态更新的DNS等(分布式)。Internet数据库提供商也为各种应用提供了专用实时登记协议(集中式)。集中式方案易实现,但扩展性差,且要求所会议成员向同一服务提供商登记也不大可能。分布方式基于有DNS系统,实践证明它运行稳定、扩展性良好。安全动态更新的DNS就是一个理想选择。
目前人们提出的目录服务都未考虑穿越防火墙的问题。穿越防火墙最常用的方法是使用代理服务器。通用代理服务器也能进行IP地址转换,且有一整套强大的安全功能,但它们的通用性也带来了以下问题:
同时有许多应用使用可能造成延迟,无法保证实时性;
为黑客提供了可突破的漏洞;
无法提供不同子网间域名查询服务;
在IP地址转换级连的情况下会产生无法预料的情况。我们使用的专用代理能克服以上缺点,可在RTP的Mixer或Translator上实现 。
假设A和B分别位于两个不同的防火墙之内,我们可在A和B所在子网的防火墙上各设一个代理PA和PB,在它们共同连接的Internet有一个公共目录服务提供商。假设A是呼叫方,B是被呼叫方。下面是穿越防火墙通信的过程:
用户A登录到网上时向PA登记。PA为A建立一个内部记录,登记A的IP地址和E-mail地址。然后,PA向外部目录服务提供商登记A的用户名(E-mail地址)和自己的IP地址。用户B登录时,B和PB进行同样的操作。
当A要与B通信时,A向PA发一个呼叫请求,给出呼叫目标B的E-mail地址。
PA向外部目录服务提供商发出解析名字B的请求。外部目录服务将返回步骤1中为B登记的地址(即PB的IP)。根据B的域名或目录服务提供的一些特殊信息,PA可以知道B处于某个防火墙内。
PA向PB发出一个连接请求,给出呼叫方和被呼方的名字A和B。这样PA和PB就可为A和B建立一个虚连接,后面的通信可以通过A-PA-PB-B这条链路进行。
结束语
Internet 的发展促使了新的分布式多点视频会议解决方案的出现,分布式解决方案与电路交换网络中的集中式方案有很大区别。作为群组计算的一个重要应用,分布式多点视频会议系统会得到新的群组通信技术的进一步支持,如:更理想的多播路由算法和协议;能适应复杂网络环境的资源预留和信息过滤技术;可靠有序的通信保障;针对会议系统应用的支持。然而,如何最有效地使用这些支持来适应视频会议中复杂、多样的需求将继续是我们的研究主题。
应用实例
中国移动贵州公司项目主要采用DANACOID的分布式系统,大楼包括3层一号视频会议室、3层多功能厅、13层一号二号三号视频会议室、经分会议室、视频控制室、总控室和18层党组会议室、19层大会议室等组成。
所有会议室中视频信号的接入和输出设备都是通过
多功能厅主显示屏为P2.5,辅助显示屏为P1.25;
接口机共计 200台,双服务器备份设计;
一台27寸触控一体机集中管理。
|
|
|
|
|
|
|