RTP/RTCP 应用背景
随着多媒体网络应用的发展，针对网络多媒体的通用、实时交互式应用的传输协议——实时传输协议（Real-Transport Protocol，RTP）与实时传输控制协议（Real-Transport Control Protocol，RTCP）应运而生。
一、RTP协议特点
RTP协议运行在TCP/IP协议之上，
RTP通常运行在用户空间，它位于UDP或者TCP协议之上。从工作流程来看，由于RTP运行在用户空间，并且与应用层协议链接，因此它看上去更像应用层协议。另一方面，它又是一个与具体应用无关的通用协议，它将应用层的多媒体数据封装后，再利用UDP、IP及低层协议实现多媒体数据的传输。
当应用程序开始一个RTP会话时，将使用两个端口：一个用于RTP，另一个用于RTCP。同时需要注意的是，与其他应用层协议都是分配一个熟知端口号不同，RTP会话需要在临时端口号（1025～65 535之间）中选择一个未使用的偶数UDP端口号。例如，RTP选择的端口号为1210，那么属于同一会话的RTCP就选择加1的奇数端口号，即1211。因此，从TCP/IP协议体系的角度来看，它应该位于应用层之下、UDP之上，是一种专用于有实时性要求的网络应用的传输层协议。
RTP协议提供端–端的传输服务
多媒体数据由音频、视频、文本与其他可能的数据流组成。这些数据流被送到RTP库。RTP库软件按音频、视频、文本数据流之间的关系，将它们压缩编码后复用到RTP报文（RFC 3550使用的是“RTP Packet”），再加上套接字（Socket），通过UDP软件封装成一个UDP报文。目的主机将接收到的RTP报文封装的多媒体数据传送到应用层。应用层的播放器负责播放多媒体数据。
UDP报文封装在普通的IP分组中传输，传输路径中的所有路由器不会对该分组提供任何特殊的服务。RTP不强调需要资源预留协议（RSVP）的支持，RTP为应用层的实时应用提供端–端的传输服务，不提供任何QoS保证。
二、RTP协议的结构
RTP报头由12字节的固定长度报头与可选的分信源标识符组成。长度为12字节的固定报头包括以下字段。
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 |P|X| CC |M| PT | SN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time stamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CCRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ 版本(V)
版本字段长度为2比特，目前使用的是版本2。
+ 填充(P)
填充（P）字段的长度为1比特。在某些特殊情况下，需要对应用层数据进行加密，这就要求每个数据块有确定的长度，必须是4字节的整数倍。在有填充字节的情况下，填充位P=1。在数据部分的最后一个字节值用来表示填充的字节数。
+ 扩展(X)
扩展（X）字段的长度为1比特。X=1表示RTP报头之后有扩展报头。实际上，RTP很少使用扩展报头。
+ 参与源数量(CC)
参与源（CSRC Counter，CC）字段的长度为4比特。CC设置为最大值时，表示一次会话最多有15个参与源。
+ 标记(M)
标记（M）字段的长度为1比特。M=1表示该RTP报文有特殊意义。例如，应用程序可以用该位表示视频流的每帧开始，也可以表示视频流传输结束。
+ 有效载荷类型(PT)
有效载荷类型Payload type字段的长度为8比特。
+ 序号(SN)
序号字段的长度为16比特，用来给RTP报文编号。在一次RTP会话中，第一个RTP报文的编号是随机产生的，后续的每个报文序号加1。接收端可以根据序号来判断RTP报文是否丢失或乱序。
+ 时间戳(Time stamp)
时间戳字段的长度为32比特，用于指出RTP报文之间的时间关系。在一次会话开始时，第一个RTP报文的时间戳初始值是随机产生的。RTP没有规定时间戳的粒度（Granularity），它取决于有效载荷类型。
+ 同步源标识符(SSRC)
同步源标识符（Synchronous SouRCe identifier，SSRC）字段的长度为32比特，用来表示RTP流的来源。如果一次会话中只有一个源端，那么SSRC值就表示这个源端。
+ 参与源标识符(CCRC)
参与源标识符（Contributing SouRCe identifier，CCRC）字段的长度为32比特，用来标识参与源的源端。从长度为4比特的CC字段可以知道，一次会话的参与源数量最多为15个。
三、RTCP协议与RTP协议的关系
源端利用RTCP报文同步一次会话中的不同媒体流。例如，在一次视频会议应用中，每一个源端都产生两个独立的媒体流，一个用于传输视频，一个用于传输音频。这时，需要将这些RTP报文头中的时间戳与视频、音频采样时钟建立关联。由于源端发出的RTCP报文包含与它关联的RTP报文流的时间戳与真实时间，因此接收端可以通过RTCP报文提供的关联来同步视频与音频的播放。
实际上，RFC 3550文档定义了两部分的内容。一部分是用于传输多媒体数据流的协议（RTP），另一部分是实时传输控制协议（RTCP）。
RTCP与RTP协议是相互配合的关系。RTP与RTCP可以同时在一个多媒体应用中使用，都封装在UDP报文中传输。
RTP报文的有效载荷中封装音频、视频数据流，而RTCP报文不封装任何音频、视频数据流。
四、RTCP报文
RTCP报头中有一个长度为8比特的报文类型字段，不同报文类型字段值表示不同类型的RTCP报文。例如，报文类型字段值为200，表示发送端报告的RTCP报文。
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 |P| RC | PT=SR=200 | length | header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP Time stamp(most significant word) | sender info
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP Time stamp(least significant word) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sender's packet count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sender's octet count |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_1(SSRC of first source) | report block 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fraction lost | cumulative number of packets lost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extended hidghest sequence number received |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| interarriveal jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC_1(SSRC of second source) | report block 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................ |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| profile-secific extensions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ 版本（V）
同RTP包头域
+ 填充（P）
同RTP包头域
+ 接收报告计数器（RC）
该SR包中的接收报告块的数目，可以为0
+ 包类型（PT）
SR包是200
+ 长度域（Length）
其中存放的是该SR包以32比特为单位的总长度减一
+ 同步源（SSRC）
SR包发送者的同步源标识符。与对应RTP包中的SSRC一样
+ NTP Timestamp（Network time + protocol）
SR包发送时的绝对时间值,NTP的作用是同步不同的RTP媒体流
+ RTP Timestamp
与NTP时间戳对应，与RTP数据包中的RTP时间戳具有相同的单位和随机初始值
+ Sender’s packet count
从开始发送包到产生这个SR包这段时间里，发送者发送的RTP数据包的总数. SSRC改变时，这个域清零
+ Sender`s octet count
从开始发送包到产生这个SR包这段时间里，发送者发送的净荷数据的总字节数（不包括头部和填充）,发送者改变其SSRC时，这个域要清零
+ 同步源n的SSRC标识符
该报告块中包含的是从该源接收到的包的统计信息
+ 丢失率（Fraction Lost）
表明从上一个SR或RR包发出以来从同步源n(SSRC_n)来的RTP数据包的丢失率
+ 累计的包丢失数目
从开始接收到SSRC_n的包到发送SR,从SSRC_n传过来的RTP数据包的丢失总数
+ 收到的扩展最大序列号
从SSRC_n收到的RTP数据包中最大的序列号，
+ 接收抖动（Interarrival jitter）
RTP数据包接受时间的统计方差估计
+ 上次SR时间戳（Last SR,LSR）
取最近从SSRC_n收到的SR包中的NTP时间戳的中间32比特。如果目前还没收到SR包，则该域清零。
+ 上次SR以来的延时（Delay since last SR,DLSR）
上次从SSRC_n收到SR包到发送本报告的延时。
五、RTCP报文类型
-
发送端报告（SR）
发送端与接收端的一次会话包含很多RTP流。发送端每次发送一个RTP流时，就会发送一个SR报文。绝对时间对于多媒体传输是非常重要的。在传输一个视频信号时，实际上需要同时传输音频流与图像流。这样，在播放一个视频节目时，通过RTP报文的时间戳与绝对时间可实现音频流与图像流的同步。 -
接收端报告（RR）
接收端每次接收一个RTP流时，就会发送一个RR报文。接收端可以使用RTCP报文，周期性地向发送端反馈与QoS相关数据。发送端可以根据RTCP报文反馈的信息，了解网络当前的延时与延时抖动、丢包率，以便决定数据传输速率。如果网络通信状态良好，发送端可以动态改变编码算法，以提高多媒体信息的播放质量。 -
发送端描述报告（SDES）
发送端周期性地通过多播方式发送SDES报文，给出了会话参与者的规范名（Canonical Name）。规范名是会话参与者电子邮件地址的字符串。 -
结束（BYE）
结束（BYE）报文用来关闭一个数据流。在视频会议应用中，一个发送端通过结束报文宣布退出这次会议。 -
特定应用（APP）
特定应用（APP）报文用于应用程序定义一种新的RTP报文类型。在通常情况下，RTCP报文占用的网络带宽不应超过5%。如果一个发送端正在以2Mbps速率发送视频流，那么该节点的RTCP报文占用带宽必须低于100kbps。在具体的实现中，通常将这个带宽的75%（75kbps）分配给接收端，剩余25%（25kbps）留给接收端。如果在多播情况下有n个接收端，那么每个接收端用于发送RTCP报文的带宽应控制在75/n（kbps）之内。