RTP/RTCP

RTP

RTP: A Transport Protocol for Real-Time Applications 本文档描述了实时传输协议 RTP 。

RTP - 实时传输协议（Real-Time Transport Protocol）为具有实时特征的数据（如交互式音频和视频）提供端到端传输服务，包括：payload type identification, sequence number, timestamp, delivery monitor (RTCP-RR & SR)。Application 通常在 UDP 上传输 RTP，当然也可以在 TCP 上传输 RTP 。当然，如果底层网络（IP）支持，RTP 支持使用多播将输出传输到多个目的地。

注意：RTP 不提供任何机制来确保及时交付、保证交付、有序交付或其他服务质量保证，而是依靠其他服务来实现这一点（例如：TWCC 反馈、GCC/BBR 拥塞控制、带宽分配、Nack 等）。

虽然 RTP 主要是为满足多参与者的多媒体会议的需求而设计的，但实际上 RTP 并不局限于特定的应用程序。在数据存储、交互式分布式模拟、控制和测量等应用也可能发现 RTP 的适用性。

RTP 其实由紧密相连的两部分组成：

Real-Time Transport Protocol ：
RTP Control Protocol (RTCP) ：用于监控服务质量（RR、SR、TWCC）、请求重传（NACK）、请求关键帧（NACK-PLI/FRI）等控制需求。

RTP是一个故意不完整的协议框架。在传统协议中，可以通过使协议更加通用或添加需要解析的选项机制来适应附加功能，RTP则不同，RTP旨在根据需要通过修改和/或添加 headers (扩展头) 来进行定制。因此，下文会提到 RTP Header Extension 对 RTP 进行扩展。

RTP 需要结合其他文档一同使用。比如：RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP) 作为一个 profile specification document (配置文件规范文档) 定义了一组有效载荷类型（payload type）到有效载荷（payload）的映射，一个 profile 还可以对特定类应用程序的 RTP 进行扩展或修改。又如：Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF) 定义 Audio-Video Profile（AVP）的扩展：Audio-visual Profile Feedback（AVPF），常用的 PLI 便是在 AVPF 中进行了定义。

RTP Data Transfer Protocol

RTP Fixed Header Fields

RTP header （固定字段部分）格式如下：

    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             |
   |                             ....                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

字段含义：

version (V) ：2 bits，标识 RTP 版本，RFC3550 定义了两个版本，值 1 用于 RTP 的第一个草案版本，值 0 用于在 vat 音频工具中最初实现的协议版本。
padding (P) ：1 bi，如果 padding 被设置为 1 ，则标识 packet 的末尾包含不属于 payload 的填充字节。填充字节的最后一个字节包含填充应该忽略的填充字节数（包括它本身）。使用场景：某些具有固定大小的加密算法或在较低层协议数据单元中携带多个 RTP 包时可能需要填充。
extension (X) ：1 bits，如果 extension 被设置为 1，则标识 fixed header 后紧跟一个 header extension 。
CSRC count (CC) ：4 bits，CSRC count 为 fixed header 中 CSRC list 中的 items 个数。
maker (M) ：1 bit，由 profile 定义，通常用于在 packet 中标记帧边界等重要事件。当然，profile 可以额外定义标记位，或者通过改变 payload type 中的位数（7bit 改变 8bit）来弃用标记位。
payload type (PT) ：7 bits，标识 RTP payload 的格式/类型。
sequence number ：16 bits，序列号，初始值应该随机（以使已知明文对加密的攻击更加困难），每发送一个RTP数据包，序列号增加 1 ，接收方可以使用它来检测丢包和恢复包序列。
timestamp ：32 bits，时间戳。
- 时间戳反映当前 RTP 数据包中第一个字节的采样时间。采样时间必须来自一个时间上单调线性递增的时钟（clock），以允许同步和抖动计算。时钟的分辨率必须足够满足所需的同步精度和测量包到达抖动(每个视频帧一个滴答声通常是不够的)。时钟频率依赖于作为 payload 的数据格式，在定义格式的 profile 或 payload format specification 中静态指定或可以通过其他方法（如 SDP）定义的 payload format 动态指定。如果 RTP 包是周期性产生的，则使用从采样时钟确定的名义采样时间，而不是读取系统时钟。例如，对于固定速率的音频，时间戳时钟可能会在每个采样周期增加1，如果一个音频应用程序从输入设备读取包含 160 个采样周期的块，那么对于每个这样的块，时间戳将增加160，无论该块是在包中传输还是以静默方式丢弃。
- 初始值：时间戳的初始值应该是随机的，就像序列号一样。如果几个连续的RTP包(逻辑上)是同时生成的，例如属于同一个视频帧，那么它们将具有相同的时间戳。如果数据不是按照采样的顺序传输的，连续的 RTP 包可能包含非单调的时间戳，就像MPEG插值视频帧的情况一样 (不过传输的数据包的序列号仍然是单调的)。
- 音视频同步：不能根据该时间戳进行同步。原因：来自不同媒体流（音频，视频-摄像头、屏幕共享）的 RTP 时间戳可能以不同的速度前进，通常具有独立的随机偏移量。因此，尽管这些时间戳足以重建单个流的时间，但直接比较来自不同媒体流的 RTP 时间戳对于同步是无效的。音视频同步解决方案：每一种媒体的RTP 时间戳与 payload 采样瞬间 的参考时钟 (wallclock) 的时间戳配对（得到时间戳对），参考时钟 (wallclock) 由所有要同步的媒体共享，时间戳对 并不在每个数据包中传输，而是在 RTCP SR 数据包中以较低的速率传输。选择采样瞬间作为 RTP 时间戳的参考点的原因：该方式对所有媒体都有共同的定义，与编码延迟或其他处理无关，其目的是在播放时同步显示同时采样的所有媒体。
- 传输存储数据（录制的媒体文件）的时间戳：传输存储数据而不是实时采样数据的应用程序通常使用从 wallclock 时间派生的虚拟时钟表示的时间线来确定存储数据中的下一帧或每个媒体的其他单元应该何时呈现。在这种情况下，RTP时间戳将反映每个单元的呈现时间。不过，实际呈现发生在一段时间后，由接收者决定。
- 以现场音频（实时的）解说预录视频（录制的）为例，说明选择采样时刻作为参考点的意义。在这种情况下，视频将在本地呈现，供解说员观看，同时使用 RTP 传输视频。视频的 RTP 包 timestamp 配对的 “采样瞬间” 引用视频帧呈现给叙述者时的 wallclock 的时间。解说员的音频 RTP 包 timetamp 配对的 采样瞬间 采用音频采样时与视频相同的 wallclock 的时间。如果两个主机上的参考时钟通过某种方式(如NTP)同步，则音频和视频甚至可以在不同的主机上传输。接收端可以使用RTCP SR包中的时间戳对关联音频和视频包的RTP时间戳，从而同步音频和视频包的表示。（RTP- video - timestamp1，RTP - audio - timestamp2，RTCP SR - {timestamp1:timestamp3; timestamp2:timestamp3}）
SSRC ：32 bits，标识同步源，应该随机生成，同一个 RTP 会话中两个不同的同步源的 SSRC 不应该相同。
CSRC list ：0-15 items，32 bits each，CSRC 标识数据包中所包含的 payload 的来源，list 的数量由 CC 字段给出，如果超过 15 个源，则只能确定 15 个。例如：对于音频包，将混合在一起的音频构成的 payload 中的所有源 SSRC 标识符列出来（列在 CSRC list 中），接收端可根据 CSRC list 中的 SSRC 正确指示说话者。

