RTP&RTCP详解

RTP提供了一个端到端的网络传输功能,适合于传输实时数据的应用(组播或单播网络服务),例如音频,视频。RTP并不要求资源预留,也不保证实时服务的服务质量。数据传输被控制协议RTCP增强,该协议适合在大的组播网络中监控数据的传输,RTCP还提供了少量的控制和标识功能。RTP和RTCP是独立于下面的网络层和传输层的。协议支持RTP级的转换和合成。
RTP负载:一个RTP包中传输的数据,例如音频抽样或压缩的视频数据。
RTP包:一个包含固定RTP头,一个可能为空的贡献源列表,以及负载数据的数据包。
RTCP包:一个包含固定头,依赖于RTCP包类型的结构化元素的控制包。多个RTCP包可以作为一个合成包在下层协议的一个简单包中一起发送,这是由每一个RTCP包固定头中的长度字段决定的。
端口:一个给定的主机中,传输协议用于识别多个目的地的抽象。
传输地址:网络地址和端口的混合用来标识一个传输级的端点,例如一个IP地址和UDP端口。包从源传输地址到目的传输地址传输。
RTP会话:使用RTP通信的参与者的集合。对每一个参与者,会话都给它定义了一对具体的目的传输地址(一个网络地址加一对端口,用于RTP和RTCP).目的传输地址对对所有的参与者可能是共有的,例如在IP组播中,或者是彼此不同的。在一个多媒体会话中,分离的会话以及自己的RTCP包用来携带一个媒体。多个RTP会话可以被不同的端口对或/与不同的组播地址识别。
同步源(SSRC):RTP包一个流的源,通过携带在RTP头中32bit的数字SSRC标识符标识,目的是独立于网络地址。 来自同步源的所有包形成相同的时间和顺序号间隔部分,这样接收者就可以在回放中把同步源的包合成一组。一个同步源可以改变它的数据格式,例如音频编码。同步源标识符是随机选择的一个值,在整个RTP会话,它必须是唯 一的。在多媒体会话中,一个参与者不需要对所有的会话使用相同的SSRC标识符。SSRC标识符的绑定可通过RTCP提供。如果一个参与者在一个RTP会话中生成多个流,例如来自不同的摄像机,每一个必须用不同的SSRC来标记。
贡献源(CSRC):RTP包流的源对RTP混合器产生的合成流做了贡献。混合器插入一个列表到它生成的RTP包的RTP包头中,该列表列出了对生成该包所有做过贡献的源的SSRC标识符,成为CSRC列表。例如在一个音频会议中,一个混合器把所有发言者的声音联合产生一个包,允许接收者指出当前的发言者,即使混合器产生的所有音频包包含相同的SSRC标识符。
终端系统:产生RTP包发送内容或消费接收RTP包内容的应用。在一个具体的RTP会话中一个终端系统可作为一个或多个同步源。
混合器:从一个或多个源接收RTP包的中间系统,可以改变数据格式,以某种方式混合包,然后把这个新的RTP包发送出去。因为多个输入源的时间通常是不同步的,混合器将调整这些流的时间并为合成流生成自己的时间。这样从混合器产生的所有数据报将被混合器产生的同步源识别。
翻译器:用原来RTP包的同步源标识符发送RTP包的中间系统。例如,不用混合的转编码,多播到单播的复制,应用级的防火墙过滤器。
监视器:在RTP会话中接收参与者发送的RTCP包的应用,主要是接收报告,估计当前的服务质量,缺点诊断和长期统计。监视器的功能可以内建在参与会话的应用中,也可以从应用中分离出来,作为一个独立的应用不发送或接收RTP数据包,这时的监视器称为第三方监视器。
挂钟时间(绝对时间):用网络时间标准(NTP)格式的时间戳表达,该时间是相对于1900年1月1日的。全分辨率的NTP时戳是一个64比特的无符号定点数,整型部分用前32比特表示,小数部分用后32比特表示。在一些域中使用更为压缩的表达,即只使用中间的32比特。
sequence number: 16 bits
  每发送一个RTP数据包,顺序号加1,它可以被接收者使用来检测包丢失并存储包顺序号。顺序号的初始值是随机的不可预测的,目的是防止明文攻击。
 timestamp: 32 bits
  时戳反映了RTP数据包中第一个字节的采样时刻。采样时刻必须源于一个随时间线性增长的时钟,允许同步和抖动 计算。时钟的精度必须满足要求的同步准确性,并能很好衡量包到达抖动(每一个视频帧一个滴答值是不够的)。时戳的初始值是随机的,和顺序号一样。几个连续的RTP包可能有相等的时戳如果它们逻辑上同时产生,例如,属 于同一个视频帧。连续的RTP包包含的时戳可能不是单调的,如果数据不按它的采样顺序传输。例如MPEG的交织视频帧。(包传输的顺序号仍然是线性的)。
