第31讲RTP与SIP协议.pptVIP

《数据通信与计算机网络（第二版）》电子教案 笫三十一讲 RTP与SIP协议 本讲内容 第十一章 多媒体网络 11.3 RTP协议 11.3.1 RTP概述 11.3.2 RTP分组头部格式 11.3.3 RTCP 11.4 会话控制 11.4.1 SIP 11.3.1 RTP概述 实时多媒的基本需求 通信的实体间应该就采取什么样的压缩算法进行协商。 实时多媒体要求提供时间戳，接收者能够根据时间戳来进行回放。 实时多媒体数据在传输过程中可能会丢失，接收者应该能够处理数据丢失的情况。 实时多媒体应用应该能够对网络的拥塞作出响应，就需要相应的机制来把数据的丢失情况反馈回发送者。 11.3.1 RTP概述（续） 实时运输协议RTP 实时运输协议RTP是一种用于实时多媒体的标准传输协议，在RFC 1889定义。 RFC 1889定义了一对协议，RTP和实时运输控制协议RTCP。RTP用于交换多媒体信息，而RTCP用于定期发送对应该多媒体流的控制信息。 RTP一般运行于UDP之上 RTP数据流的端口为偶数端口（x），而RTCP则使用相邻的那个为奇数的端口（x+1）。 11.3.1 RTP概述（续） RTP支持组播方式的多媒体应用，它也可以运行在其他网络或者运输协议之上。 不采用TCP传输多媒体信息的原因 TCP是面向连接的协议，不支持组播。 在多媒体会话中 TCP允许少数报文的丢失，如果报文由于丢失而重传之后到达接收者，也很可能因为属于它的播放时序已经过去而不得不丢弃。 TCP机制在多媒体会话中可能并不是非常适合，而且会带来额外的延迟和延迟的抖动。 11.3.1 RTP概述（续） TCP缺少时间戳等机制。 RTP的特点 RTP不需要预先建立连接，同时也并没有更多的可靠性控制。 从应用开发者的角度来看，RTP是一种应用层协议。 新的多媒体应用不可能使用传统TCP协议，而且不大可能设计出一种符合各种类型的新应用的通用协议。 因此RTP协议只定义了一个实时多媒体应用的框架（framework）。 11.3.1 RTP概述（续） RTP会话（RTP Session）中的每个多媒体源都被分配了一个32个比特的同步源SSRC（synchronization source）标识，该标识在RTP会话中是惟一的。 11.3.1 RTP概述（续） RTP支持点到点的通信。 RTP支持会议方式的通信，可以采用组播方式的通信。所有会议成员的音频流都通过该组播地址 + 第一个UDP端口号（偶数）传输。 RTP支持在某个网关处把多个源混合在一起来形成一个新的单个流。 这个时候这个流的分组头部包含了所有被混合在一起的流的ID，那个网关被称为RTP混合器（Mixer）。 11.3.1 RTP概述（续） 混合器接收来自于一个或者多个源的RTP流，然后按照某种方式（可能改变其中的数据格式）将这些流合成在一起。 这个新的多媒体流实际上是一个单一的多媒体源，具有惟一的SSRC标识，同时在RTP头部中给出了那些原来的流的SSRC标识列表。 RTP还支持一种叫做RTP转发器（RTP translator）的设备，该设备转发RTP流，在转发的同时可能还会改变数据的格式，但是它并不改变SSRC标识。 11.3.2 RTP分组头部格式 RTP分组头部格式 一个RTP消息包括了一个12个字节的固定头部。 接下来多个相关源标识CSRC（contributing source）只在RTP混合器合成多个流下才使用。 可选的扩展头部用于协议的扩展。 负载字段所携带的实时多媒体信息的格式是由具体的应用而确定的。 11.3.2 RTP分组头部格式（续） 11.3.2 RTP分组头部格式（续） RTP的填充机制 RTP消息通过UDP封装，而UDP头部给出了经过填充后的RTP消息的长度，UDP消息中的最后一个字节给出了所填充的字节的数目，这样RTP消息的头部字段可以省掉长度字段。 11.3.2 RTP分组头部格式（续） 扩展（X）比特 扩展比特表示是否有一个扩展的头部； 一个特定的应用可能需要对协议进行扩展，从而可以利用这样一个扩展的头部。 CC字段 4比特的CC字段给出了相关源标识的个数，固定头部后面的CSRC列表包含了那些被合成在一起的源标识。 标志（Marker）比特 标志比特具体含义随所承载的负载类型而定。 11.3.2 RTP分组头部格式（续） 负载类型（Payload Type）字段 7比特的负载类型给出了所携带的多媒体信息的类型。 将负载类型信息包含在每一个报文中，避免了每次连接的重新初始化，这样做还允许动态的变换编码方案。 顺序号（Sequence Number） 16比特顺序号用于检测报文丢失的情况，同时可以区别那些同一个时间戳的报文。