RTP Header Extension

RTP Header Extension 提供了一种扩展机制，允许各个实现尝试新的与 payload format 无关的实现方法，这些实现方法需要在 RTP 数据包头中携带额外的信息。当然，RTP Header Extension 被设计成可以被其他未扩展的实现忽略。

注意，此头扩展仅用于有限的使用，固定头扩展的处理成本较低，因为它不是有条件的，也不在可变位置；而头扩展增加了处理成本。建议：特定 payload format 所需的附加信息不应使用此头扩展，而应在包的有效载荷部分中携带。

    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 Fixed Header 中的 X 为 1，则意味着在 RTP Fixed Header 后跟一个可变长度的RTP Header Extension ，只能将一个 Extension 附加到 RTP Fixed Header。Header Extension 包含一个16位 length 的字段，用于计算 Extension 中 32位 words的数量，length 不包括前4字节的 Extension header (因此0是有效长度)。Extension header 前16位是开放的，用于区分标识符或参数，这16位的格式将由运行实现的配置文件规范定义。

思考：如果需要多个 extension 怎么办？在 RTP 仅支持的一个 extension 中自行定义 defined by profile 表示包含多个 extensions 。

例如：

    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              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      defined by profile       |           length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        header extension                       |
   |                             ....                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      defined by profile       |           length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        header extension                       |
   |                             ....                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      defined by profile       |           length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        header extension                       |
   |                             ....                              |

已有的 RTP Header Extension ：

用于实现 REMB 的 send timestamp 扩展。
... ...

RTCP

RTCP 功能：

提供关于数据分发质量的 feedback 。
RTCP为RTP源携带一个持久的传输级别标识符，称为 canonical name 或CNAME。由于 SSRC 标识符可能在发现冲突或重新启动程序时发生变化，接收方需要 CNAME 来跟踪每个参与者。接收者可能还需要基于 CNAME 将来自给定参与者的多个数据流关联到一组相关的RTP会话中，例如同步音频和视频。媒体间同步还需要数据发送方在RTCP数据包中包含 NTP （Nature Timestamp）和 RTP 时间戳。
.
.

RFC3550 定义了几种RTCP包类型来携带各种控制信息：

SR ：Sender report，用于报告发送者的传输统计数据。
RR ：Receiver report，用于报告接收者的接收统计数据。
SDES：Source description items，包括 CNAME（canonical name）、用户名、电话、邮箱等。
BYE：表示结束。
APP：Application-sepcific functions ，应用程序可自定义的 function，可用于定义私有协议。

每个RTCP数据包以一个类似于RTP数据包的固定部分开始，随后是结构化元素，根据数据包类型可以是可变长度的，但必须以32位边界结束。每个 RTCP 数据包的对齐要求和固定部分的长度字段都包括在内，以使RTCP数据包“可堆叠”。

 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|    --   |      PT      |             length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               SSRC                            |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

version (V)：2 bits，标识 RTCP 版本，RFC3550 定义的版本为 2 。
padding (P)：1 bit，如果 padding 被设置为 1 ，则标识 packet 的末尾包含不属于控制信息的填充字节（但是包含在长度字段中）。填充字节的最后一个字节包含应该忽略的填充字节数（包括它本身）。使用场景：某些具有固定大小的加密算法可能需要填充。在一个复合RTCP包中，填充只需要在一个单独的包上，因为复合包在 [rfc3550-section-3.1] 的加密方法中作为一个整体加密。因此，填充只需要添加到最后一个单独的包，如果填充添加到该包，则填充位只设置在该包上。
--：5 bit，不同的 payload type 下，-- 表示的含义如下：
- SR：0，无意义。
- RR：包中 report block 的数量。可为 0 表示无 report block 。
- SC：包中 SSRC chunk 的数量。
- BYE：包中 SSRC chunk 的数量。
- APP：subtype，子类型。
packet type (PT)：16 bits，包类型，标识 RTCP 报文。
length：16 bits，RTCP 包 32-bit words 的数量减 1。RTCP 包 length 以 32-bit（4字节）为单位，不足 32-bit 则补齐 32-bit，包括 header 和 padding。（减1是使0成为有效长度，避免扫描复合 RTCP 包时出现的无限循环，而采用 32-bit words 计算是为了避免对 4 的倍数进行有效性检查）
SSRC：32 bits，源标识符

compound RTCP packet ：多个RTCP报文可以在不需要任何分隔符的情况下连接在一起，形成一个复合RTCP报文（compound RTCP packet），作为一个较低层协议 (如 UDP) 的单包发送。在复合包中没有显式的单个 RTCP 包计数，因为下层协议期望提供一个总体长度来确定复合包的结束。因此，根据总体长度确定复合包的结束。

RTCP compound format：

 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|    --   |      PT      |             length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               SSRC                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               BODY                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |V=2|P|    --   |      PT      |             length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               SSRC                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               BODY                            |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

