RTP/RTCP协议详解 (RTP\/RTCP协议)
RTP payload:RTP数据包的有效载荷。
RTP packet:RTP数据包,包括RTP数据包头部与payload。
Transport address:IP地址+端口号。
RTP session:区分RTP session的标志是是否有SSRC标识符的独立空间。
SSRC:RTP Stream的数据源。SSRC的标识符必须在RTP Session中唯一。
其中,前12个字节为fixed header。
2 bits。RTP的版本号,当前版本为2.
1 bit。如果设置为1,payload后面可能会有1个或者多个padding字节,它们不是payload的一部分。方便一些针对固定长度算法的封装。
1 bit。如果设置为1,则在RTP固定报头后跟有一个扩展报头。
4 bits。记录了CSRC包含的字节数。
1 bit。不同的有效载荷有不同的含义,对于视频,标记一帧的结束;对于音频,标记会话的开始。
有效载荷类型,占7位,用于说明RTP报文中有效载荷的类型,如GSM音频、JPEM图像等,在流媒体中大部分是用来区分音频流和视频流的,音频流的PT值与视频的PT值是不同的,这样便于客户端进行解析。
占16位,用于标识发送者所发送的RTP报文的序列号,每发送一个报文,序列号增1。这个字段当下层的承载协议用UDP的时候,网络状况不好的时候可以用来检查丢包。同时出现网络抖动的情况可以用来对数据进行重新排序。
32 bits。用于记录RTP数据包第一个字节的采样时间。接收者使用时戳来计算延迟和延迟抖动,并进行同步控制。
在一次会话开始时,时间戳初始化成一个初始值。即使在没有信号发送时,时间戳的数值也要随时间而不断地增加(时间在流逝嘛)。时钟频率依赖于负载数据格式,并在描述文件(profile)中进行描述。 同一个帧的不同分片的时间戳是相同的。这样就省去了起始标志和结束标志。一定要记住,不同帧的时间戳肯定是不一样的 。
同步信源(SSRC)标识符,占32位,用于标识同步信源。 标识RTP会话中的参与者 ,同步源就是指RTP包 流的来源。 该标识符是随机选择的,RFC1889推荐了MD5随机算法。它是全局唯一的,不同的SSRC表示不同的共享源。参加同一视频会议的两个同步信源不能有相同的SSRC。
特约信源(CSRC)标识符,每个CSRC标识符占32位,可以有0~15个。每个CSRC标识了包含在该RTP报文有效载荷中的所有特约信源。
用来标志对一个RTP混合器产生的新包有贡献的所有RTP包的源。由混合器将这些有贡献的SSRC标识符插入表中。SSRC标识符都被列出来,以便接收端能正确指出交谈双方的身份。一般用在混音或混屏上。例如,在1路音流中混了好几个人的声音,那么这每一个人的声音就是一个CSRC。
有5种RTCP包类型:
超越RFC3550 - RTP/RTCP协议族分析
RTCP是实时传输控制协议,RTCP 有两个最重要的报文:RR(Reciever Report)和 SR(Sender Report),另外还有其他类型的报文,下面逐一介绍:
1.SR(Sender Report,发送者报文)
PT=200,报文格式如下:
2.RR(Reciever Report,接收者报文)
PT=201,报文格式如下:
3.SDES(source description,源描述项)
PT=202,报文格式如下:
4.BYE(goodbye,参与者会话结束)
PT=203,报文格式如下:
5.APP(Application-Defined,应用自定义)
PT=204,报文格式如下:
6.RTPFB(transport layer feedback messages,传输层反馈)
PT=205,通用的报文格式如下:
附一张RTCP 协议头各个字段的含义:
RTP系列:RTP协议详解和分析
RF3550定义实时传输协议RTP和它的控制协议RTCP。RTP协议是Internet上针对流媒体传输的基础协议,该协议详细说明在互联网上传输音视频的标准数据包格式。RTP本身只保证实时数据的传输,并不能提供可靠传输、流量控制和拥塞控制等服务质量保证,这需要RTCP协议提供这些服务。</br>
RTCP协议负责流媒体的传输质量保证,提供流量控制和拥塞控制等服务。在RTP会话期间,各参与者周期性彼此发送RTCP报文。报文中包含各参与者数据发送和接收等统计信息,参与者可以据此动态控制流媒体传输质量。RTP和RTCP配合使用,通过有效反馈使使流媒体传输效率最佳化。</br>
IETF的RFC3550定义RTP/RTCP协议的基本内容,包括报文格式、传输规则等。除此之外,IETF还定义一系列扩展协议,包括RTP档次扩展,RTCP报文类型扩展,等等。本文对这些协议进行初步归纳总结,在分析RFC3550的基础上,以档次为主线分析RTP系列协议,以报文类型为主线分析RTCP系列协议。</br>
RFC3550 - RTP: A Transport Protocol for Real-Time Applications (RTP)</br>
RFC3550协议定义RTP和RTCP协议的最基本内容,包括报文格式及头部扩展、发送和接收规则、RTP Mixer和Translator、协议安全等内容。详细内容都在协议中定义,这里只简述RTP和RTCP报文的基本格式。</br>
RTP报文由固定头部、(可选)扩展头部和负载三部分组成,如图1所示。头部中的X域标示固定头部后面是否跟随扩展头部,PT域定义负载类型。各部分的详细定义请参考RFC3550[1]。</br>
RFC3550根据RTCP报文类型定义SR、RR、SDES、BYE和APP五种报文格式。图2显示了SR(Sender Report)的报文格式,包括固定头部、发送端信息和报告块三部分组成:发送端信息携带NTP时间同步和数据发送统计等内容,报告块则包含发送端接收到数据的统计信息。关于RTCP报文格式的详细信息,请继续参考RFC3550 [1]。</br>
RFC3550关于RTP档次的定义如下[1]:</br>
“档次定义了一系列负载类型和对应的负载格式,也定义了特定于具体应用的RTP扩展和修改。典型地,某个应用仅基于一个档次运行。”</br>
IETF针对RFC3550在档次方面定义了一系列扩展协议,总结如下表1:</br>
RFC3551(RTP/AVP)在RFC3550的基础上针对RTP档次进行补充形成RTP/APVP档次,被用在具有最小会话控制的音视频会议中,是其它扩展档次的基础。该档次在没有参数协商和成员控制的会话中非常有用。该档次也为音视频定义一系列编码和负载格式。对于具体的流媒体负载格式,IETF也定义一系列协议详细描述,如VP8视频负载格式[6]和H264视频负载格式[7],等等。</br>
RFC3711(SRTP,也即RTP/SAVP)是RTP/AVP在安全方面进行扩展形成的档次,为RTP/RTCP提供数据加密、消息认证、重放保护等功能。SRTP具有高吞吐量和低数据膨胀等特点,是异构环境下对RTP/RTCP数据的有效保护。</br>
RFC4585(RTP/AVPF)是RTP/AVP在及时反馈方面进行扩展形成的档次,使得接收端能够向发送端提供及时反馈,实现短时调整和基于反馈的修复机制。该协议定义早期RTCP报文以实现及时反馈,并定义一系列通用RTCP反馈报文和特定于应用的反馈报文,如NACK、PLI、SLI、RPSI等。</br>
RTC5124(RTP/SAVPF)则是RTP/SAVP和RTP/AVPF的综合。SAVP和AVPF在使用时,需要参与者借助于SDP协议[8]就档次和参数信息达成一致。但是对一个RTP会话来说,这两种档次不能同时被协商。而实际应用中,我们有同时使用这两种档次的需要。因此,RTP/SAVPF档次应运而生,它能够使得RTP会话同时具有安全和及时反馈两方面的特性。</br>
本节对RFC3550在档次方面扩展形成的一系列协议进行初步分析。可以看到,RFC3550只定义最基本的内容,在实际应用中会对其在安全性、及时反馈等方面进行扩展。</br>
RFC 3550定义五种RTCP报文,类型在报文头部的PT域定义。表2对它们作简单描述。</br>
SR报文用于发送端报告本端的数据发送统计信息和数据接收统计信息,RR报文用于报告本端的数据接收统计信息,SDES报文用于报告本端的描述性信息,BYE在本端离开会话时发送,而APP则是特定于应用的数据。</br>
IETF根据实际需求对RTCP的报文类型进行扩展,定义了一系列协议。对这类RTCP报文总结如表3所示:</br>
下面对这些RFC做进一步分析:</br>
RFC5450 - Tran***ission Time Offsets in RTP Streams</br>
该协议在定义一种更精细地描述传输时间的方法的基础上,定义一种改进的Jitter报告报文,负载类型为195。</br>
RFC5104 - Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)</br>
该协议对RFC4585 AVPF档次进一步补充,定义一系列传输层和特定于负载的RTCP报文格式。该系列报文对SR/RR报文的RC域重定义为FMT域,用以区分报文的子类型。综合RFC4585所定义的报文,如下表4所示:</br>
RFC3611 - RTP Control Protocol Extended Reports (RTCP XR)</br>
该协议定义RTCP扩展报告块,负载类型为207。RTCP扩展报告块在SR/RR报告块的基础上传输更多的信息。RFC3661定义了7种子报告块,总结如表5:</br>
本节以报文类型为主线,归纳总结RTCP报文及其扩展报文,内容比较多也比较繁琐。这些报文为RTP提供更丰富的控制信息和统计数据。</br>
本文在分析RTP/RTCP基础协议RFC3550的基础上,以档次为主线分析RTP系列扩展协议,以报文类型为主线分析RTCP系列扩展协议。通过以上工作,得到一个较为清晰的框架和流程,为进一步学习RTP/RTCP协议打下良好基础。</br>
</br>
[1] RFC3550 - RTP: A Transport Protocol for Real-Time Applications </br>
[2] RFC3551 - RTP Profile for Audio and Video Conferences with Minimal Control </br>
[3] RFC3711 - The Secure Real-time Transport Protocol (SRTP) </br>
[4] RFC4585 - Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-based Feedback (RTP/AVPF) </br>
[5] RFC5124 - Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-based Feedback (RTP/SAVPF) </br>
[6] RFC7741 - RTP Payload Format for VP8 Video </br>
[7] RFC6184 - RTP Payload Format for H.264 Video </br>
[8] RFC4566 - SDP: Session Description Protocol </br>
[9] RFC 5450 - Tran***ission Time Offsets in RTP Streams </br>
[10] RFC 5104 - Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF) </br>
[11] RFC3611 - RTP Control Protocol Extended Reports (RTCP XR) </br>
1、RTP概述
实时传输协议(Real-time Transport Protocol或简写RTP)是一个网络传输协议,作为因特网标准在RFC 3550(该文档的旧版本是RFC 1889)有详细说明。RFC 3551(STD 65,旧版本是RFC 1890)详细描述了使用最小控制的音频和视频会议。
RTP协议详细说明了在互联网上传递音频和视频的标准数据包格式。它一开始被设计为一个多播协议,但后来被用在很多单播应用中。RTP协议常用于流媒体系统(配合RTSP协议),视频会议和一键通(Push to Talk)系统(配合H.323或SIP),使它成为IP电话产业的技术基础。RTP协议和RTP控制协议RTCP一起使用。
2、RTP协议格式
RTP包结构 = RTP包头 + payload 载荷数据(媒体数据),包头结构如下(粗体字段,重点关注):
1. V:RTP协议的版本号,占2位,当前协议版本号为2。
2. P:填充标志,占1位,如果P=1,则在该报文的尾部填充一个或多个额外的八位组,它们不是有效载荷的一部分。
3. X:扩展标志,占1位,如果X=1,则在RTP报头后跟有一个扩展报头。
4. CC:CSRC计数器,占4位,指示CSRC 标识符的个数。
5. M : 标记,占1位,不同的有效载荷有不同的含义,对于视频,标记一帧的结束;对于音频,标记会话的开始。
6. PT: 有效载荷类型,占7位,用于说明RTP报文中有效载荷的类型,如GSM音频、JPEM图像等,在流媒体中大部分是用来区分音频流和视频流的,这样便于客户端进行解析。
7. 序列号 :占16位,用于标识发送者所发送的RTP报文的序列号,每发送一个报文,序列号增1。这个字段当下层的承载协议用UDP的时候,网络状况不好的时候可以用来检查丢包。
8. 时间戳(Timestamp) :占32位,反映了该RTP报文的第一个八位组的采样时刻。接收者使用时戳来计算延迟和延迟抖动,并进行同步控制。使用的是采样时间。
9. 同步信源(SSRC)标识符 :占32位,用于标识同步信源。该标识符是随机选择的,参加同一视频会议的两个同步信源不能有相同的SSRC。
10. 特约信源(CSRC)标识符:每个CSRC标识符占32位,可以有0~15个。每个CSRC标识了包含在该RTP报文有效载荷中的所有特约信源。
3、抓包分析
相关的参数在软件已经分析出来,其中RTP数据中包含了两种数据,PT为96的为视频;PT为97的为音频。
以上就是关于RTP/RTCP协议详解全部的内容,如果了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!
版权声明:本文内容由用户投稿和互联网及文摘转载整编而成,不代表本站观点,不承担相关法律责任。其著作权各归其原作者或其出版社所有。如发现本站有涉嫌抄袭侵权/违法违规的内容,侵犯到您的权益,请在线联系站长,一经查实,本站将立刻删除。转载请注明出处:https://www.gulizw.com/guli/170265.html