网络流媒体-RTP与RTCP

1、RTP与RTCP概述

RTP与RTCP协议本来不属于我们常见的流媒体协议,类似rtmp,rtsp,hls,webrtc等,但是很多的流媒体协议又是在这两个协议之上的额,比如rtsp和webtrc这两个下层就是rtp与rtcp协议的。这两个协议在四层模型中我们仍把他们归属到应用层协议中,因为这两个协议的实现代码均是由我们用户自己完成,一个包含RTP完整的流媒体协议封装应是类似user data+rtsp+rtp/rtcp+udp+ip来完成的。

RTP与RTCP协议区别?

在流媒体协议中这两个协议一定是成对出现的,但是他们分工不一样,RTP包负责传输用户数据,RTCP包负责控制数据(确保数据质量等,里面包含了RTP数据的传输包数量,丢包数,码率等),因此RTCP是必须周期性穿插在码流中。且这两个协议占用端口不一样,RTP占用的是UDP偶数端口,而RTCP则是RTP端口+1的奇数端口。

2、RTP封装

我们知道任何一种协议的封包格式中,肯定包含有头部信息的,rtp也不例外(rtp+fixed_header+extend_header+payload),具体的rtp header见图。重点关注标红的一个字段,关系到是否包含有扩展头,rtp包的序号以控制rtp包接收顺序,丢包重传等(因为rtp是基于UDP不可靠协议的,并不能保证包顺序,是否丢包等)。其实还有扩展头的,只不过我们只关注基本原理,就不详细去讲扩展头等。对于rtp的理解我们只需知道,rtp专用于用户数据的传输,同时在头部为rtcp提供rtp的负载类型,rtp包顺序,标记位等以便于RTCP控制质量。

版本号(V):2比特,用来标志使用的RTP版本。

填充位(P):1比特,如果该位置位,则该RTP包的尾部就包含附加的填充字节。

扩展位(X): 1比特,如果该位置位的话,RTP固定头部后面就跟有一个扩展头部。

CSRC计数器(CC):4比特,含有固定头部后面跟着的CSRC的数目。

标记位(M): 1比特,该位的解释由配置文档(Profile)来承担.
载荷类型(PayloadType): 7比特,标识了RTP载荷的类型。

序列号(SN):16比特,每发送一个 RTP 数据包,序列号增加1。接收端可以据此检测丢包和重建包序列。

时间戳(Timestamp): 2比特,记录了该包中数据的第一个字节的采样时刻。在一次会话开始时,时间戳初始化成一个初始值。即使在没有信号发送时,时间戳的数值也要随时间而不断地增加(时间在流逝嘛)。时钟频率依赖于负载数据格式,并在描述文件(profile)中进行描述。

同步源标识符(SSRC):32比特,同步源就是指RTP包流的来源。在同一个RTP会话中不能有两个相同的SSRC值。该标识符是随机选取的 RFC1889推荐了MD5随机算法。

贡献源列表(CSRC List):0~15项,每项32比特,用来标志对一个RTP混合器产生的新包有贡献的所有RTP包的源。由混合器将这些有贡献的SSRC标识符插入表中。SSRC标识符都被列出来,以便接收端能正确指出交谈双方的身份。

例子:下面是wireshark抓取的RTP包,

3、RTCP封装

 rtcp的主要功能是服务质量的监视与反馈、媒体间的同步,以及多播组中成员的标识。在RTP会话期 间,各参与者周期性地传送RTCP包。RTCP包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料,因此,各参与者可以利用这些信息动态地改变传输速率,甚至改变有效载荷类型。RTP和RTCP配合使用,它们能以有效的反馈和最小的开销使传输效率最佳化,因而特别适合传送网上的实时数据。RTCP分为五种类型:

 RTCP也是用UDP来传送的,但RTCP封装的仅仅是一些控制信息,因而分组很短,所以可以将多个RTCP分组封装在一个UDP包中。RTCP有如下五种分组类型。
类型     缩写表示     用途
200     SR(Sender Report)     发送端报告
201     RR(Receiver Report)     接收端报告
202     SDES(Source Description Items)     源点描述
203     BYE     结束传输
204     APP     特定应用

上述五种分组的封装大同小异,下面只讲述SR类型,而其它类型请参考RFC3550。

        发送端报告分组SR(Sender Report)用来使发送端以多播方式向所有接收端报告发送情况。SR分组的主要内容有:相应的RTP流的SSRC,RTP流中最新产生的RTP分组的时间戳和NTP,RTP流包含的分组数,RTP流包含的字节数。SR包的封装如图3所示。

版本(V):同RTP包头域。

填充(P):同RTP包头域。

接收报告计数器(RC):5比特,该SR包中的接收报告块的数目,可以为零。
包类型(PT):8比特,SR包是200。

长度域(Length):16比特,其中存放的是该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包到发送本报告的延时。
参考链接:https://blog.csdn.net/machh/article/details/51868569

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值