compound 包中的每个RTCP包可以独立处理，对包的顺序或组合没有要求。然而，为了实现协议的功能，有以下约束:

接收统计信息 (在SR或RR中) 应该在带宽限制允许的情况下尽可能频繁地发送，以最大限度地提高统计信息的分辨率，因此每个周期性传输的复合RTCP包必须包含一个报告包。
新的接收端需要尽快接收到源的 CNAME，以识别源并开始为诸如口型同步等目的关联媒体，因此每个复合RTCP包也必须包含SDES CNAME，除非复合RTCP包被分割为部分加密。

因此，RTCP数据包可以至少两个单独数据包的复合数据包的形式发送，顺序如下:

Encryption prefix：当且仅当复合包要按照 [rfc3550-section-3.1] 中的方法加密时，每个复合包必须以一个随机的32位数作为前缀，为每个传输的复合包重绘。如果加密需要填充，则必须将其添加到复合包的最后一个包中。
SR 或 RR：复合包中的第一个 RTCP 包必须总是一个报告包。即使没有数据发送或接收，在这种情况下，一个空的RR必须被发送，即使复合包中唯一的另一个RTCP包是BYE，这也是正确的。
Additional RRs ：如果要报告接收统计信息的源的数量超过了31个，那么一个SR或RR包就可以容纳这个数量，那么附加RR包应该在初始报告包之后。
SDES：包含 CNAME 项的 SDES 包必须包含在每个复合RTCP包中，除非。

BYE 或 APP：其他 RTCP 数据包类型，包括那些尚未定义的，可以按照任何顺序，除了BYE应该是与给定SSRC/CSRC一起发送的最后一个数据包。包类型可以出现多次。

Example of an RTCP compound packet：

   |
   |[--------- packet --------][---------- packet ----------][-packet-]
   |
   |                receiver            chunk        chunk
   V                reports           item  item   item  item
   --------------------------------------------------------------------
   R[SR $sendinfo $site1$site2][SDES $CNAME PHONE $CNAME LOC][BYE$$why]
   --------------------------------------------------------------------
   |                                                                  |
   |<-----------------------  compound packet ----------------------->|
   |<--------------------------  UDP packet ------------------------->|

$: SSRC/CSRC identifier

RTCP 传输间隔

RTP允许应用程序自动扩展会话大小，会话的参与者可能从几个到数千个。通常，在一个音频会议中，数据流量本质上是自我限制的，因为一次只有一到两个人发言，所以在多播分发中，任何给定链路上的数据速率都保持相对恒定，与参与者的数量无关。但是，控制流量不是自我限制的，如果每个参与者的接收报告以恒定的速率发送，则控制流量将随参与者的数量线性增长。因此，必须通过动态计算RTCP报文之间的传输间隔来降低速率。

对于固定的最小RTCP报文传输间隔，建议值为5秒。

随着参会者的增加，RTCP报文传输间隔应该动态调整，计算方法：[Computing the RTCP Transmission Interval] 。

RTCP Packets

RTCP Packet Types

   abbrev.  name                 value
   SR       sender report          200
   RR       receiver report        201
   SDES     source description     202
   BYE      goodbye                203
   APP      application-defined    204

SR: Sender Report RTCP Packet

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P|    RC   |   PT=SR=200   |             length            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         SSRC of sender                        |
       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
sender |              NTP timestamp, most significant word             |
info   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |             NTP timestamp, least significant word             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         RTP timestamp                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     sender's packet count                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      sender's octet count                     |
       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report |                 SSRC_1 (SSRC of first source)                 |
block  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1    | fraction lost |       cumulative number of packets lost       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           extended highest sequence number received           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      interarrival jitter                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         last SR (LSR)                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   delay since last SR (DLSR)                  |
       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report |                 SSRC_2 (SSRC of second source)                |
block  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2    :                               ...                             :
       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
       |                  profile-specific extensions                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

NTP timestamp ：64 bits，发送报告时的 wallclock 时间。
RTP timestamp：32 bits，指示与 NTP timestamp 相同 wallclock 时间的 RTP timestamp，RTP timestamp 与数据包中的 RTP timestamp 的单位和随机偏移相同，即虽然和 NTP timestamp 表示的 wallclock 时间相同，但是数值不同，因此可以建立一个 RTP timestamp 到 NTP timestamp 的映射，从而得到 RTP timestamp 的 NTP timestamp 。音视频同步基于 RTP timestamp 映射的 NTP timestamp 后进行。
sender's packet count：32 bits，从开始传输到SR报文产生为止，发送方发送的RTP数据包总数。如果发送方改变了它的SSRC标识，计数应该被重置。
sender's octet count：32 bits，从开始传输到SR数据包生成为止，发送方发送的RTP数据包的 payload 字节数(即，不包括头或填充)。如果发送方改变了它的SSRC标识，计数应该被重置。该字段可用于估计平均有效载荷数据速率。
SSRC_n：32 bits，此接收报告块中的信息所属的源的SSRC标识符。
fraction lost：8 bits，从源 SSRC_n 发送上一个SR或RR报文以来，RTP数据包丢失的百分比，用二进制点在字段左边缘的固定点数表示。(这相当于用损失分数乘以256后的整数部分。) 这个分数被定义为丢失的包数除以预期的包数。如果由于重复而损失为负，则损失的分数设置为零。请注意，接收方无法判断在接收到最后一个包后是否有任何包丢失，如果在最后一个报告间隔内从该源发送的所有包都丢失了，则不会为该源发出接收报告块。
cumulative number of packets lost：24 bits，从接收开始以来，从源SSRC_n丢失的RTP数据包总数。这个数字定义为期望的包数减去实际收到的包数，其中收到的包数包括任何延迟或重复的包数。因此，延迟到达的数据包不被计算为丢失，如果有重复的数据包，则丢失可能为负。预期的包数定义为接收到的扩展的最后序列号(如next所定义)减去接收到的初始序列号。可按附录A.3计算。（）
extended highest sequence number received：32 bits，低16位包含源SSRC_n收到的RTP数据包的最高序列号，最高16位对该序列号进行了相应的序列号循环数的扩展，可根据附录A.1中的算法进行维护。注意，同一会话中的不同接收者会产生差异。
interarrival jitter：32 bits，一对包在接收端（到达时的 RTP timestamp）与发送端（封装时的 RTP timestamp（包头提取））之间的包间距差D(i,j)的平均偏差(平滑绝对值)J(i)：
- D(i,j) = (Rj - Ri) - (Sj - Si) = (Rj - Sj) - (Ri - Si)
- J(i) = J(i-1) + (|D(i-1,i)| - J(i-1))/16
- Si 是数据包 i 的RTP时间戳，Ri 是数据包 i 的RTP时间戳单位的到达时间
- 增益参数 1/16 在保持合理收敛速率的同时，具有较好的降噪率。
last SR timestamp (LSR)：32 bits，从源 SSRC_n 收到的最近一个 SR 报文中的 NTP timestamp 中 64位中的中间 32位。如果还没有收到SR，则该字段置零。
delay since last SR (DLSR)：32 bits，从源 SSRC_n 收到的最近一个 SR 报文到发送此 接收报告块 之间的延迟，以1/65536秒为单位。如果还没有收到来自 SSRC_n 的 SR 报文，则将DLSR字段置零。

