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包。

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

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

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

RTP/RTCP详解相关推荐

IP实时传输协议RTP/RTCP详解
1.简介目前,在IP网络中实现实时语音.视频通信和应用已经成为网络应用的一个主流技术和发展方向,本文详细介绍IP协议族中用于实时语音.视频数据传输的标准协议RTP( Real-time Transp ...
RTP和RTCP详解
1 RTP和RTCP详解文章目录 1 RTP和RTCP详解 1.1 概述 1.2 RTP协议详解 1.3 RTCP协议详解 1.1 概述在流媒体相关的领域,我们进场会看到RTP/RTCP,其用于流 ...
WebRTC中RTP协议详解
WebRTC中RTP协议详解 WebRTC中RTP协议详解 WebRTC中RTP协议详解前言一.RTP/RTCP在协议栈中的位置 1. RTP传输流程图二.RTP Header 的结构图 1.R ...
H.264 基础及 RTP 封包详解
一. h264基础概念 1.NAL.Slice与frame意思及相互关系 1 frame的数据可以分为多个slice. 每个slice中的数据,在帧内预测只用到自己slice的数据, 与其他slice ...
rtp协议详解/rtcp协议详解
1.简介目前,在IP网络中实现实时语音.视频通信和应用已经成为网络应用的一个主流技术和发展方向,本文详细介绍IP协议族中用于实时语音.视频数据传输的标准协议RTP( Real-time Transp ...
嵌入式 RTP协议详解以及其他相关协议
RTP协议 1 RTP报文格式 2 基于RTP的带宽控制方法 1.接收端的控制策略 2.发送端的控制策略 RTP(Real-timeTransportProtocol)是由IETF开发的实时传输 ...
音视频传输：RTP协议详解和H.264打包方案
问题背景: 前面讲解了PS.TS.FLV这三种媒体封装格式,现在新开一个系列讲解下传输协议,这里面会包含RTP.RTSP.HLS.RTMP等.当然最复杂的封装格式MP4在准备中,后面会把封装格式这个系 ...
RTP协议详解（荷载H264）
目录 RTP的会话过程 RTP实际应用中的细节用户网络带宽不同用户是否被防火墙隔离 RTP结构解析解析举例 RTP荷载H264码流单个NAL单元包分片单元(FU-A) 解析举例 RTP的会话 ...
WebRTC[54] - WebRTC之RTCP详解
<WebRTC工作原理精讲>系列-总览(了解专栏更多内容,请点我!) 前言在WebRTC中,流媒体协议使用的RTP/RTCP协议,其中,RTP负责流媒体数据传输,RTCP负责传输的质量控 ...

RTP/RTCP详解

RTP/RTCP详解相关推荐

最新文章

热门文章