SSRC: 32 bits
  SSRC字段标识了同步源。这个标识符是随机选择的,规定同一RTP会话中不能有相同的SSRC标识符。虽然多个源选择同一个标识符的概率很低,但是所有的RTP实现必须准备检测并处理该冲突。如果一个源变换了它的源传输地址,它也必须选择一个新的SSRC标识符避免它被解释为一个循环源。
 CSRC list: 0 to 15 items, 32 bits each
  CSRC列表说明了该包包含的负载贡献源。标识符的数目是由CC字段给定的。如果多于15个贡献源,只能有15个被标识。CSRC标识符是被混合器插入的,使用贡献源的SSRC标识符。
 
RTCP基于会话中所有参与者周期性地传输控制包,采用和数据包相同的分发机制。低层的协议必须提供数据包和控制包的复用,例如当使用UDP时利用分开的端口号。RTCP实现四个功能:
提供数据分发的质量反馈;
RTCP为一个RTP源携带永久的称为规范名(CNAME)的传输级标识符;
每一个参与者对其它人发送自己的控制包,每一个  用户独立地观测参与者的数目;  
传输最小会话控制信息,该功能可选,例如在用户界面上呈现参与者的标识符。

SR:发送报告,来自发送者的传输或接收统计。
RR:接收报告,来自接收者的接收统计。
SDES:源描述条款,包含CNAME。
BYE:说明参与者的退出。
AAP:应用功能。
  每一个RTCP包都是由固定头开始的,后面跟着长度可变的结构化元素,这些长度是由包的类型确定的,并且需要32比特对齐,RTCP固定头中包含长度字段。多个RTCP包可以不需要交织分隔符来形成一个组合的RTCP包,通过低层协议作为一个简单的包发送出去。在低层协议中并没有独立RTCP包的数目,它只提供了该包的全部长度。
组合包中每一个独立的RTCP包没有必要按照组合顺序逐次处理。然而,为了实现协议的功能,必须要有下面的限制:
接收统计(SR或RR中的),当带宽限制能允许统计信息完全传输时,它应该被经常传输,因此周期性传输的RTCP包必须包含报告包。
新的接收者需要接收源的CNAME来识别源,因此每一个组合RTCP包需要包含SDES CNMAE。

可能出现在组合包中开始部分的包类型应该被限制,这样可增加第一个字中的不变比特数,有效地预防错误描述的RTP数据包或其它无关的数据包被认为是RTP包。 一个组合包必须以SR或RR包开头。
RTP被设计允许一个应用可以自动变化会话大小,即参与者可以从几个到几千个。控制传输没有自限制性,如果来 自每一个参与者的接收报告以固定码率发送,控制传输将会随着参与者的增加线性增长。在每一个会话中,假设数据传输是由一个称为“会话带宽”的带宽值决定的,该带宽被多个参与者分割,可以被网络保留或限制,或者被合理地共享。控制传输应该占用小部分的会话带宽,这样可以使传输协议的传输数据功能不受损害。建议分配给RTCP的带宽固定为会话带宽的5%,发送者至少占用控制传输带宽的1/4。