RR: Receiver Report RTCP Packet

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P|    RC   |   PT=RR=201   |             length            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     SSRC of packet sender                     |
       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report |                 SSRC_1 (SSRC of first source)                 |
block  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1    | fraction lost |       cumulative number of packets lost       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           extended highest sequence number received           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      interarrival jitter                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         last SR (LSR)                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   delay since last SR (DLSR)                  |
       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report |                 SSRC_2 (SSRC of second source)                |
block  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2    :                               ...                             :
       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
       |                  profile-specific extensions                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

SDES: Source Description RTCP Packet

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P|    SC   |  PT=SDES=202  |             length            |
       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
chunk  |                          SSRC/CSRC_1                          |
  1    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           SDES items                          |
       |                              ...                              |
       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
chunk  |                          SSRC/CSRC_2                          |
  2    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           SDES items                          |
       |                              ...                              |
       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

SDES Types

   abbrev.  name                            value
   END      end of SDES list                    0
   CNAME    canonical name                      1
   NAME     user name                           2
   EMAIL    user's electronic mail address      3
   PHONE    user's phone number                 4
   LOC      geographic user location            5
   TOOL     name of application or tool         6
   NOTE     notice about the source             7
   PRIV     private extensions                  8

CNAME: Canonical End-Point Identifier SDES Item

    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=1    |     length    | user and domain name        ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

NAME: User Name SDES Item

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     NAME=2    |     length    | common name of source       ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

EMAIL: Electronic Mail Address SDES Item

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    EMAIL=3    |     length    | email address of source     ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

PHONE: Phone Number SDES Item

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    PHONE=4    |     length    | phone number of source      ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

LOC: Geographic User Location SDES Item

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     LOC=5     |     length    | geographic location of site ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

NOTE: Notice/Status SDES Item

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     NOTE=7    |     length    | note about the source       ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

PRIV: Private Extensions SDES Item

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     PRIV=8    |     length    | prefix length |prefix string...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ...             |                  value string               ...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

BYE: Goodbye RTCP Packet

       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                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                              ...                              :
      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
(opt) |     length    |               reason for leaving            ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

APP: Application-Defined RTCP Packet

    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                ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

AVP

RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP) 本文档描述了一个名为 RTP/AVP 的配置文件（Profile），用于 RTP 。

RTP (RTP/AVP)音频/视频配置文件是RTP (Real-time Transport Protocol)协议的一种配置文件，用于指定音视频流的技术参数。RTP指定了一种通用的数据格式，但没有指定编码后的数据应该如何利用RTP的特性(在RTP标头中放入什么有效载荷类型值，要使用什么采样率和时钟率(RTP时间戳增量的速率)，等等)。RTP音频/视频配置文件指定了特定音频和视频编解码器及其采样率到RTP有效负载类型和时钟率的映射，以及如何将每种数据格式编码为RTP数据有效负载，以及指定如何使用会话描述协议(Session Description Protocol, SDP)描述这些映射。感兴趣可以读 rfc3551 或 RTP_audio_video_profile 。

AVP 适用于在音频和视频会议中使用，特别是不支持参数协商或成员控制的会话。该配置文件在不使用协商或成员控制的会话中很有用 (例如使用静态有效负载类型) 。

Payload type (PT)	Name	Type	No. of channels	Clock rate (Hz)[note 1]	Frame size (ms)	Default packet size (ms)	Description	References
dynamic (or profile)	AMR	audio	(various)	8000	20		Adaptive Multi-Rate audio	RFC 4867
dynamic (or profile)	AMR-WB	audio	(various)	16000	20		Adaptive Multi-Rate Wideband audio (ITU-T G.722.2)	RFC 4867
dynamic	aptx	audio	2 – 6	(equal to sampling rate)	4000 ÷ sample rate	4[note 4]	aptX audio	RFC 7310
dynamic	ATRAC-ADVANCED-LOSSLESS	audio		(various)			ATRAC Advanced Lossless audio	RFC 5584
dynamic	ATRAC3	audio		44100			ATRAC3 audio	RFC 5584
dynamic	ATRAC-X	audio		44100, 48000			ATRAC3+ audio	RFC 5584
dynamic	BMPEG	video					Bundled MPEG-2 video	RFC 2343
13	CN	audio	1	8000			Comfort noise. Payload type used with audio codecs that do not support comfort noise as part of the codec itself such as G.711, G.722.1, G.722, G.726, G.727, G.728, GSM 06.10, Siren, and RTAudio.	RFC 3389
dynamic	ac3	audio	(various)	32000, 44100, 48000			Dolby AC-3 audio	RFC 4184
dynamic	telephone-event	audio		8000 (default)			DTMF tone	RFC 4733
dynamic	DV	video		90000			DV video	RFC 3189
dynamic	eac3	audio	(various)	32000, 44100, 48000			Enhanced AC-3 audio	RFC 4598
3	GSM	audio	1	8000	20	20	European GSM Full Rate audio 13 kbit/s (GSM 06.10)	RFC 3551
dynamic	EVRC	audio		8000			EVRC audio	RFC 4788
	EVRC0
	EVRC1
dynamic	EVRCB	audio		8000			EVRC-B audio	RFC 4788
	EVRCB0
	EVRCB1
