WEBRTC RTP/RTCP协议族

101 篇文章 109 订阅 ¥29.90 ¥99.00
本文深入探讨RTP/RTCP协议,包括RFC3550的基本内容,RTP的档次扩展如RTP/AVP、SRTP、RTP/AVPF、RTP/SAVPF,以及RTCP报文类型扩展如SR、RR、SDES、BYE、APP等。通过分析,为理解WebRTC实时视频传输中的RTCP协议提供基础。
摘要由CSDN通过智能技术生成

RF3550定义实时传输协议RTP和它的控制协议RTCP。RTP协议是Internet上针对流媒体传输的基础协议,该协议详细说明在互联网上传输音视频的标准数据包格式。RTP本身只保证实时数据的传输,并不能提供可靠传输、流量控制和拥塞控制等服务质量保证,这需要RTCP协议提供这些服务。

RTCP协议负责流媒体的传输质量保证,提供流量控制和拥塞控制等服务。在RTP会话期间,各参与者周期性彼此发送RTCP报文。报文中包含各参与者数据发送和接收等统计信息,参与者可以据此动态控制流媒体传输质量。RTP和RTCP配合使用,通过有效反馈使使流媒体传输效率最佳化。

IETF的RFC3550定义RTP/RTCP协议的基本内容,包括报文格式、传输规则等。除此之外,IETF还定义一系列扩展协议,包括RTP档次扩展,RTCP报文类型扩展,等等。本文对这些协议进行初步归纳总结,在分析RFC3550的基础上,以档次为主线分析RTP系列协议,以报文类型为主线分析RTCP系列协议。

二 RFC3550协议

RFC3550 - RTP: A Transport Protocol for Real-Time Applications (RTP)
RFC3550协议定义RTP和RTCP协议的最基本内容,包括报文格式及头部扩展、发送和接收规则、RTP Mixer和Translator、协议安全等内容。详细内容都在协议中定义,这里只简述RTP和RTCP报文的基本格式。


图1 RTP报文头部格式

RTP报文由固定头部、(可选)扩展头部和负载三部分组成,如图1所示。头部中的X域标示固定头部后面是否跟随扩展头部,PT域定义负载类型。各部分的详细定义请参考RFC3550[1]。


图2 RTCP报文Sender Report头部格式

RFC3550根据RTCP报文类型定义SR、RR、SDES、BYE和APP五种报文格式。图2显示了SR(Sender Report)的报文格式,包括固定头部、发送端信息和报告块三部分组成:发送端信息携带NTP时间同步和数据发送统计等内容,报告块则包含发送端接收到数据的统计信息。关于RTCP报文格式的详细信息,请继续参考RFC3550 [1]。

二 RTP档次扩展

RFC3550关于RTP档次的定义如下[1]:
“档次定义了一系列负载类型和对应的负载格式,也定义了特定于具体应用的RTP扩展和修改。典型地,某个应用仅基于一个档次运行。”

IETF针对RFC3550在档次方面定义了一系列扩展协议,总结如下表1:


表1 RFC3550在档次方面的扩展

RFC3551(RTP/AVP)在RFC3550的基础上针对RTP档次进行补充形成RTP/APVP档次,被用在具有最小会话控制的音视频会议中,是其它扩展档次的基础。该档次在没有参数协商和成员控制的会话中非常有用。该档次也为音视频定义一系列编码和负载格式。对于具体的流媒体负载格式,IETF也定义一系列协议详细描述,如VP8视频负载格式[6]和H264视频负载格式[7],等等。

RFC3711(SRTP,也即RTP/SAVP)是RTP/AVP在安全方面进行扩展形成的档次,为RTP/RTCP提供数据加密、消息认证、重放保护等功能。SRTP具有高吞吐量和低数据膨胀等特点,是异构环境下对RTP/RTCP数据的有效保护。

RFC4585(RTP/AVPF)是RTP/AVP在及时反馈方面进行扩展形成的档次,使得接收端能够向发送端提供及时反馈,实现短时调整和基于反馈的修复机制。该协议定义早期RTCP报文以实现及时反馈,并定义一系列通用RTCP反馈报文和特定于应用的反馈报文,如NACK、PLI、SLI、RPSI等。

RTC5124(RTP/SAVPF)则是RTP/SAVP和RTP/AVPF的综合。SAVP和AVPF在使用时,需要参与者借助于SDP协议[8]就档次和参数信息达成一致。但是对一个RTP会话来说,这两种档次不能同时被协商。而实际应用中,我们有同时使用这两种档次的需要。因此,RTP/SAVPF档次应运而生,它能够使得RTP会话同时具有安全和及时反馈两方面的特性。

本节对RFC3550在档次方面扩展形成的一系列协议进行初步分析。可以看到,RFC3550只定义最基本的内容,在实际应用中会对其在安全性、及时反馈等方面进行扩展。

三 RTCP报文类型扩展

