名词解释
RTP协议
Real-time Transport Protocol,实时传输协议,一个网络传输协议,该协议属于七层模型中的应用层协议。
大致作用:实时语音、视频数据经过模数转换和压缩编码处理后,先送给RTP封装成RTP数据单元,RTP数据单元被封装成UDP数据报,然后再向下传递给IP封装成IP数据包。
此协议详细说明了在互联网上传递音频和视频的标准数据包格式,一开始被设计为多播协议,后来被用于很多单播应用中。RTP协议常用于流媒体系统(配合RTSP协议),视频会议和一键通(Push toTalk)系统(配合H.323或SIP),使它成为IP电话产业的技术基础。RTP协议和RTP控制协议RTCP一起使用,它是建立在用户数据报协议(UDP)上的。
RTP为数据提供了具有实时特征的端对端传送服务,如在组播或者单播网络服务下的交互式视频音频或者模拟数据。应用程序通常在UDP上运行RTP以便使用其多路结点和校验服务;这两种协议都提供了传输层协议的功能。但是RTP可以与其他适合的底层网络或者传输协议一起使用。如果底层网络提供组播方式,那么RTP可以使用该组播表传输数据到多个目的地。
RTP本身并没有提供按时发送机制或其他服务质量(QoS)保证,它依赖于底层服务去实现这一过程。RTP并不能保证传送或者防止传送,也不确定网络底层的可靠性。RTP实行有序传送,RTP中的序列号允许接收方重组发送方的包序列,同时序列号也能用于决定适当的包位置,例如:在视频解码中,就不需要顺序解码。
RTP与控制协议RTCP配合工作,RTCP使得大的组播网络能够监视数据传输。监视能使接收器侦测到任何的包丢失,还可以补偿任何的延迟抖动,两个协议都独立于下面的传输层和网络层协议。RTP头中的信息将告诉接收器如何重建数据,并描述了比特流是如何打包的。通常,RTP工作于用户数据报协议之上,但它也能使用其他的传输协议。会话发起协议(SIP)和H.232都使用RTP
RTP的组成包括:序列号,用于侦测丢失的包;净负荷标识,描述了媒体的编码,他可以被更改以适应带宽的改变;帧指示,标记每一帧的开始与结束;源标识,标识帧的源;媒体内部同步,使用时间戳来侦测一个码流中不同的时延抖动,并对抖动进行补偿。
分组结构表:
+ 比特 | 0-1 | 2 | 3 | 4-7 | 8 | 9-15 | 16-31 |
0 | Ver. | P | X | CC | M | PT | sequence number |
32 | Timestamp | ||||||
64 | SSRC identifier | ||||||
96 | ... CSRC identifiers ... | ||||||
96+(CC×32) | Additional header (optional), indicates length "AHL" | ||||||
96+(CC×32) | |
定义 | 所占位 | 描述 |
Ver | 2 | 标明RTP版本号。协议初始版本为0,RFC3550中规定的版本号为2 |
P | 1 | padding如果该位被设置,则在该包末尾包含了额外的附加信息,附加信息的最后一个字节表示额外附加信息的长度(包含该字节本身)。该字段存在的原因是一些加密机制需要固定长度的数据块,或者为了在一个底层协议数据单元中传输多个RTP包 |
X | 1 | Extension如果该位被设置,则在固定的头部后存在一个扩展头部格式参见RFC3550 5.3.1 |
CC | 4 | CSRC count 在固定头部后存在多少个CSRC标记 |
M | 1 | marker 该位的功能依赖于profile的定义。Profile可以该变该位的长度,但是要保持marker和payload type总长度不变(共8bits) |
PT | 7 | payload type标记RTP包所携带信息的类型,用于说明RTP报文中有效载荷的类型, 如GSM音频、JPEM图像等。标准类型列出在RFC3551中,如果接收方不能识别该类型,必须忽略该包 |
sequence number | 16 | 序列号,每个RTP包发送后该序列号加1,接收方可以根据该序列号重新排列数据包顺序。 |
timestamp | 32 | 时间戳,RTP时间戳为同步不同的媒体流提供采样时间,用于重新建立原始音频或视频的时序。另外,它还可以帮助接收方确定数据到达时间的一致性或变化(有时被称为抖动) |
SSRC | 32 | 数据源标识,在一个RTP session中,其间每个数据流都会有一个不同的SSRC |
CSRC | 32*(0~15) | 特约信源(CSRC)标识符: 每个CSRC标识符占32位, 可以有0~15个。 网络中使用混合器时,混合器会在RTP报文头部之后插入新的同步源标识,其作用是区分多个同时的数据流。 |
RTCP协议
RTP 控制协议 (RTCP:RTP Control Protocol)
RTP使用一个偶数UDP端口,则RTCP使用RTP的下一个奇数port。
大致功能:为RTP媒体流提供信道外(out-of-band)控制。RTCP本身不传输数据,但是和RTP一起协作将多媒体数据打包和发送。RTCP定期在多媒体流会话参加者之间传输控制数据。RTCP的主要功能是为RTP所提供的服务质量(Quality of Service)提供反馈。RTCP收集相关媒体连接的统计信息(如:传输字节数,传输分组数,丢失分组数,jitter,单向和双向网络延迟等)。应用程序可利用RTCP所提供的信息视图提高服务质量(如:限制信息流量,改用压缩比较小的编解码器)。
注:RTCP本身不提供数据加密或身份认证。SRTCP可以用于此类用途。
RTP 控制协议(RTCP)采用与数据包相同的分发机制,将控制包周期性传输到所有会话参与者中。底层协议必须提供数据和控制包的多路发送,例如使用不同的 UDP 端口号。
RTCP 提供数据分发质量反馈信息,这是 RTP 作为传输协议的部分功能并且它涉及到了其它传输协议的流控制和拥塞控制。
RTCP 为 RTP 源携带一个持久性传输层标识符,称为规范名或 CNAME。由于一旦发现冲突或程序重启时, SSRC 标识符会随之改变,所以(1)接收方需要 CNAME 来跟踪每一个参与者。(2)同时接收方还要求 CNAME 能够与一组相关 RTP 会话中来自于给定参与者的多重数据流相关联,例如同步视频和音频。这样,要完成这两个功能就要求所有的参与者都要发送RTCP包,此时,需要控制速率使得RTP按比例来增加大量的参与者。通过每一个参与者发送各自的控制包给其他所有参与者,每一个参与者能够独立观察到参与者数据量,该数量可用来计算控制包的发送速率。
包结构表:
Version | p | rc | Packet-type |
2 | 3 | 8 | 16 |
Length |
包结构说明:
定义 | 所占位 | 描述 |
Version | 2 | 识别 RTP 版本。RTP 数据包中的该值与 RTCP 数据包中的一样。当前规范定义的版本值为 2 |
P | 3 | Padding, 设置时, RTCP 数据包包含一些其它 padding 八位位组,它们不属于控制信息。Padding 的最后八位是用于计算应该忽略多少间隙八位位组。一些加密算法中需要计算固定块大小时也可能需要使用 Padding 字段。在一个复合 RTCP 数据包中,只有最后的个别数据包中才需要使用 padding ,这是因为复合数据包是作为一个整体来加密的。 |
Rc | 8 | 接收方报告计数。包含在该数据包中的接收方报告块的数量,有效值为 0 |
packet | 16 | 包括常量 200 ,识别这是一个 RTCP SR 数据包 |
Length |
| RTCP 数据包的大小(32 位字减去 1),包含头和任意间隙 (偏移量的引入使得 0 成为有效值,并避免了扫描复合 RTCP 数据包过程中的无限循环现象,而采用 32 位字计数方法则避免了对 4 的倍数的有效性校验 )。 |