dynamic	EVRCWB	audio		16000			EVRC-WB audio	RFC 5188
	EVRCWB0
	EVRCWB1
7	LPC	audio	1	8000	any	20	Experimental Linear Predictive Coding audio 5.6 kbit/s	RFC 3551
dynamic (or profile)	AMR-WB+	audio	1, 2 or omit	72000	13.3–40		Extended Adaptive Multi Rate – WideBand audio	RFC 4352
34	H263	video		90000			H.263 video, first version (1996)	RFC 3551, RFC 2190
dynamic	H263-1998	video		90000			H.263 video, second version (1998)	RFC 3551, RFC 4629, RFC 2190
dynamic	H263-2000	video		90000			H.263 video, third version (2000)	RFC 4629
dynamic (or profile)	H264 SVC	video		90000			H.264 video	RFC 6190
dynamic (or profile)	H264 AVC	video		90000			H.264 video (MPEG-4 Part 10)	RFC 6184, previously RFC 3984
dynamic (or profile)	H265	video		90000			H.265 video (HEVC)	RFC 7798
dynamic	DAT12	audio	(various)	(various)	any	20 (by analogy with L16)	IEC 61119 12-bit nonlinear audio	RFC 3190 Section 3
5	DVI4	audio	1	8000	any	20	IMA ADPCM audio 32 kbit/s	RFC 3551
16	DVI4	audio	1	11025	any	20	IMA ADPCM audio 44.1 kbit/s	RFC 3551
6	DVI4	audio	1	16000	any	20	IMA ADPCM audio 64 kbit/s	RFC 3551
17	DVI4	audio	1	22050	any	20	IMA ADPCM audio 88.2 kbit/s	RFC 3551
dynamic	iLBC	audio	1	8000	20, 30	20, 30	Internet low Bitrate Codec 13.33 or 15.2 kbit/s	RFC 3952
dynamic	BT656	video					ITU-R BT.656 video	RFC 3555
8	PCMA	audio	1	8000	any	20	ITU-T G.711 PCM A-Law audio 64 kbit/s	RFC 3551
0	PCMU	audio	1	8000	any	20	ITU-T G.711 PCM µ-Law audio 64 kbit/s	RFC 3551
dynamic	PCMA-WB	audio	1	16000	5		ITU-T G.711.1 A-law	RFC 5391
dynamic	PCMU-WB	audio	1	16000	5		ITU-T G.711.1 µ-law	RFC 5391
dynamic	G718	audio		32000 (placeholder)	20		ITU-T G.718	draft-ietf-payload-rtp-g718
dynamic	G719	audio	(various)	48000	20		ITU-T G.719	RFC 5404
9	G722	audio	1	8000[note 2]	any	20	ITU-T G.722 audio 64 kbit/s	RFC 3551 - Page 14
dynamic	G7221	audio		16000, 32000	20		ITU-T G.722.1 and G.722.1 Annex C	RFC 5577
4	G723	audio	1	8000	30	30	ITU-T G.723.1 audio	RFC 3551
dynamic	G726-16	audio	1	8000	any	20	ITU-T G.726 audio 16 kbit/s	RFC 3551
dynamic	G726-24	audio	1	8000	any	20	ITU-T G.726 audio 24 kbit/s	RFC 3551
dynamic	G726-32	audio	1	8000	any	20	ITU-T G.726 audio 32 kbit/s	RFC 3551
dynamic	G726-40	audio	1	8000	any	20	ITU-T G.726 audio 40 kbit/s	RFC 3551
15	G728	audio	1	8000	2.5	20	ITU-T G.728 audio 16 kbit/s	RFC 3551
18	G729	audio	1	8000	10	20	ITU-T G.729 and G.729a audio 8 kbit/s; Annex B is implied unless the annexb=no parameter is used	RFC 3551, Page 20, RFC 3555, Page 15
dynamic	G729D	audio	1	8000	10	20	ITU-T G.729 Annex D	RFC 3551
dynamic	G729E	audio	1	8000	10	20	ITU-T G.729 Annex E	RFC 3551
dynamic	G7291	audio		16000	20		ITU-T G.729.1	RFC 4749
dynamic	GSM-EFR	audio	1	8000	20	20	ITU-T GSM-EFR (GSM 06.60)	RFC 3551
dynamic	GSM-HR-08	audio	1	8000	20		ITU-T GSM-HR (GSM 06.20)	RFC 5993
31	H261	video		90000			ITU-T H.261 video	RFC 4587
dynamic	jpeg2000	video		90000			JPEG 2000 video	RFC 5371
26	JPEG	video		90000			JPEG video	RFC 2435
dynamic	L8	audio	(various)	(various)	any	20	Linear PCM 8-bit audio with 128 offset	RFC 3551 Section 4.5.10 and Table 5
dynamic	L16	audio	(various)	(various)	any	20	Linear PCM 16-bit audio	RFC 3551 Section 4.5.11, RFC 2586
11	L16	audio	1	44100	any	20	Linear PCM 16-bit audio 705.6 kbit/s, uncompressed	RFC 3551, Page 27
10	L16	audio	2	44100	any	20	Linear PCM 16-bit Stereo audio 1411.2 kbit/s,[2][3][4] uncompressed	RFC 3551, Page 27
dynamic	L20	audio	(various)	(various)	any	20 (by analogy with L16)	Linear PCM 20-bit audio	RFC 3190 Section 4
dynamic	L24	audio	(various)	(various)	any	20 (by analogy with L16)	Linear PCM 24-bit audio	RFC 3190 Section 4
dynamic	mpa-robust	audio	1, 2	90000	24–72		Loss-Tolerant MP3 audio	RFC 5219 (previously RFC 3119)
32	MPV	video		90000			MPEG-1 and MPEG-2 video	RFC 2250
14	MPA	audio	1, 2	90000	8–72		MPEG-1 or MPEG-2 audio only	RFC 3551, RFC 2250
dynamic	MP1S	video					MPEG-1 Systems Streams video	RFC 2250
dynamic	MP2P	video					MPEG-2 Program Streams video	RFC 2250
33	MP2T	audio/video		90000			MPEG-2 transport stream	RFC 2250
dynamic (or profile)	MP4A-LATM	audio		90000 or others			MPEG-4 Audio	RFC 6416 (previously RFC 3016)
dynamic (or profile)	mpeg4-generic	audio/video		90000 or other			MPEG-4 Elementary Streams	RFC 3640
dynamic (or profile)	MP4V-ES	video		90000 or others			MPEG-4 Visual	RFC 6416 (previously RFC 3016)
dynamic (or profile)	opus	audio	1, 2	48000[note 3]	2.5–60	20	Opus audio	RFC 7587
12	QCELP	audio	1	8000	20	20	Qualcomm Code Excited Linear Prediction	RFC 2658, RFC 3551
dynamic	RED	audio					Redundant Audio Data	RFC 2198
72–76	reserved						reserved because RTCP packet types 200–204 would otherwise be indistinguishable from RTP payload types 72–76 with the marker bit set	RFC 3550, RFC 3551
19	reserved (previously CN)	audio					reserved, previously comfort noise	RFC 3551
1	reserved (previously FS-1016 CELP)	audio	1	8000			reserved, previously FS-1016 CELP audio 4.8 kbit/s	RFC 3551, previously RFC 1890
2	reserved (previously G721 or G726-32)	audio	1	8000			reserved, previously ITU-T G.721 ADPCM audio 32 kbit/s or ITU-T G.726 audio 32 kbit/s	RFC 3551, previously RFC 1890
dynamic	SMPTE292M	video					SMPTE 292M video	RFC 3497
dynamic (or profile)	speex	audio	1	8000, 16000, 32000	20		Speex audio	RFC 5574
25	CELB	video		90000			Sun CellB video[5]	RFC 2029
dynamic	t140	text		1000			Text over IP	RFC 4103
dynamic (or profile)	theora	video		90000			Theora video	draft-barbato-avt-rtp-theora
dynamic	tone	audio		8000 (default)			tone	RFC 4733
dynamic	UEMCLIP	audio		8000, 16000			UEMCLIP audio	RFC 5686
dynamic	raw	video		90000			Uncompressed Video	RFC 4175
dynamic	VDVI	audio					Variable-rate DVI4 audio	RFC 3551
dynamic (or profile)	vorbis	audio	(various)	(various)			Vorbis audio	RFC 5215
dynamic	VP8	video		90000			VP8 video	RFC 7741
dynamic	VP9	video		90000			VP9 video	draft-ietf-payload-vp9
28	nv	video		90000			Xerox PARC's Network Video (nv)[6]	RFC 3551, Page 32

