多媒体通信---第5章多媒体通信的实时通信协议.pptVIP

第5章 多媒体通信的实时通信协议 5.1 概述 5.2 实时传输协议 5.3 实时传输控制协议 5.4 实时流协议 5.5 资源预留协议 5.1 概述 Internet原本并不是用于实时通信的， 由于TCP/IP协议不能确保实时通信所需要的带宽， 传输延迟所造成的时间抖动将使实时通信的质量严重下降。 另外， TCP协议负责数据的流量控制， 保证传输的正确性， 具有数据重发功能， 这一点也不适合于实时通信。 概 述 为了解决这个问题， IETF提出了多种实时通信协议， 这里主要介绍应用比较广泛的实时传输协议（RTP）、 实时流协议（RTSP）和资源预留协议 （RSVP）。  5.2 实时传输协议 1.RTP和RTCP RTP是一种提供端对端传输服务的实时传输协议，用来支持在单目标广播和多目标广播网络服务中传输实时数据，而实时数据的传输则由RTCP协议来监视和控制。为了可靠、 高效地传送实时数据， RTP和RTCP必须配合使用， 通常， RTCP包的数量占所有传输量的5％。  2. RTP 的实现 RTP 封装了多媒体应用的数据块。由于 RTP 向多媒体应用程序提供了服务（如时间戳和序号），因此也可以将 RTP 看成是在 UDP 之上的一个传输层的子层。 从应用开发人员的角度来看，可把RTP执行程序看成是应用程序的一部分，因为开发人员必需把RTP集成到应用程序中。在发送端，开发人员必需把执行RTP协议的程序写入到创建RTP信息包的应用程序中，然后应用程序把RTP信息包发送到UDP的套接接口(socket interface)；同样，在接收端，RTP信息包通过UDP套接接口输入到应用程序，因此开发人员必需把执行RTP协议的程序写入到从RTP信息包中抽出媒体数据的应用程序。 现以用RTP传输声音为例来说明它的工作过程。假设音源的声音是64 kb/s的PCM编码声音，并假设应用程序取20毫秒的编码数据为一个数据块(chunk)，即在一个数据块中有160个字节的声音数据。应用程序需要为这块声音数据添加RTP标题生成RTP信息包，这个标题包括声音数据的类型、顺序号和时间戳。然后RTP信息包被送到UDP套接接口，在那里再被封装在UDP信息包中。在接收端，应用程序从套接接口处接收RTP信息包，并从RTP信息包中抽出声音数据块，然后使用RTP信息包的标题域中的信息正确地译码和播放声音。 3. RTP信息包标题域 RTP信息包的标题域的结构如下： Payload Type(有效载荷类型) Sequence Number(顺序号) Timestamp(时间戳) Synchronization Source Identifier(同步源标识符) Miscellaneous Fields(其他) （1）有效载荷类型 RTP信息包中的有效载荷域(Payload Type Field)的长度为7位，因此RTP可支持128种不同的有效载荷类型。对于声音流，这个域用来指示声音使用的编码类型，例如PCM、自适应增量调制或线性预测编码等等。如果发送端在会话或者广播的中途决定改变编码方法，发送端可通过这个域来通知接收端。表16-01列出了目前RTP所能支持的声音有效载荷类型。 RTP所能支持的声音有效载荷类型 RTP所能支持的视频有效载荷类型 （2）顺序号 顺序号(Sequence Number Field)域的长度为16位。每发送一个RTP信息包顺序号就加1，接收端可以用它来检查信息包是否有丢失以及按顺序号处理信息包。例如，接收端的应用程序接收到一个RTP信息包流，这个RTP信息包在顺序号86和89之间有一个间隔，接收端就知道信息包87和88已经丢失，并且采取措施来处理丢失的数据。 （3）时间戳 时间戳(Timestamp)域的长度为32字节。它反映RTP数据信息包中第一个字节的采样时刻(时间)。接收端可以利用这个时间戳来去除由网络引起的信息包的抖动，并且在接收端为播放提供同步功能。 （4）同步源标识符 同步源标识符(Synchronization Source Identifier，SSRC)域的长度为32位。它用来标识RTP信息包流的起源，在RTP会话或者期间的每个信息包流都有一个清楚的SSRC。SSRC不是发送端的IP地址，而是在新的信息包流开始时源端随机分配的一个号码。 5.3 实时传输控制协议（RTCP） RTCP通过在会话用户之间周期性地递交控制报文来完成监听服务质量和交换会话用户信息等功能。 根据用户间的数据传输反馈信息， 可以制定流量控制的策略， 而会话用户信息的交互， 可以制定会话控制的策略。  RTCP将控制包周期发送给所有连接者， 应用与数据报文相同的分