RTP/RTCP详解

通过IP多播方式建立的一个会议，每个参与者通过某些分配机制（不在本协议讨论范围中）得到一个组地址和2个端口号，一个端口号用来传送RTP数据，即音频数据，另一个用来传输RTCP控制数据。如果需要加密，可根据本协议生成密钥。

会议的每个参与者每隔20ms发送一段音频数据，放在RTP包中。RTP包又通过UDP包传输。RTP包头中定义了音频文件的编码方式，以便参与者改变自己的编码方式以适应网络传输（如编码质量低以适应低带宽传输）。

INTERNET会产生丢包和延迟，所以RTP包头中包含了时间信息和一个序号，序号可以用来使接受方预测丢包的情况。

在本例中，由于会议不时有成员加入或离开，所以每个接受方会每隔一段时间报告一次接受情况。这个信息有可能被用来控制编码方式以适应带宽。当某个成员发出BYE的RTCP包时，该成员离开该会议。
音频、视频信息通过不同的RTP会话（session）传输，即二者是分开传输的。同时对于每一个传输，都有2个端口用来传送RTP数据和RTCP控制信息。

这样做的目的是因为接受者可能由于带宽限制，只够接受音频数据，或他只想接受一种数据。
RTP会话 （RTP SESSION):
   多个参与者通过RTP协议通信，这就形成了一个RTP会话。对于每个参与者来说，RTP会话被一个地址和一对端口号定义。在多媒体会话中，不同的流建立不同的RTP会话（如：音频的会话，视频的会话）。每种不同的会话都有自己的RTCP包。不同的会话靠不同的传输地址来区分
   
   同步化源（SYNCHRONIZATION SOURCE）：
  即SSRC，可理解为信号的源头，如一个麦克风输入或一个摄像头输入，在整个会话中有一个独一无二的标识符。从它输出的信号都经过它的同步处理，以使接受方能实现对源的控制，如回放功能。若一个服务器有多个输入，如多个摄像头信号，那么每个摄像头都有一个SSRC。SSRC标识符靠RTCP绑定。

供流源（CONTRIBUTING SOURCE ）：
   即CSRC，经由混流服务器（MIXER)输出的一个流通常由多个分流汇成，每个分流都有一个供流源。（详见第8章）
   ，CSRC字段只有当MIXER插入时才产生。
   
   RTP协议中，多路传输的目标地址由定义RTP会话的网络地址＋端口号确定。

音视频传输不能定义在同一个RTP会话中，因为负载类型不同而SSRC标识符相同会引起一系列的问题。
SSRC: 32 bits
   同步化源标识符，即此RTP包的发出者（个人理解）。因为一个RTP会话中不能有2个相同的SSRC ，所以当发送者传输地址改变时此值需重新生成，以防止形成循环

CSRC list: 0 to 15 items, 32 bits each
   字段头中CSRC COUNT项给出了该项中ITEM的数量。
   当包通过MIXER时由MIXER将原来包中的SSRC标识符作为CSRC插入，而将MIXER自己的SSRC作为新的SSRC项。
RTCP协议基于每隔一段时间给会话的所有参与者发送一些控制包的机制。下层协议必须支持数据和控制包的多路传输。比如通过UDP协议发送数据到多个端口。

提供数据分布服务质量的反馈。这是RTP作为传输协议必不可少的部分。同时也与别的协议中拥塞和流量控制功能有关。反馈功能主要通过“接受者报告”和“发送者报告”实现。在某些时候，第三方也可以通过RTCP包实现对网络的监控
RTCP包中携带着RTP源的永久标识符信息存放为CNAME（canonical name）项。在会话中的RTP源有可能因为SSRC冲突或者因为程序重启而重新生成一个SSRC，但它的CNAME是不变的，这样就可以追踪会话的每个参与者
前2个功能均要求会议的参与者发送RTCP包。所以，发送速率应该得到控制以适应有大规模参与者的RTP会话。每个参与者必须可以独立地知道会话的参与者数量，来决定发包的速率
第四个，同时也是一个可选功能项，通过RTCP协议传递最少的会话控制信息，比如用户界面上显示的参与者身份。这个功能在参与者可随时加入或离开的会话时非常有用，因为可以传递控制信息到每个参与者。该功能用于IP多播环境

以下是RTCP包的5种类型：
SR: Sender report 会话中频繁发送包的参与者的报告
RR: Receiver report 非频繁发包的参与者发送的接受方统计数据
SDES: Source description items 发送源描述项，包括CNAME信息
BYE: 终止参与会议信息的包
APP: 用于特定进程的包

每个RTCP包都有一个包头，然后根据包的类型的不同，包头后跟着不同长度的结构化的数据项，但这些数据项都有一个32位的包的边界。
RTCP包通过下层协议传输时，相邻的包之间没有分隔符。比如用UDP传输时，并没有给出UDP包中RTCP包的数量，而仅有一个总长度
几个RTCP包在通过下层协议传输时，对包的排列次序和组合方式没有要求，但有以下限制：
接受方数据统计（包含于SR和RR内）必须在带宽允许下尽可能多地发送，以使统计更加精确。因此，每个RTCP包集合必须有一个SR或RR的包。
新的接收者必须尽快得到源的CNAME并联系媒体求得同步。每个RTCP包集合必须包含SDES CNAME。

综上所述，每个RTCP包都必须以混合包的形式传输，每个混合包中必须至少包含2个独立的包，包的形式按下列推荐：
Encryption prefix: 混合包如果需要加密，前面必须有个32位加密前缀。
SR or RR: 混合包的第一个包必须为其中之一。
Additional RRs: 如果接受方数据中的源的数目超过了31，就需在正常的RR或SR后添加发送超出部分的信息
SDES: 每个混合包中必须包含的包类型，除了CNAME项，可视带宽情况在SDES包中加入更多源的信息。
BYE or APP: BYE类型的RTCP包必须是SSRC/CSRC发送的最后一个包，APP包为其他类型的RTCP包。

综上所述，每个RTCP包都必须以混合包的形式传输，每个混合包中必须至少包含2个独立的包，包的形式按下列推荐：
Encryption prefix: 混合包如果需要加密，前面必须有个32位加密前缀。
SR or RR: 混合包的第一个包必须为其中之一。
Additional RRs: 如果接受方数据中的源的数目超过了31，就需在正常的RR或SR后添加发送超出部分的信息
SDES: 每个混合包中必须包含的包类型，除了CNAME项，可视带宽情况在SDES包中加入更多源的信息。
BYE or APP: BYE类型的RTCP包必须是SSRC/CSRC发送的最后一个包，APP包为其他类型的RTCP包。

RTP包的接受者发送REPORT的RTCP包来反馈服务质量。REPORT包分为2种，RR和SR。两者的唯一区别是，发送后者的站点不仅是包的接受者同时也是活跃的包发送者。所以SR比RR要多20字节，用来携带发送者信息

sdes ：
包头后的每一项都是对一个SSRC/CSRC的描述，其中包含一系列子项。每个子项都具有下列格式：

8位子项类型标识
8位该子项的描述文本长度，不包括子项头这2个字节
描述文本，以UTF-8方式编码，最大长度255字节
同SSRC一样，在一个RTP会话中，CNAME也是全局唯一的，用来绑定应用程序与该站点的连接，通常具有以下形式："[e-mail]" "doe@192.0.2.89"