clock rate 是RTP报头中的时间戳增量的速率，它不需要与编解码器的采样速率相同。例如，视频编解码器通常使用90000的 clock rate，因此它们的帧可以更精确地与RTCP NTP时间戳对齐，即使视频采样率通常在每秒1-60个样本的范围内。
虽然 G.722 的采样率是16000，但它的 clock rate 是8000，以保持向后兼容RFC 1890, RFC 1890错误地使用了这个值。
因为 Opus 可以动态地改变采样率，它的 clock rate 固定在48000，即使编解码器将以较低的采样率操作。SDP 中的 maxplaybackrate 和 sprop-maxcapturerate 参数可用于指示关于编码/解码的最大采样率的提示/首选项。
对于aptX，封包化间隔必须取四舍五入到可以包含整数个样本的最接近的包间隔。因此，当采样率为11025、22050 或 44100 时，“4”的分组率舍入到3.99。
该配置文件还为每个编码分配一个短名称（Name），可被高级控制协议使用，如会话描述协议(SDP)。
dynamic 的 payload type 在会话描述协议(SDP)和ITU-T建议H.323/H.245等其他协议中指定。

RFC 3551列出了部分有效载荷格式的详细信息，提供了详细信息的参考。有效负载标识符 96-127 用于在会话期间动态定义的有效负载。

RTP/AVPF

Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF) 定义 Audio-Video Profile（AVP）的扩展：Audio-visual Profile Feedback（AVPF）。

Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF) 通过两处修改/增加，指定了音视频会议的 RTP profile 的最小控制：首先，为了实现及时反馈，引入了早期 RTCP 消息的概念（FB message）以及允许在小组播组中进行低延迟反馈 (并防止在大组播组中发生反馈爆炸) 的算法。其次，定义了少量通用反馈消息以及特定于编解码器和特定于应用程序的反馈信息的格式，以便在RTCP有效负载中传输。

定义

Event：接收方对媒体流所做的观察，它(可能)与发送方有关，如包丢失或包接收、帧丢失等，因此接收方可以通过 Feedback (FB) message 的方式向发送方报告。

Early RTCP mode：一种操作模式，媒体流的接收方通常 (但不总是) 能够在 Event 发生不久后向发送方报告相关事件。在 Early RTCP mode 下，RTCP报文按照 [RTP/AVPF] 定义的定时规则进行传输。

Early RTCP packet：一个 Early RTCP packet 是一个 RTCP packet 的发送时间比按照 [rfc3550] 的调度算法允许的时间要早，原因是接收端观察到的一个 Event （此时需要提前做出反馈）。Early RTCP packet 有两种发送方式：Early RTCP mode 和 Immediate Feedback mode。Early RTCP packet 也称为 Early Feedback。

Feedback (FB) message：RTCP消息，用于向媒体流的发送方传递关于在接收端观察到的事件的信息 —— RTCP receiver reports(RRs) 携带的长期接收端状态信息之外的信息。feedback message 也被称为 FB message。

Immediate Feedback mode：一种操作模式，媒体流的每个接收方在统计上都能够立即向媒体流发送方报告每个感兴趣的事件。在 Immediate Feedback mode 下，RTCP FB message 按照 [RTP/AVPF] 定义的定时规则进行传输。

Regular RTCP mode：不允许优先传送 FB messages 的操作模式。RTCP消息按照 [rfc3550] 的规则发送。不过，这样的RTCP消息仍可以包含 RTCP FB message 。

Regular RTCP packet：不作为 Early RTCP packet 发送的 RTCP packet。

描述

[RTP/AVPF] 中描述的基于RTCP的反馈由两个部分组成：