建议分配给每一个参与者的RTCP带宽中,用来传输额外信息的带宽不超过20%。因此,并不需要把所有的SDES条款包含在每一个应用中。例如,一个应用被设计只发送CNAME,NAME,EMAIL。NAME的优先级可能比EMAIL高,因为NAME将会在应用的用户界面上连续显示,而EMAIL仅在请求的时候显示。在每一个RTCP间隔中,一个RR包和一个包含CNAME条款的SDES包被传输。在一个小间隔的小会话中,间隔平均为5秒。每三个间隔后,SDES包将包含额外的一个条款。八次中的七次将会是NAME条款,只有一次是EMAIL条款。
RTCP头:
reception report count (RC): 5 bits
    该包中包含的接收报告块数。
length: 16 bits
    RTCP包包含头字段和填充字段的字长度(32比特)。
packet type (PT): 8 bits
    如果是200,说明该包是RTCP SR包。
SSRC: 32 bits
   该SR包发起者的同步源标识符。
RTP timestamp: 32 bits
    与NTP时戳的时间值是相关的,但是和RTP数据包的时戳一样,同样的单元具有相同的时间偏移。该相关性可用于源的帧间帧内媒体的同步,该源的NTP时戳是同步的,它也可以让独立媒体的接收者估计出RTP时钟频率。

sender's octet count: 32 bits
  发送字节数,发送者发出的总的负载字节数(不包括头和填充信息),从开始传输到生成该SR包这段时间内。如果源改变它的SSRC,该数被重置。该字段可用来估计平均负载数据率。
SSRC_n (source identifier): 32 bits
  源的SSRC标识符说明该报告块说明哪一个源的信息。
fraction lost: 8 bits
  RTP数据包从上次发送SR或RR包开始丢失的源SSRC_n的片断。该值是一个定点数,它的定义是丢失的包数除以期待的包数。
cumulative number of packets lost: 24 bits
  对源SSRC_n从开始接收时累计丢失的RTP数据包数。
 
  extended highest sequence number received: 32 bits
  低16位包含了从源SSRC_n中接收到的最大的RTP数据包顺序号,高16位反映了低16位循环的次数。
interarrival jitter: 32 bits
  RTP数据包内部到来时间统计方差的估计。
last SR timestamp (LSR): 32 bits
  从源SSRC_n收到的最近的RTCP发送报告包的NTP时戳的中间32位。如果没有收到SR,该值为零。
delay since last SR (DLSR): 32 bits
  从接收到源SSRC_n最后一个SR包到发送该接收数据块之间的延迟,以1/65536为单位。

通常,我们假设所有用户都接收相同格式的媒体数据。但是,这一点并不总是成立的。考虑一种情形,一个会议的许多参与者都能对会议进行高速网络访问,但是一个低速链接的用户加入该会议。并不强制让每一个与会者使用低带宽,低质量的音频编码,一个称为混合器的RTP级中继可以放置在低带宽领域。该混合器同步到来的音频包并重组这些包到一个流中,使用一种适合低带宽的音频编码格式转编码该音频流并发送给低速链路用户。RTP头中包含混合器的方式来标识贡献源,这样接收者就可以知道该音频的发出成员是谁。
一些音频会议用户不能直接通过IP组播与高速带宽链路连接。例如,它们可能位于应用级的防火墙后面,该防火墙不让IP包通过。在这种情况下,混合器是不需要的,需要使用另一种RTP级的中继翻译器。两个翻译器被放置在防火墙的两侧,外面的可以把接收到的所有组播包通过一个安全的连接进入防火墙内部的翻译器。防火墙内部的翻译器再把它们按照组播包重新传给一个组播地址。

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值