基于SIP的视频会议系统模型、协议栈及相关扩展(3)

基于SIP的视频会议系统模型、协议栈及相关扩展的研究

的50％左右，但代价是编解码的复杂性上升，H.264编码复杂性是H．263的3倍，解码复杂性是H．263的2倍。H．264一经推出就广受欢迎，并很快被ISO批准为MPEG-4的图像编解码标准。

实时传输技术

实时传输技术主要是采用实时传输协议RTP。RTP是提供端到端的包括音视频在内的实时数据传送的协议。RTP包括数据和控制两部分，后者叫RTCP。

实时传输协议RTP是针对Internet上多媒体数据流的一个传输协议。RTP被定义为在一对一或一对多的传输情况下工作，其目的是提供时间信息和实现流同步（RTP提供了时间标签和控制不同数据流同步特性的机制，可以让接收端重组发送端的数据包）。RTP的典型应用建立在UDP上，但也可以在TCP或ATM等其他协议之上工作。RTP本身只保证实时数据的传输，并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。

工作时，RTP协议从上层接收流媒体信息码流(如H．263 ），装配成RTP数据包发送给下层，下层协议提供RTP和RTCP的分流。如在UDP中，RTP使用一个偶数号端口，则相应的RTCP使用其后的奇数号端口。RTP数据包没有长度限制，它的最大包长只受下层协议的限制。

资源预留协议

RSVP协议的设计思想是期望通过应用和网络的协商，保证实时传输所需要的网络资源，在互联网上同时提供尽力传送和实时传送的综合服务能力。RSVP只负责资源的预留，并不牵涉到具体数据流的传输。

根据当前的RSVP规范建议，RSVP适合于小型的，私有的网络上，扩展性和策略控制问题不会表现的很突出。因此，RSVP协议适用于互联网的边缘区域，除非扩展性问题得到解决，在互联网的骨干网上不适合采用RSVP协议。

实时传输控制协议(RTCP)

RTCP与RTP协同使用，它把传输状态信息发送给所有与会者以进行媒体流性能和质量的监测。发送方也可以用它来确保SSRC的唯一性，RTCP协议主要依靠在所有成员之间周期性的传输控制分组来实现控制检测功能，它要求下层协议必须提供时间和控制分组的复用功能，如UDP协议可以提供不同的端口号。

RTCP主要完成以下四大功能，前三项是所有系统都支持的功能，最后一项是可以选择的功能。提供数据传输质量的反馈信息，这些反馈信息与流量控制和拥塞控制密切相关，也可以直接用于故障诊断。对每一个RTP信息源，RTCP带有一致的传输层标识，称为通用名。当SSRC（同步源标志）在由于冲突而发生改变时，接收方需要CNAME（通用名）标识来区分多个媒体流中给定应用的应用成员；当前参与成员的动态估计，可以用来计算数据发送速率，并且在成员动态变化时对速率进行动态调整以合理利用网络资源；传送最少量的控制信息以保证系统可以很容易的扩展成为大规模的松散耦合系统。

RTCP协议具有很好的伸缩性，允许应用从几个人的小规模系统扩展成上千人的大规模系统。

服务质量保证(QoS)技术

IP网络执行“尽最大可能提供服务”的策略，对所有数据一视同仁，而视频会议系统传输的数据的重要性是不同的，如少量的视频数据丢失可能影响不大，但认证信息丢失会导致整个会议呼叫失败。QoS的目的是在现有条件下尽可能获得好的效果，如保证重要的数据优先得到传输，必要的情况下，可以丢弃一些相对不重要的数据等等。