status reports 包含在发送方报告(SR)/接收方报告(RR)包中，并作为复合RTCP包（compound RTCP packets）的一部分定期传送；这些状态报告提供了媒体流最近接收质量的总体指示。
FB messages 表示媒体流的特定片段丢失或接收 (或对接收到的数据提供某种其他形式的相当即时的反馈)，并新增 FB messages 的传输规则。

RTCP FB messages 只是另一种RTCP包类型。因此，多个 FB messages 可以组合在一个单一的复合RTCP包（compound RTCP packets）中，它们也可以与其他RTCP 包组合发送。

包含 [RTP/AVPF] 定义的 RTCP FB messages 的复合RTCP报文必须按照 [rfc3550] 定义的顺序；FB消息必须放在 [rfc3550] 中定义的RR和SDES RTCP报文之后的复合包中。除此之外，没有定义相对于其他RTCP扩展的顺序。

文档使用了两种带反馈报文的复合RTCP报文：

最小复合RTCP反馈包：一个最小的复合RTCP反馈包必须只包含上面列出的必须信息：加密前缀(如果需要的话)，恰好一个RR或SR，恰好一个只有CNAME项的SDES，以及 FB messages 。这是为了最小化用于传递反馈的RTCP数据包的大小，而最大化提供反馈的频率，同时遵守RTCP带宽限制。当 RTCP FB messages 作为 Early RTCP packet 的一部分发送时，应该使用这种包格式。
全复合RTCP反馈包：一个(完整的)复合 RTCP 反馈包可以包含任何额外数量的RTCP包(额外的RR，进一步的SDES items，等等)。当然， RTCP FB messages 作为 Regular RTCP packet 的一部分以 Regular RTCP mode 发送时，必须使用此数据包格式。它也可以用在 Immediate Feedback mode 或 Early RTCP mode 下。这种报文类型在本文中称为全复合RTCP报文。

不包含 RTCP FB messages 的RTCP报文称为非FB RTCP报文。

RTCP 反馈运行规则、模式、算法

SDP 定义

profile 标识

[rfc3551] 在 SDP 中的标识为 AVP。
Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF) 在 SDP 中的标识为 AVPF
除非 SDP 表明使用 AVPF ，否则不得为特定媒体会话发送 RTP/AVPF 中指定的反馈信息。

RTCP 反馈能力属性。

定义新的 SDP 属性以表示 RTCP 反馈能力：a=rtcp-fb 。

a=rtcp-fb 语法：a=rtcp-fb:rtcp-fb-pt SP rtcp-fb-val CRLF

SP 表示空格
CRLF 表示行尾
rtcp-fb-pt
- * 表示适用于所有 payload type
- fmt 表示指定 payload type
rtcp-fb-val
- ack rtcp-fb-ack-param
- nack rtcp-fb-nack-param
- trr-int SP 1*DIGIT
- rtcp-fb-id rtcp-fb-param
rtcp-fb-id：字母、数字、"-"、"_" 的组合
rtcp-fb-param：
- SP app：[SP byte-string]
- SP token：[SP byte-string]
- 空
rtcp-fb-ack-param：
- SP rpsi
- SP app：[SP byte-string]
- SP token：[SP byte-string]
- 空
rtcp-fb-nack-param：
- SP pli
- SP sli
- SP rpsi
- SP app：[SP byte-string]
- SP token：[SP byte-string]
- 空

ack ：表示支持反馈的 ack。其中，rpsi 表示使用 Reference Picture Selection Indication 反馈。app 表示使用应用层反馈。在 app 后面可以提供额外的参数，以区分不同类型的应用层反馈。文档中没有定义特定于 app 的参数。

nack ：表示支持的 nack。其中，pli 表示 Picture Loss Indication 反馈。sli 表示 Slice Loss Indication 反馈。rpsi 表示 Reference Picture Selection Indication 反馈。app 表示使用应用层反馈。在 app 后面可以提供额外的参数，以区分不同类型的应用层反馈。文档中没有定义特定于 app 的参数。空 表示使用 Generic NACK 。

其他反馈类型：可以在其他文件中定义其他类型的反馈; 为了保持语法对这些情况的可扩展性，引入 rtcp-fb-id 作为占位符。

trr-int ：指定此媒体会话的两个常规（完全复合）RTCP Packet 之间的最小间隔。

RTCP 带宽修改器
b=RS:<bw>
b=RR:<bw>
示例

      v=0
      o=alice 3203093520 3203093520 IN IP4 host.example.com
      s=Multicast video with feedback
      t=3203130148 3203137348
      m=audio 49170 RTP/AVP 0
      c=IN IP4 224.2.1.183
      a=rtpmap:0 PCMU/8000
      m=video 51372 RTP/AVP 98 99
      c=IN IP4 224.2.1.184
      a=rtpmap:98 H263-1998/90000
      a=rtpmap:99 H261/90000
      m=video 51372 RTP/AVPF 98 99
      c=IN IP4 224.2.1.184
      a=rtpmap:98 H263-1998/90000
      a=rtpmap:99 H261/90000
      a=rtcp-fb:* nack
      a=rtcp-fb:98 nack rpsi

Format of RTCP Feedback Messages

本节定义 low-delay RTCP feedback messages 的格式。这些消息分为以下三类：

Transport layer FB messages ：旨在传输通用反馈信息，即独立于特定编解码器或正在使用中的应用程序的信息。预计信息将在传输层/RTP层生成和处理。目前，只定义了 Generic NACK 消息。（比如：）
Payload-specific FB messages ：传输特定于指定有效负载类型的信息，这些信息将在编码器层生成并加以处理。比如：PLI（Picture Loss Indication），SLI（Slice Loss Indication），RPSI（Reference Picture Selection Indication）等。
Application layer FB messages ：提供一种可以透明地将 feedback 从接收方传送到发送方的应用程序的方法。这种消息中包含的信息不是预期在传输层或RTP层或编解码器层上起作用的。而是要在两个 application instances 之间交换的数据，通常在应用程序协议规范中定义，可以由应用程序识别，而不需要额外的外部信息。因此，该文档仅定义了与所有应用层FB消息一起使用的公共标头。从协议的角度来看，应用层FB消息被视为特定于有效负载的FB消息的特殊情况。

Common Packet Format for Feedback Messages

    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)                 :
   :                                                               :

