引言
在目前已成为计算机领域热点的群组协作计算工具中，视频会议系统是其中的一个重要组成部分。电路交换网络中的视频会议系统已有较成熟的模型，如 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 的发展促使了新的分布式多点视频会议解决方案的出现，分布式解决方案与电路交换网络中的集中式方案有很大区别。作为群组计算的一个重要应用，分布式多点视频会议系统会得到新的群组通信技术的进一步支持，如：更理想的多播路由算法和协议；能适应复杂网络环境的资源预留和信息过滤技术；可靠有序的通信保障；针对会议系统应用的支持。然而，如何最有效地使用这些支持来适应视频会议中复杂、多样的需求将继续是我们的研究主题。
分布式会议案例：（来自51CTO）
android：http://down.51cto.com/data/656648
WIN：http://down.51cto.com/data/656675
Linux：http://down.51cto.com/data/656664
IOS：http://down.51cto.com/data/656655