RFC 3550定义五种RTCP报文,类型在报文头部的PT域定义。表2对它们作简单描述。


表2 RFC3550定义的五种RTCP报文

SR报文用于发送端报告本端的数据发送统计信息和数据接收统计信息,RR报文用于报告本端的数据接收统计信息,SDES报文用于报告本端的描述性信息,BYE在本端离开会话时发送,而APP则是特定于应用的数据。

IETF根据实际需求对RTCP的报文类型进行扩展,定义了一系列协议。对这类RTCP报文总结如表3所示:


表3 RTCP其它报文及所在RFC

下面对这些RFC做进一步分析:
RFC5450 - Transmission Time Offsets in RTP Streams
该协议在定义一种更精细地描述传输时间的方法的基础上,定义一种改进的Jitter报告报文,负载类型为195。

RFC5104 - Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)
该协议对RFC4585 AVPF档次进一步补充,定义一系列传输层和特定于负载的RTCP报文格式。该系列报文对SR/RR报文的RC域重定义为FMT域,用以区分报文的子类型。综合RFC4585所定义的报文,如下表4所示:


表4 RTPFB和PSFB及其子类型

RFC3611 - RTP Control Protocol Extended Reports (RTCP XR)
该协议定义RTCP扩展报告块,负载类型为207。RTCP扩展报告块在SR/RR报告块的基础上传输更多的信息。RFC3661定义了7种子报告块,总结如表5:


表5 RFC3611扩展报告块

本节以报文类型为主线,归纳总结RTCP报文及其扩展报文,内容比较多也比较繁琐。这些报文为RTP提供更丰富的控制信息和统计数据。

四 总结

本文在分析RTP/RTCP基础协议RFC3550的基础上,以档次为主线分析RTP系列扩展协议,以报文类型为主线分析RTCP系列扩展协议。通过以上工作,得到一个较为清晰的框架和流程,为进一步学习RTP/RTCP协议打下良好基础。

参考文献

[1] RFC3550 - RTP: A Transport Protocol for Real-Time Applications 
[2] RFC3551 - RTP Profile for Audio and Video Conferences with Minimal Control 
[3] RFC3711 - The Secure Real-time Transport Protocol (SRTP) 
[4] RFC4585 - Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF) 
[5] RFC5124 - Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF) 
[6] RFC7741 - RTP Payload Format for VP8 Video 
[7] RFC6184 - RTP Payload Format for H.264 Video 
[8] RFC4566 - SDP: Session Description Protocol 
[9] RFC 5450 - Transmission Time Offsets in RTP Streams 
[10] RFC 5104 - Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF) 

[11] RFC3611 - RTP Control Protocol Extended Reports (RTCP XR)



Webrtc(7) 实时视频传输中的RTCP协议


我以前主要研究语音,语音中常用的RTCP包主要有SR/RR/SDES/BYE/APP/XR,主要由RFC 3611和RFC 3550定义。

而视频中常用的RTCP包比语音要多很多,语音的RTCP主要用于状态传递,统计数据。而视频中的RTCP更多赋予了控制功能,比如关键帧请求,码率控制等等。


本文不介绍语音中的RTCP,只介绍视频中的RTCP包。

这些报文遵守RFC4585RFC5104协议。


第一类:关键帧请求

主要包括SLI/PLI/FIR,作用是在关键帧丢失无法解码时,请求发送方重新生成并发送一个关键帧。

这本质是一种重传,但是跟传输层的重传的区别是,它重传是最新生成的帧。

PLI 是Picture Loss Indication,SLI 是Slice Loss Indication。

发送方接收到接收方反馈的PLI或SLI需要重新让编码器生成关键帧并发送给接收端。


FIR 是Full Intra Request,这里面Intra的含义可能很多人不知道。

Intra的含义是图像内编码,不需要其他图像信息即可解码;Inter指图像间编码,解码需要参考帧。

故Intra Frame其实就是指I帧,Inter Frame指P帧或B帧。


那么为什么在PLI和SLI之外还需要一个FIR呢?

原因是使用场景不同,FIR更多是在一个中心化的Video Conference中,新的参与者加入,就需要发送一个FIR,其他的参与者给他发送一个关键帧这样才能解码,

而PLI和SLI的含义更多是在发生丢包或解码错误时使用。


第二类:重传请求

主要包括RTX/NACK/RPSI

这个重传跟关键帧请求的区别是它可以要求任意帧进行重传


第三类:码率控制

主要包括REMB/TMMBR/TMMBN

TMMBR是Temporal Max Media Bitrate Request,表示临时最大码率请求。表明接收端当前带宽受限,告诉发送端控制码率。

REMB是ReceiverEstimated Max Bitrate,接收端估计的最大码率。

TMMBN是Temporal Max Media Bitrate Notification


另外,除了关键帧请求和重传,Webrtc还支持RED/FEC等冗余编码和前向纠错手段来保证视频质量,后续有空了再写。


http://blog.csdn.net/wangruihit/article/details/47041515


评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值