Feedback message type (FMT) ：5 bits，
Payload type (PT)：8 bits，RTCP 报文类型，用来标识该报文是 RTCP FB message。 [rfc4585] 定义了两个值：
- RTPFB：205，Transport layer Feedback messages 。
- PSFB：206，Payload-specific Feedback messages （PLI、SLI、RPSI）。
SSRC of packet sender：32 bits，packet sender 的 SSRC 。
SSRC of media source：32 bits，此反馈信息相关的媒体源的 SSRC 。
Feedback Control Information (FCI)：可变长度。接下来三个部分将定义：对于每种类型的反馈，哪些附加信息（ transport layer feedback, payload-specific feedback, or application layer feedback）可以包含在 FB message 中。

Transport layer FB messages （205）

FMT

0：unassigned
1：Generic NACK
2-30：unassigned
31：reserved for future expansion of the identifier number space

Generic NACK
Feedback Control Information (FCI) ：

    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               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Packet ID (PID)，16 bits，PID 为的丢失的 RTP 包的 sequence number 。
Bitmask of following lost packets (BLP)，16 bits，设 BLP 的最低有效位为第1位，最高有效位为第16位，如果第 i 位被设置为 1 ，则表示 sequence number 为(PID+i)%(2^16) 的包丢失。当 BLP 为 0 时，表示仅有 Packet ID (PID) 这一个包丢失。

Payload-Specific Feedback Messages（206）

FMT

0：unassigned
1：Picture Loss Indication (PLI)
2：Slice Loss Indication (SLI)
3：Reference Picture Selection Indication
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)
语义：
解码器通过 Picture Loss Indication (PLI) Message 将图片的编码视频数据丢失通知编码器。当与任何基于图像间预测的视频编码方案结合使用时，接收PLI的编码器会意识到预测链可能被破坏。接收 PLI 的一端可以通过传输 intra-picture （I帧）来对PLI作出反应，以实现重同步 (使此消息有效地类似于 [rfc2032:RTP Payload Format for H.261 Video Streams] 中定义的 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |V=2|P|    1   |       206      |             2                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  SSRC of packet sender                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  SSRC of media source                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                 :

PT=206
FMT = 1
Length = 2
无 Feedback Control Information (FCI)

Slice Loss Indication (SLI)
语义：
通过 Slice Loss Indication (SLI) Message，解码器可以将它检测到扫描顺序中一个或几个连续宏块（连续宏块和slice的关系详见：H.264 结构分析）的丢失或损坏通知编码器。

Slice Loss Indication (SLI) Message，不能用于具有非均匀的、动态可变宏块大小的视频编解码器（比如：启用Annex Q的H.263 ）。
Slice Loss Indication (SLI) Message，仅适用于小部分编解码器。

格式：

    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|    2   |       206      |           2 + n               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  SSRC of packet sender                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  SSRC of media source                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            First        |        Number           | PictureID |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            First        |        Number           | PictureID |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
   |                                ...                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

PT=206
FMT = 2
Length = 2 + n ：可以包含 n 个 SLI （First, Number, PictureID）。
First：13 bits，第一个丢失的宏块的宏块地址（macroblock number），宏块编号的方式是：图片左上角的宏块的 macroblock number 为 1 ，剩余宏块的编号按栅格扫描的顺序从左到右，从上到下递增。
Number：13 bits，丢失的宏块数量（按上面的扫描顺序的连续的若干个宏块）。
PictureID：6 bits，图片ID，一些特定编解码器的图片标识符的低6位，用于引用发生宏块丢失的图片。对于许多视频编解码器，PictureID 与 Temporal Reference 是相同的。

Reference Picture Selection Indication（RPSI）
语义：
通过 Reference Picture Selection Indication（RPSI），解码器可向编码端请求丢失的参考图片。

格式：

    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|    3   |       206      |       2 + variable length     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  SSRC of packet sender                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  SSRC of media source                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      PB       |0| Payload Type|    Native RPSI bit string     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   defined per codec          ...                | Padding (0) |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

PT=206
FMT = 3
Length = 2 + variable length ：可变长度。
PB：13 bits，末尾 Padding 的长度，用于补足 32 bits 对齐。
0：13 bits，。
Payload Type：6 bits，Native RPSI bit string 的 RTP payload type。
Native RPSI bit string：variable length，由视频编码定义的数据。MPEG-4和H.263都为RPSI消息的 “Payload ” 定义了一种二进制格式，其中包括受损图片的临时ID和受损区域的大小等信息。这个位串通常很小(几十位)，长度可变，并且自包含，也就是说，包含执行参考图片选择所需的所有信息。
Padding：$PB bits，全部为 0 的 padding，用于补足 32 bits 对齐。

Application Layer Feedback Messages

PT= 206 （Payload-Specific Feedback Messages）
FMT = 15 （Application layer FB （AFB） message）
Application Message (FCI) ：variable length，格式取决于应用程序，必须 32 位对齐（使用 padding）。

More RTCP

RTP Payload Format for H.261 Video Streams

[rfc2032-H.261 control packets definition]

Full INTRA-frame Request (FIR) packet

语义：
Full INTRA-frame Request (FIR) packet 用于向源端请求一个完整的编码图像，以便开始解码一个完整的图像，或者刷新它的图像，并在大量丢失数据包后加速恢复。要求源端编码的下一个图像采用完整的“帧内”编码模式，即不使用差分编码。

格式：

     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|   MBZ   |  PT=RTCP_FIR  |           length              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                              SSRC                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

PT = 192（RTCP_FIR）
length = 1
SSRC：是 the sender of this packet 的同步源标识。

Negative ACKnowledgements (NACK) packet

格式：

  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|   MBZ   | PT=RTCP_NACK  |           length              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                              SSRC                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              FSN              |              BLP              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

PT = 193 （RTCP_NACK）
length = 2
SSRC：是 the sender of this packet 的同步源标识。
First Sequence Number (FSN)：16 bits，标识丢失的 RTP 包的第一个序列号。
Bitmask of following lost packets (BLP)：16 bits，设 BLP 的最低有效位为第1位，最高有效位为第16位，如果第 i 位被设置为 1 ，则表示 sequence number 为(PID+i)%(2^16) 的包丢失。当 BLP 为 0 时，表示仅有 First Sequence Number (FSN) 这一个包丢失。