笫4讲 RTP与SIP协议

8.3.3 RTCP（续）
RR给出了最近接收到的所有RTP流的情况，它实际 上是由多个接收报告块组成。
• 接收报告块包含的信息：
* 该报告对应的RTP流的SSRC标识； * 在上次接收报告至今这段时间内来自于该RTP流的分组丢 失率； * 总的丢失分组数； * 目前接收到的最高顺序号； * 到达抖动（interarrival jitter）估计； * 最近的SR时刻； * 从接收到那个最近的发送报告到发送这个接收报告的间隔 时间。
8.3.3 RTCP
RTCP的主要功能
对多媒体递交的质量的反馈； 给出了把多媒体流与会话成员对应起来的手 段； 给出了RTP媒体时间戳和发送者的实时时钟 之间的关系； 提供了相应的文本信息来标识会话中的发送 者。
RTCP分组的类型
8.3.3 RTCP（续）
发送报告SR（Sender Report） • 给出了会话成员最近发送的多媒体流的情 况，还包含了该成员最近接收到多媒体流 的状况。 接收报告RR（Receiver Report） • 给出了该成员最近接收到的多媒体流的状 况。 源描述SDES（Source Description） • 给出了有关该成员的一些描述信息。
8.3.3 RTCP（续）
BYE分组 • 在成员离开会话时采用。
APP
• 用于携带和应用相关的信息，它的具体格 式和含义在相应的脚本（Profile）中定义。 这些不同类型的RTCP报文通过低层协议如 UDP传递，RTCP报文可以“堆叠”在一起 形成一个RTCP消息再发送。 RTCP消息中至少必须包含2个RTCP分组， 一个是接收报告，另外一个是源描述。
笫3讲 讲 RTP与SIP协议 与 协议
本讲内容
第8章 多媒体网络
8.3 RTP协议
8.3.1 RTP概述 8.3.2 RTP分组头部格式 8.3.3 RTCP
8.4 会话控制
8.4.1 SIP
8.3.1 RTP概述
实时多媒的基本需求
通信的实体间应该就采取什么样的压缩算法 进行协商。 实时多媒体要求提供时间戳，接收者能够根 据时间戳来进行回放。 实时多媒体数据在传输过程中可能会丢失， 接收者应该能够处理数据丢失的情况。 实时多媒体应用应该能够对网络的拥塞作出 响应，就需要相应的机制来把数据的丢失情 况反馈回发送者。
8.4.1 SIP（续）
SIP协议的设计借鉴了HTTP协议的诸多方面。
• SIP采用基于文本的请求/响应事务模型。 • SIP包含了两种类型的消息，分别是客户方到服 务方的请求和服务方到客户方的响应。 • 每个SIP消息包含一个起始行、消息头部和可选 的消息体。 • 当前SIP定义了6种方法：INVITE、ACK、 OPTIONS、BYE、CANCEL和REGISTER。
8.3.2 RTP分组头部格式
RTP分组头部格式
一个RTP消息包括了一个12个字节的固定头 部。 接下来多个相关源标识CSRC（contributing source）只在RTP混合器合成多个流下才使 用。 可选的扩展头部用于协议的扩展。 负载字段所携带的实时多媒体信息的格式是 由具体的应用而确定的。
8.3.1 RTP概述（续）
TCP缺少时间戳等机制。
RTP的特点
RTP不需要预先建立连接，同时也并没有更 多的可靠性控制。 从应用开发者的角度来看，RTP是一种应用 层协议。 新的多媒体应用不可能使用传统TCP协议， 而且不大可能设计出一种符合各种类型的新 应用的通用协议。 因此RTP协议只定义了一 个实时多媒体应用的框架（framework）。
顺序号（Sequence Number）
• 16比特顺序号用于检测报文丢失的情况，同时可 以区别那些同一个时间戳的报文。 • 一个RTP流每次发出一个RTP分组时该顺序号递 增，初始顺序号是随机选择的。
8.3.2 RTP分组头部格式（续）
时间戳（Timestamp）
• 时间戳信息描述了该报文中携带的第一个样本生 成的时间，这个时间并不是绝对的时间值，只有 时间戳之间的相对值才有意义。 • 时间戳的频率由所承载的负载类型所确定。 • 在当前的版本中，所有的视频数据使用65536Hz。
SIP独立于底层协议，一般使用UDP等无连 接的协议，而采用自己的应用层可靠性机制 来保证消息的可靠传输。 SIP标识
8.4.1 SIP（续）
• 用户可能会从一个端系统移动到另外一个端系统， 也可能通过多个名字来定位，为此SIP提供了相 应的寻址机制，每个用户都有一个唯一的SIP标 识，即SIP URI（Uniform Resource Identifier）。 • SIP标识可能是通过网页上的一个超链接，或者 地址表中的表项，或者是用户直接输入来进行访 问。 • SIP URI是与某个用户相关联，而不是与某一个 具体的设备相联系。 • SIP还支持一种安全的标识，称为SIPS URI。
RTP支持点到点的通信。 RTP支持会议方式的通信，可以采用组播方 式的通信。所有会议成员的音频流都通过该 组播地址 + 第一个UDP端口号（偶数）传输。 UDP RTP支持在某个网关处把多个源混合在一起 来形成一个新的单个流。 • 这个时候这个流的分组头部包含了所有被 混合在一起的流的ID，那个网关被称为 RTP混合器（Mixer）。
• RTP数据流的端口为偶数端口（x），而RTCP则 使用相邻的那个为奇数的端口（x+1）。
8.3.1 RTP概述（续）
• RTP支持组播方式的多媒体应用，它也可以运行
在其他网络或者运输协议之上。
不采用TCP传输多媒体信息的原因
TCP是面向连接的协议，不支持组播。 在多媒体会话中 TCP允许少数报文的丢失， 如果报文由于丢失而重传之后到达接收者， 也很可能因为属于它的播放时序已经过去而 不得不丢弃。 TCP机制在多媒体会话中可能并不是非常适 合，而且会带来额外的延迟和延迟的抖动。
8.3.1 RTP概述（续）
应用层 RTP
socket
UDP IP 子网
RTP在Internet中的位置
RTP会话（RTP Session）中的每个多媒体源 都被分配了一个32个比特的同步源SSRC （synchronization source）标识，该标识在 RTP会话中是惟一的。
8.3.1 RTP概述（续）
8.3.3 RTCP（续）
平均到达抖动的估计
• 到达抖动描述了两个相邻的RTP报文在发送时的 间隔与收到时两者的间隔的偏差情况。 • 通过变换后相当于RTP相对传输时间的偏差D，即 RTP报文到达接收者的时间与报文中包括的RTP 时间戳的差。 • RTP报文i和j之间的相对传输时间为：
D (i, j ) = ( Arrival j − Timestamp j ) − ( Arrival i − Timestamp i )
8.3.2 RTP分组头部格式（续）
32比特
V P X CC
负载类型 时间戳 同步源标识SSRC 相关源标识CSRC ···
顺序号
扩展头部（可选） RTP负载
RTP消息格式
8.3.2 RTP分组头部格式（续）
RTP的填充机制
• RTP消息通过UDP封装，而UDP头部给出了经过 填充后的RTP消息的长度，UDP消息中的最后一 个字节给出了所填充的字节的数目，这样RTP消 息的头部字段可以省掉长度字段。
接收者个数 T= * （平均RTCP分组长度） 0.75 * 0.05 * 会话带宽
8.4.1 SIP
SIP概述
概念
• IETF提出的会话初始化协议SIP（Session Initiation Protocol）是一种应用层的控制协议， 通过该协议可以完成有一个或者多个参加者的会 话的建立、修改和终止功能。
标志（Marker）比特
• 标志比特具体含义随所承载的负载类型而定。
8.3.2 RTP分组头部格式（续）
负载类型（Payload Type）字段
• 7比特的负载类型给出了所携带的多媒体信息的 类型。 • 将负载类型信息包含在每一个报文中，避免了每 次连接的重新初始化，这样做还允许动态的变换 编码方案。
RTCP提供了相应的机制来保证所有成员发 送的RTCP总负载只占会话带宽的一小部分。
8.3.3 RTCP（续）
• 根据实验表明，RTCP所占比例 5％是一个可接 受的值，并且可以很好地控制几百到几千个会话 成员。 • 为了限制RTCP负载的规模，必须知道会话带宽 和会议中的成员数。 • 活跃的发送者应该比一般的接受者获得更多的带 宽，以便它们能及时发送CNAME信息，从而使 得成员在接收到多媒体信息时知道到底是谁在讲 话。 • 协议把RTCP负载的25%分配给发送者，而剩余 的75%则属于接收者。
• 平均到达抖动可以按照下列公式进行更新：
Jitter = Jitter + (| D(i − 1, i ) | − Jitter ) / 16
8.3.3 RTCP（续）
SR实际上包括两个部分，一个部分是发送报 告块，另外一个是接收报告块。
• 发送报告块包含的信息： * 最近生成的RTP分组所对应的RTP时间戳和NTP RTP RTP NTP 时间戳（即实际的时间）； * 目前为止已发送的分组和字节数；
Βιβλιοθήκη Baidu
8.3.1 RTP概述（续）
实时运输协议RTP
实时运输协议RTP是一种用于实时多媒体的 标准传输协议，在RFC 1889定义。 RFC 1889定义了一对协议，RTP和实时运输 控制协议RTCP。RTP用于交换多媒体信息， 而RTCP用于定期发送对应该多媒体流的控 制信息。 RTP一般运行于UDP之上
利用SR和RR，可以计算出发送者到接收者 的往返传输时间RTT。
• 可以按照下列公式计算RTT： RTT = t arrival − t DLSR − t LSR
8.3.3 RTCP（续）
发送者 LSR 接收者 发送报告
RTT
DLSR
Arrival
接收报告
往返传输时间RTT的计算
RTP数据包中，除了32位的SSRC标识外， 不提供任何额外的数据源标识信息。
8.3.1 RTP概述（续）
• 混合器接收来自于一个或者多个源的RTP流，然 后按照某种方式（可能改变其中的数据格式）将 这些流合成在一起。 • 这个新的多媒体流实际上是一个单一的多媒体源， 具有惟一的SSRC标识，同时在RTP头部中给出 了那些原来的流的SSRC标识列表。
RTP还支持一种叫做RTP转发器（RTP translator）的设备，该设备转发RTP流，在 转发的同时可能还会改变数据的格式，但是 它并不改变SSRC标识。
SSRC标识
• SSRC标识用来标识该多媒体的信息源，它是在 每个RTP数据源初始化时随机生成的，并且需确 保在所有成员中保持唯一确定。
8.3.2 RTP分组头部格式（续）
CSRC列表
• CSRC列表给出了本RTP分组携带的负载在合成 前的多媒体流的SSRC列表。 • CSRC列表中携带的个数在前面的CC字段指定， 最多可以携带15个SSRC。
UDP头部中的长度字段 UDP头部 RTP头部 RTP负载 填充字节 填充的字节数 填充字段
RTP的填充机制
8.3.2 RTP分组头部格式（续）
扩展（X）比特
• 扩展比特表示是否有一个扩展的头部； • 一个特定的应用可能需要对协议进行扩展，从而 可以利用这样一个扩展的头部。
CC字段
• 4比特的CC字段给出了相关源标识的个数，固定 头部后面的CSRC列表包含了那些被合成在一起 的源标识。
8.3.3 RTCP（续）
• SSRC必须在RTP会话中唯一，如果有两个以上 多媒体源选择了同一个SSRC，则必须重新选择 一个。 • 另外用户可能由于断电、断网等原因而重新启动 应用程序，这样多媒体流的SSRC也会改变。
每一个会话成员都要定期发送RTCP报文。
• 较短的周期有利于更好地实时控制，但这会加重 网络负载。必须很好地平衡两者之间的关系。
8.3.3 RTCP（续）
会议的成员定期计算平均RTCP分组大小， 并且根据当前的成员数来决定其所占用的 RTCP带宽，从而计算出RTCP分组的传输间 隔。
• 发送者的RTCP分组传输间隔为： 发送者个数 T= * （平均RTCP 分组长度） 0.25 * 0.05 * 会话带宽 •接收者的RTCP分组传输间隔为：