RTCP介绍及发送间隔控制

1、简述

RTP实时传输协议，广泛应用于流媒体传输应用场景，根据rfc3550介绍，RTP协议应用场景有如下几种：

Ø  简单多播音频会议（Simple Multicast Audio Conference）

Ø  音频和视频会议（Audioand Video Conference）

Ø  混频器和转换器（MixersandTranslators）

Ø  分层编码（LayeredEncodings）

        在实时音视频应用场合，考虑低延迟问题一般都使用RTP over UDP进行流媒体数据的传输，因此对于丢包、延迟、流畅性的考虑，发送端必须了解发送出去的流媒体数据到达对端的统计信息，RTP 控制协议 RTCP，就是用于监控服务质量和传达关于在一个正在进行的会议中的参与者的信息，包括对抗卡顿、网络拥塞控制扩展功能的实现，均利用RTCP报文实现，有名的是Google的GCC（拥塞控制算法(Google Congestion Control,简称GCC[1])）），RTCP的Nack、fir、pli报文都是实现抗丢包的策略，详细可查看rfc4585；

2、RFC3550中关于RTCP的介绍

2.1、基本场景介绍

       RTP 控制协议(RTCP)向会议中所有成员周期性发送控制包。它使用与数据包相同的传输机制。底层协议必须提供数据包和控制包的复用，例如用不同的 UDP 端口或相同的UDP端口（采用复用模式下）。RTCP 提供以下四个功能：

Ø  基本功能是提供数据传输质量的反馈；

     这是 RTP 作为一种传输协议的主要作用，它与其他协议的流量和拥塞控制相关。反馈可能对自适应编码有直接作用，并且 IP 组播的实验表明它对于从接收端得到反馈信息以诊断传输故障也有决定性作用。向所有成员发送接收反馈可以使"观察员"评估这些问题是局部的还是全局的。利用类似多点广播的传输机制，可以使某些实体，诸如没有加入会议的网络业务观察员，接收到反馈信息并作为第三方监视员来诊断网络故障。反馈功能通过 RTCP 发送者和接收者报告实现。

Ø  RTCP 为每个 RTP 源传输一个固定的识别符，称为规范名（CNAME）；

     由于当发生冲突或程序重启时 SSRC可能改变，接收者要用 CNAME 来跟踪每个成员。接收者还要用 CNAME 来关联一系列相关 RTP 会话中来自同一个成员的多个数据流，例如同步语音和图像。

Ø  1和2功能要求参与方都发送RTCP报文，为保证会议参与方增长，必须严格控制发送包速率，避免过多占用本端带宽，导致视频质量差；

    通过让每个成员向所有成员发送控制包，各个成员都可以独立地观察会议中所有成员的数目。此数目可以用来估计发包速率。

Ø  传输最少的会议控制信息；

    例如在用户接口中显示参与的成员。这最可能在"松散控制"的会议中起作用，在"松散控制"会议里，成员可以不经过资格控制和参数协商而加入或退出会议。

2.2、包格类型介绍

类型	类型简称		描述	RFC文档
192	FIR		关键帧重传请求（IDR帧，无需参考帧可解码）	RFC2032
193	NACK		否定确认，NACK重传（丢包）	RFC2032
194	SMPTETC		SMPTE time-code 映射	RFC5484
195	IJ		extended inter-arrival jitter report.	RFC5450
200	SR		发送者报告，描述作为活跃发送者成员的发送和接收统计数字	RFC3550
201	RR		接收者报告，描述非活跃发送者成员的接收统计数字；	RFC3550
202	SDES		源描述项，其中包括规范名 CNAME。	RFC3550
203	BYE		表明参与者将结束会话。	RFC3550
204	APP		应用描述功能	RFC3550
205	RTPFB		通用RTP反馈	RFC4585
<