文章目录
- RTP(real-time transport protocol),实时传输协议
- RTCP（RTP 控制协议）
- rfc3550：RTP: A Transport Protocol for Real-Time Applications
- rfc4585：Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)
- rfc5104：Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)
- rfc3611：RTP Control Protocol Extended Reports (RTCP XR)
- 参考文献
RTP(real-time transport protocol),实时传输协议
相关概念
RTP 在多点传送(多播)或单点传送(单播)的网络服务上,提供端对端的网络传输功能,适合应用程序传输实时数据,如:音频,视频或者仿真数据。RTP没有为实时服务提供资源预留的功能,也不能保证QoS(服务质量)。数据传输功能由一个控制协议(RTCP)来扩展,通过扩展,可以用一种方式对数据传输进行监测控制,该协议(RTCP)可以升级到大型的多点传送(多播)网络,并提供最小限度的控制和鉴别功能。RTP 和 RTCP 被设计成和下面的传输层和网络层无关。协议支持 RTP 标准的转换器和混合器的使用。
同步源(SSRC,Synchronization source)
RTP 包流的源,用 RTP 报头中 32 位数值的 SSRC 标识符进行标识,使其不依赖于网络地址。一个同步源的所有包构成了相同计时和序列号 空间的一部分,这样接收方就可以把一个同步源的包放在一起,来进行重放。举些同步源的例子,像来自同一信号源的包流的发送方,如麦克风、摄影机、RTP 混频器(见下文)就是同步源。一个同步源可能随着时间变化而改变其数据格式,如音频编码。SSRC 标识符是一个随机选取的值,它在特定的 RTP 会话中是全局唯一(globally unique)的。参与者并不需要在一个多媒体会议的所有 RTP 会话中,使用相同的 SSRC 标识符;SSRC 标识符的绑定通过RTCP(见章节 6.5.1)。如果参与者在一个 RTP 会话中生成了多个流,例如来自多个摄影机,则每个摄影机都必须标识成单独的同步源。
作用源(CSRC,Contributing source )
若一个 RTP 包流的源,对由 RTP 混频器生成的组合流起了作用,则它就是一个作用源。对特定包的生成起作用的源,其 SSRC 标识符组成的列表,被混频器插入到包的 RTP 报头中。这个列表叫做 CSRC 表。相关应用的例子如,在音频会议中,混频器向所有的说话人(talker)指出,谁的话语(speech)将被组合到即将发出的包中,即便所有的包都包含在同一个(混频器的)SSRC 标识符中,也可让听者(接收者)可以清楚谁是当前说话人。
混频器和转换器(Mixers and Translators)
混频器(Mixer)：一种中间系统,它从一个或多个源中接收 RTP 包,可能改变其数据格式,再按某种方式把这些包组合成一个新的包,然后转发出去。由于多个输入源的计时一般不会同步,所以混频器会对各个流的计时作出调整,并为组合流生成一个新的计时。因此,混频器将被标识成它所产生所有数据包的同步源。
转换器(Translator)：一种中间系统,它转发 RTP 包而不改变各包的同步源标识符。转换器的例子如下:不作混频地转变编码的设备,把多播复制到单播的重复装置,以及防火墙里应用层次的过滤器。
考虑一下这种情况,一个地方的参与者只能低速接入会议,而其他大部分参与者都能享受高速连接。与其让强迫大家都忍受低带宽,不如在只能低速接入的地方,放置一个减质量音频编码的RTP层次的中继(称作混频器)。混频器将重新同步输入的音频包,重建发送方产生的20ms固定间隔,混频已重建过的音频流为单一的流,转换音频编码为低带宽格式,最后通过低带宽连接转发数据包流(package stream)。这些包可能被单播到一个接收方,也可能多播到另一个的地址而发给多个接收方。RTP 报头为混频器提供了一种方法,使其能辨识出对混频后的包有用的源,从而保证提供给接收方正确的说话者指示。
在音频会议中,一些预定参与者尽管有高带宽连接,但不能通过IP多播直接接入会议。例如,他们可能位于一个不允许任何 IP 包通过的应用层防火墙后面。对这些站点,可能就不需要混频,而需要另一种称为转换器的RTP层次中继。可以在防火墙两侧分别安装一个转换器,外侧转换器将所有多播包通过安全连接转入内侧转换器,
内侧转换器再转发给内部网的一个多播组(multicast group)。
混频器和转换器可以设计成用于各种目的。比如,一个视频混频器在测量多个不同视频流中各人的单独影像后,将它们组合成一个单一视频流来模拟群组场景。又如,在只用 IP/UDP和只用ST_II的两个主机群之间通过转换建立连接。再如,在没有重新同步或混频时,用packet-by-packet 编码转换来自各个独立源的视频流。
RTP 负载（RTP payload）
通过 RTP 传输的包中的数据，例如，音频样本或压缩好的视频数据。RTP负载由RTP负载头和RTP负载数据构成。
- RTP Payload Types (PT) for standard audio and video encodings - Closed:0-127，其中：
| PT 值 | 状态 |
|---|---|
| 0-34 | 已分配 |
| 35-71 | Unassigned |
| 72-76 | Reserved for RTCP conflict avoidance |
| 77-95 | Unassigned |
| 96-127 | dynamic |
- RTCP Control Packet Types (PT)
| PT 值 | - | 说明 |
|---|---|---|
| 1-191 | Specification Required or Expert Review | - |
| 194-199 | Specification Required or Expert Review | If 200-223 is fully occupied |
| 200-223 | Specification Required or Expert Review | Primary Assignments range |
| 224-254 | Specification Required or Expert Review | - |
RTP 包（RTP packet）
一种数据包，其组成部分有：一个固定 RTP 报头（12字节），一个可能为空的作用源（contributing sources）列表，以及RTP负载。
RTP 包解析
RTP 包头格式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
前 12 个字节出现在每个 RTP 包中,仅仅在被混合器插入时,才出现 CSRC 识别符列表。这些域有以下意义:
| 类型 | 长度（位） | 描述 |
|---|---|---|
| 版本(V) | 2 bits | 此域定义了 RTP 的版本。此协议定义的版本是 2。(值 1 被 RTP 草案版本使用,值 0 用在最初"vat"语音工具使用的协议中。) |
| 填充§ | 1 bits | 若填料比特被设置,则此包包含一到多个附加在末端的填充比特,填充比特不算作负载的一部分。填充的最后一个字节指明可以忽略多少个填充比特。填充可能用于某些具有固定长度的加密算法,或者用于在底层数据单元中传输多个 RTP 包。 |
| 扩展(X) | 1 bits | 若设置扩展比特,固定头(仅)后面跟随一个头扩展。 |
| CSRC 计数(CC) | 4 bits | CSRC 计数包含了跟在固定头后面 CSRC 识别符的数目。 |
| 标志(M) | 1 bits | 标志的解释由具体协议规定。它用来允许在比特流中标记重要的事件,如对于视频，标记一帧的结束；对于音频，标记会话的开始 |
| 负载类型(PT) | 7 bits | 此域定义了负载的格式,由具体应用决定其解释。协议可以规定负载类型码和负载格式之间一个默认的匹配。其他的负载类型码可以通过非 RTP 方法动态定义（如H264使用96）。 RTP发送端在任意给定时间发出一个单独的 RTP 负载类型;此域不用来复用不同的媒体流。 |
| 序列号(sequence number) | 16 bits | 每发送一个 RTP 数据包,序列号加 1,接收端可以据此检测丢包和重建包序列。序列号的初始值是随机的(不可预测),以使即便在源本身不加密时(有时包要通过翻译器,它会这样做),对加密算法泛知的普通文本攻击也会更加困难。 |
| 时间戳(timestamp) | 32 bits | 时间戳计算的单位不是秒之类的单位，而是由采样频率所代替的单位，这样做的目的就是为了是时间戳单位更为精准，时间戳反映了 RTP 数据包中第一个字节的采样时间，在一次会话开始时的时间戳初值也是随机选择的。时钟频率依赖于负载数据格式,并在描述文件(profile)中进行描述。也可以通过 RTP 方法对负载格式动态描述。 |
| SSRC | 32 比特 | 用以识别同步源。标识符被随机生成,以使在同一个 RTP 会话期中没有任何两个同步源有相同的 SSRC 识别符。尽管多个源选择同一个 SSRC 识别符的概率很低,所有RTP实现工具都必须准备检测和解决冲突。若一个源改变本身的源传输地址,必须选择新的SSRC识别符,以避免被当作一个环路源 |
| CSRC 列表 | 0 到 15项,每项32 bits | CSRC列表识别在此包中负载的所有贡献源。识别符的数目在 CC 域中给定。若有贡献源多于 15 个,仅识别 15 个。CSRC 识别符由混合器插入,并列出所有贡献源的SSRC识别符。例如语音包,混合产生新包的所有源的SSRC标识符都被列出,以在接收端处正确指示参与者 |
RTP 头扩展
RTP扩展头:rtc8285:A General Mechanism for RTP Header Extensions，可以同时扩展为1或2个字节
RTP 提供扩展机制以允许实现个性化:某些新的与负载格式独立的功能要求的附加信息在RTP 数据包头中传输。设计此方法可以使其它没有扩展的交互忽略此头扩展。RTP 头扩展的格式如下所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| defined by profile | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| header extension |
| .... |
若 RTP 头中的扩展比特位置 1,则一个长度可变的头扩展部分被加到 RTP 固定头之后，RTP固定头之后只允许有一个头扩展。为允许多个互操作实现独立生成不同的头扩展,或某种特定实现有多种不同的头扩展：
| 类型 | 长度 | 描述 |
|---|---|---|
| 识别标识符或参数 | 16 bits | 这16 bits 的格式由具体实现的上层协议定义。基本的RTP明并不定义任何头扩展本身。 |
| 长度域(length) | 16 bits | 指示扩展项中 32 bits 字的个数,不包括 4 个字节扩展头(因此零是有效值)。 |
RTCP（RTP 控制协议）
| RFC版本号 | 名称 | 备注 |
|---|---|---|
| 3550 | RTP: A Transport Protocol for Real-Time Applications (RTP/AVP) -SR: Sender report, for transmission and reception statistics from participants that are active senders -RR: Receiver report, for reception statistics from participants that are not active senders and in combination with SR for active senders reporting on more than 31 sources -SDES: Source description items, including CNAME -BYE: Indicates end of participation -APP: Application-specific functions | 现用RTP协议,定义RTP和RTCP协议的最基本内容 |
| 4585 | Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF) - Transport layer FB messages:(RTPFB/205) 0: unassigned 1: Generic NACK 2-30: unassigned 31: reserved for future expansion of the identifier number space - Payload-specific FB messages:(PSFB/206) 0: unassigned 1: Picture Loss Indication (PLI) 2: Slice Loss Indication (SLI) 3: Reference Picture Selection Indication (RPSI) 4-14: unassigned 15: Application layer FB (AFB) message 16-30: unassigned 31: reserved for future expansion of the sequence number space - Application layer FB messages | 增加了 feedback NACK等定义，通过实时的RTCP进行丢包重传 |
| 5104 | Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF) -Transport Layer Feedback Messages Assigned in AVPF [RFC4585]: 1:Generic NACK 31:reserved for future expansion of the identifier number space Assigned in this memo: 2:reserved (see note below) 3:Temporary Maximum Media Stream Bit Rate Request (TMMBR) 4:Temporary Maximum Media Stream Bit Rate Notification (TMMBN) - Payload-specific FB messages:(PSFB/206) Assigned in [RFC4585]: 1: Picture Loss Indication (PLI) 2: Slice Lost Indication (SLI) 3: Reference Picture Selection Indication (RPSI) 15: Application layer FB message 31: reserved for future expansion of the number space Assigned in this memo: 4: Full Intra Request (FIR) 5: Temporal-Spatial Trade-off Request (TSTR) 6: Temporal-Spatial Trade-off Notification (TSTN) 7: Video Back Channel Message (VBCM) Unassigned: 0: unassigned 8-14: unassigned 16-30: unassigned | 基于4585实时RTCP消息，来控制音视频编码器 |
| 3611 | RTP Control Protocol Extended Reports (RTCP XR) BT name – ---- 1 Loss RLE Report Block 2 Duplicate RLE Report Block 3 Packet Receipt Times Report Block 4 Receiver Reference Time Report Block 5 DLRR Report Block 6 Statistics Summary Report Block 7 VoIP Metrics Report Block | RTCP的拓展报文即XR报文定义 |
rfc3550：RTP: A Transport Protocol for Real-Time Applications
SR并不是发送者发送多少包告诉对方，而是发送者这端接收了多少包，接收过程中丢了多少包。将这些信息传送给对端。
所以SR包含两个信息，将发送者自己发送的信息告诉对端，同时将自己接收的信息也告诉对端。而RR是当报文发送方只作为接收者，而不发送媒体数据时，发给对端自己作为接收方接收到的数据的统计信息
| 类型 | 名称 | 描述 |
|---|---|---|
| 200 | SR（Sender Report） | 发送者报告：描述作为活跃发送者成员的发送和接收统计数字 |
| 201 | RR（Receiver Report） | 接收者报告：描述非活跃发送者成员的接收统计数字 |
| 202 | SDES（Source Description Items） | 源描述项：其中包括规范名 CNAME |
| 203 | BYE | 结束传输：表明参与者将结束会话 |
| 204 | APP | 应用描述功能 |
SR（Sender Report）
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| RC | PT=SR=200 | length |头部8字节==》版本(V)|填充(P)|接收报告块计数(RC）|包类型(PT)|长度
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of sender |SR 包发送者的同步源标识符
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| NTP timestamp, most significant word |发送者信息20字节==》NTP 时间戳8字节
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP timestamp, least significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP timestamp |RTP 时间戳
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sender's packet count |发送的报文数
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sender's octet count |发送的字节数
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_1 (SSRC of first source) |接收报告块==》SSRC_n(同步源标识符)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fraction lost | cumulative number of packets lost |丢包率 | 累计包丢失数
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extended highest sequence number received |接收到的扩展的最高序列号
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| interarrival jitter |到达间隔抖动
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| last SR (LSR) |上一 SR 报文
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delay since last SR (DLSR) |自上一 SR 的时间
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_2 (SSRC of second source) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| profile-specific extensions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
第一部分：头部（8字节）
| 类型 | 长度 | 描述 |
|---|---|---|
| 版本(V) | 2 bits | RTP 版本识别符,在 RTCP 包内的意义与 RTP 包中的相同。此协议中定义的版本号为 2。 |
| 填充§ | 1 bits | 若设置填充比特,该RTCP包在末端包含一些附加填充比特,并不是控制信息的基本部分。填充的最后一个比特统计了多少个字节必须被忽略。填充可能会用于需要固定长度块的加密算法。在复合 RTCP 包中,复合包作为一个整体加密,填料比特只能加在最后一个单个 RTCP 包的后面。 |
| 接收报告块计数(RC) | 5 bits特 | 该包中所含接收报告块的数目。零值有效。 |
| 包类型(PT) | 8 bits | 包含常数 200,用以识别这个为 SR 包。 |
| 长度 | 16 bits | 该 RTCP 包的长度减 1。其单位是 32 比特字,包括头和任何填充字节。(偏移量 1 保证零值有效,避免了在扫描 RTCP 包长度时可能发生的无限循环,同时以 32 比特为单位避免了对以 4 为倍数的有效性检测。) |
| SSRC | 32 bits | SR 包发送者的同步源标识符。 |
第二部分：发送者信息（20 字节）
在每个发送者报告包中出现。它概括了从此发送者发出的数据传输情况。此域有以下意义:
| 类型 | 长度 | 描述 |
|---|---|---|
| NTP 时间戳 | 64 bits | 网络时间戳，用于音视频同步，64 位时间戳也叫NTP时间戳，它的前32位是从1900 年1 月1 日0 时开始到现在的以秒为单位的整数部分，后32 位是此时间的小数部，因此，它可以肯定的表示了数据发送出去的绝对时间，指示了此报告发送时的背景时钟(wallclock)时刻,它可以与从其它接收者返回的接收报告块中的时间标志结合起来,计算往返每个接收者所花的时间。接收者应让 NTP 时间戳的精度远大于其他时间戳的精度。一个系统可能没有背景时钟的概念,而只有系统指定的时钟,如系统时间(system uptime)。在这样的系统中,此时钟可以作为参考计算相对 NTP 时间戳。选择一个公用的时名是非常重要的。这样多个独立的应用都可以使用相同的时钟，一个发送者,如果不用背景时钟时间或逝去时间,可以设置此项为零。 |
| RTP 时间戳 | 32 bits | 与以上的 NTP 时间标志对应同一时刻。与数据包中的RTP时间戳具有相同的单位和偏移量。这个一致性可以用来让 NTP 时间标志已经同步的源之间进行媒体内/间同步,还可以让与媒体无关的接收者估计名义 RTP 时钟频率。注意在大多数情况下此时间戳不等于任何临近的 RTP 包中的时间戳。RTP 时间戳可以由相应的 NTP 时间戳计算得到。依据的是―RTP时间戳计数器和―在采样时通过周期性检测背景时钟时间得到的实际时两者之间的关系。 |
| 发送的报文数 | 32 bits | 从开始传输到此 SR 包产生时该发送者发送的 RTP 数据包总数。若发送者改变 SSRC 识别符,该计数器重设 |
| 发送的字节文数 | 32 bits | 从开始传输到此 SR 包产生时该发送者在RTP数据包发送的字节总数(不包括头和填充)。若发送者改变 SSRC 识别符,该计数器重设。此域可以用来估计平均的负载数据发送速率。 |
在 RTCP SR 包中有 NTP 时间戳、RTP 时间戳,它们可以计算背景时钟和 RTP 时钟之间的对应关系,通过这个关系,可以由 RTP 数据包中的 RTP 时间戳计算也相应的回放时刻。这样就可以进行多个流的同步了。之所以要有 NTP 时间戳,是因为不同流的 RTP 时间戳有不同的随机偏移量,无法直接进行同步。
第三部分：零到多个接收报告块
块数等于从上一个报告以来该发送者侦听到的其它源(不包括自身)的数目。每个接收报告块传输从某个同步源来的数据包的接收统计信息。若数据源因冲突而改变其 SSRC 标识符,接收者重新设置统计信息。这些统计信息有:
| 类型 | 长度 | 描述 |
|---|---|---|
| SSRC_n(同步源标识符) | 32 bits | 在此接收报告块中信息所属源的 SSRC 标识符。 |
| 丢包率 | 8 bits | 自从前一 SR 包或 RR 包发送以来,从SSRC_n传来的RTP数据包的丢失比例。以定点小数的形式表示。该值定义为损失包数/期望接收的包数。若由于包重复而导致包丢失数为负值,丢包率设为零。注意在收到上一个包后,接收者无法知道以后的包是否丢失。如:若在上一个接收报告间隔内从某个源发出的所有数据包都丢失,那么将不为此数据源发送接收报告块。 |
| 累计包丢失数 | 24 bits | 从开始接收到现在,从源SSRC_n发到本源的RTP数据包的丢包总数。该值定义为:期望接收的包数-实际接收的包数。接收的包括复制的或迟到的。由于迟到的包不算作损失,在发生复制时丢包数可能为负值。期望接收的包数定义为:扩展的上一接收序号(随后定义)减去最初接收序号。 |
| 接收到的扩展的最高序列号 | 32 bits | 低16 bits 包含从源SSRC_n来的最高接收序列号,高16 bits 用相应的序列号周期计数器扩展该序列号，防止数据值大溢出，注意在同一会议中的不同接收者,若启动时间明显不同,将产生不同的扩展项。 |
| 到达间隔抖动 | 32 bits | RTP 数据包到达时刻统计方差的估计值。测量单位同时间戳单位,用无符号整数表达。到达时间抖动定义为一对包中接收者相对发送者的时间间隔差值的平均偏差(平滑后的绝对值)。如以下等式所示,该值等于两个包相对传输时间的差值。相对传输时间是指:包的 RTP 时间戳和到达时刻接收者时钟时间的差值。 |
| 上一 SR 报文(LSR) | 32 bits | 接收到的来自源 SSRC_n 的最新 RTCP 发送者报告(SR)的 64 位 NTP 时间标志的中间 32 位。若还没有接收到 SR,该域值为零。 |
| 自上一 SR 的时间(DLSR) | 32 bits | 是从收到来自 SSRC_n 的 SR 包到发送此接收报告块之间的延时,以 1/65536 秒为单位。若还未收到来自 SSRC_n 的 SR 包,该域值为零。 |
RR（Receiver Report）
接收者报告包(RR)与发送者报告包基本相同,除了包类型域包含常数 201 和没有发送者信息的 5 个字(NTP 和 RTP 时间标志和发送者包和字节计数)。余下区域与 SR 包意义相同。若没有发送和接收据报告,在 RTCP 复合包头部加入空的 RR 包(RC=0)。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| RC | PT=RR=201 | length |头部8字节==》版本(V)|填充(P)|接收报告块计数(RC）|包类型(PT)|长度
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of sender |SR 包发送者的同步源标识符
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_1 (SSRC of first source) |接收报告块==》SSRC_n(同步源标识符)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fraction lost | cumulative number of packets lost |丢包率 | 累计包丢失数
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extended highest sequence number received |接收到的扩展的最高序列号
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| interarrival jitter |到达间隔抖动
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| last SR (LSR) |上一 SR 报文
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delay since last SR (DLSR) |自上一 SR 的时间
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_2 (SSRC of second source) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| profile-specific extensions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SDES（Source Description Items）
源描述(SDES)包由一个头及 0 个或多个块组成。每个块都由块中所标识的数据源的标识符及其后的各个描述构成。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| SC | PT=SDES=202 | length |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC/CSRC_1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SDES items |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC/CSRC_2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SDES items |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
描述信息如：
| SDES items | 描述 |
|---|---|
| CNAME | CNAME与SSRC对应，为源的唯一标识（SSRC可能会发生变化） |
| NAME | 名字 |
| 邮箱 | |
| PHONE | 电话 |
| LOC | 位置 |
| TOOL | |
| NOTE | 备注 |
| PRIV | 私有扩展 |
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CNAME | length | user and domain name ...
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
BYBE
BYE 包表明一个或多个源将要离开。如果混合器收到 BYE 包,混合器应当发送这个 BYE 包,并保持 SSRC/CSRC 不变。如果混合器关闭,应向贡献源列表中的所有 SSRC,包括它自己的SSRC 发送 BYE 包。BYE 包可能会有选择的包含 8 个字节的统计字段,其后跟上几个字节的文本表明离开的原因。文本字符串编码格式和 SDES 中描述的相同。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| SC | PT=BYE=203 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC/CSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| length | reason for leaving (opt) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
APP
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| subtype | PT=APP=204 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC/CSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| name (ASCII) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| application-dependent data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 类型 | 长度 | 描述 |
|---|---|---|
| 子类型（subtype ） | 5 bits | 可以用作子类型，以允许在一个唯一名称下定义一组应用程序包 |
| 名称（name ） | 32 bits | 由定义应用程序数据包集的人员选择的名称，该数据包集相对于此应用程序可能接收的其他应用程序包。应用程序创建者可以选择使用应用程序名称，然后协调将子类型值分配给希望为应用程序定义新的数据包类型。或者，建议其他人根据他们所代表的实体选择一个名称，然后协调名称的使用在该实体内。名称被解释为四个ASCII字符的序列，其中视为不同的大小写字符。 |
| 应用程序相关数据 | 可变长度 | 应用程序相关数据可能出现在应用程序包中，也可能不出现。它被解释为而不是RTP本身。它必须是32位长的倍数。 |
rfc4585：Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)
Feedback 消息公共头
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| FMT | PT | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Feedback Control Information (FCI) :
: :
Figure : Common Packet Format for Feedback Messages
| 类型 | 长度 | 描述 |
|---|---|---|
| Feedback message type (FMT) | 5 bits | 消息类型 |
| Payload type (PT) | 8 bits | pt值 |
Payload type (PT): 8 bits
This is the RTCP packet type that identifies the packet as being
an RTCP FB message. Two values are defined by the IANA:
Name | Value | Brief Description
----------+-------+------------------------------------
RTPFB | 205 | Transport layer FB message
PSFB | 206 | Payload-specific FB message
Transport Layer Feedback Messages
0: unassigned
1: Generic NACK
2-30: unassigned
31: reserved for future expansion of the identifier number space
Generic NACK
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PID | BLP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure : Syntax for the Generic NACK message
| 类型 | 长度 | 描述 |
|---|---|---|
| Packet ID (PID) | 16 bits | 丢包编号，设置为 RTP sequence number |
| bitmask of following lost packets (BLP) | 16 bits | 位图：第 i 个位置设置 1，则 PID+i 序号的包丢失 |
Payload-Specific Feedback Messages
FMT 参数如下：
0: unassigned
1: Picture Loss Indication (PLI)
2: Slice Loss Indication (SLI)
3: Reference Picture Selection Indication (RPSI)
4-14: unassigned
15: Application layer FB (AFB) message
16-30: unassigned
31: reserved for future expansion of the sequence number space
Picture Loss Indication (PLI)
图像丢失指示消息，其中 PT=PSFB，FMT=1，解码器通知编码器图像数据丢失，接收PLI的编码器意识到预测链可能被破坏。发送方可以通过发送帧内编码图片来对PLI作出反应以完成解码。此消息的 FCI 数据为空。
Slice Loss Indication (SLI)
slice 丢失指示消息，其中 PT=PSFB，FMT=2：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| First | Number | PictureID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure : Syntax of the Slice Loss Indication (SLI)
| 类型 | 长度 | 描述 |
|---|---|---|
| First | 13 bits | 丢失的 slice 的起始 macroblock (MB) 编号 |
| Number | 13 bits | 丢失宏块的数量 |
| PictureID | 6 bits | 参考帧 ID |
Reference Picture Selection Indication (RPSI)
参考图片选择指示消息，其中 PT=PSFB，FMT=3，在发生丢包或解码错误时，请求对端发送关键帧
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PB |0| Payload Type| Native RPSI bit string |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| defined per codec ... | Padding (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure : Syntax of the Reference Picture Selection Indication (RPSI)
| 类型 | 长度 | 描述 |
|---|---|---|
| PB | 8 bits | 填充位的位数 |
| 0 | 1 bits | 传输时必须设置为 0 接收时忽略 |
| Payload Type | 7 bits | Native RPSI bit string 表示的载荷类型 |
| Native RPSI bit string | 可变长度 | 本端视频编解码器定义的 RPSI 信息 |
| Padding | 填充位 |
Application layer FB (AFB) message
rfc5104：Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)
Transport Layer Feedback Messages
Assigned in AVPF [RFC4585]:
1: Generic NACK
31: reserved for future expansion of the identifier number space
Assigned in this memo:
2: reserved (see note below)
3: Temporary Maximum Media Stream Bit Rate Request (TMMBR)
4: Temporary Maximum Media Stream Bit Rate Notification (TMMBN)
Available for assignment:
0: unassigned
5-30: unassigned
Temporary Maximum Media Stream Bit Rate Request (TMMBR)
临时最大媒体比特率请求消息，其中 PT=RTPFB，FMT=3：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MxTBR Exp | MxTBR Mantissa |Measured Overhead|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure - Syntax of an FCI Entry in the TMMBR Message
MxTBR Exp (6 bits): [0..63].
MxTBR Mantissa (17 bits)：2^17 = 131072
Measured Overhead (9 bits): 测量的平均开销
MxTBR = mantissa * 2^(Exp)
能够表示的范围：0 ~ 131072*2^63(approximately 1.2*10^24).
Temporary Maximum Media Stream Bit Rate Notification (TMMBN)
临时最大媒体比特率通知响应消息，其中 PT=RTPFB，FMT=4：同上
Payload-Specific Feedback Messages
Assigned in [RFC4585]:
1: Picture Loss Indication (PLI)
2: Slice Lost Indication (SLI)
3: Reference Picture Selection Indication (RPSI)
15: Application layer FB message
31: reserved for future expansion of the number space
Assigned in this memo:
4: Full Intra Request (FIR) Command
5: Temporal-Spatial Trade-off Request (TSTR)
6: Temporal-Spatial Trade-off Notification (TSTN)
7: Video Back Channel Message (VBCM)
Unassigned:
0: unassigned
8-14: unassigned
16-30: unassigned
Full Intra Request (FIR)
完整帧请求消息，其中 PT=RTPFB，FMT=4,新的参与者加入，就需要发送一个 FIR，通知其他的参与者发送一个关键帧，从而实现解码
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq nr. | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure - Syntax of an FCI Entry in the FIR Message
| 类型 | 长度 | 描述 |
|---|---|---|
| SSRC | 32 bits | 被请求发送解码器刷新点的媒体发送器的 SSRC 值 |
| Seq nr. | 8 bits | 命令序列号 |
Temporal-Spatial Trade-off Request (TSTR)
时空交换请求
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq nr. | Reserved | Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure - Syntax of the TSTR
| 类型 | 长度 | 描述 |
|---|---|---|
| SSRC | 32 bits | 被请求应用索引中给定的折衷值的媒体发送方的 SSRC 值 |
| Seq nr. | 8 bits | 请求序列号，每一个新的命令该序列号加一 |
| Reserved | 19 bits | 保留位 |
| Index | 5 bits | 指示请求的相对折衷值 |
Temporal-Spatial Trade-off Notification (TSTN)
时空交换响应，同上
H.271 Video Back Channel Message (VBCM)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq nr. |0| Payload Type| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VBCM Octet String.... | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure - Syntax of an FCI Entry in the VBCM
扫一扫
4075
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
