前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
社区首页 >专栏 >RTP/RTCP详解系列-----协议介绍

RTP/RTCP详解系列-----协议介绍

作者头像
lcyw
发布于 2022-06-10 11:13:52
发布于 2022-06-10 11:13:52
9.3K00
代码可运行
举报
文章被收录于专栏:machh的专栏machh的专栏
运行总次数:0
代码可运行

概述:

实时传送协议(Real-time Transport Protocol或简写RTP)是一个网络传输协议,

它是由IETF的多媒体传输工作小组提出的一个标准,对应的RFC文档为RFC3550(RFC1889为其过期版本).RFC3550不仅定义了RTP,而且定义了配套的相关协议RTCP(Real-time Transport Control Protocol,即实时传输控制协议)。

RTP协议详细说明了在互联网上传递音频和视频的标准数据包格式。它一开始被设计为一个多播协议,但后来被用在很多单播应用中。RTP协议常用于流媒体系统(配合RTCP协议或者RTSP协议)。因RTP协议和RTP控制协议RTCP一起使用,而且它是建立在用户数据报协议上的。RTP广泛应用于流媒体相关的通讯和娱乐,包括电话、视频会议、电视和基于网络的一键通业务(类似对讲机的通话)。

RTP(实时传输协议),顾名思义它是用来提供实时传输的,因而可以看成是传输层的一个子层。下图图给出了流媒体应用中的一个典型的协议体系结构。

图 1 流媒体体系结构

从图中可以看出,RTP被划分在传输层,它建立在UDP上。同UDP协议一样,为了实现其实时传输功能,RTP也有固定的封装形式。RTP用来为端到端的实时传输提供时间信息和流同步,但并不保证服务质量。服务质量由RTCP来提供。

不少人也把RTP归为应用层的一部分,这是从应用开发者的角度来说的。操作系统中的TCP/IP等协议栈所提供的是我们最常用的服务,而RTP的实现还是要靠开发者自己。因此从开发的角度来说,RTP的实现和应用层协议的实现没不同,所以可将RTP看成应用层协议。 RTP实现者在发送RTP数据时,需先将数据封装成RTP包,而在接收到RTP数据包,需要将数据从RTP包中提取出来。

实时传输协议 RTP,RTP 提供带有实时特性的端对端数据传输服务,传输的数据如:交互式的音频和视频。那些服务包括有效载荷类型定义,序列号,时间戳和传输监测控制。应用程序在 UDP 上运行 RTP 来使用它的多路技术和 checksum 服务。2 种协议都提供传输协议的部分功能。不过,RTP 可能被其他适当的下层网络和传输协议使用。如果下层网络支持,RTP 支持数据使用多播分发机制转发到多个目的地。

注意 RTP 本身没有提供任何的机制来确保实时的传输或其他的服务质量保证,而是由低层的服务来完成。它不保证传输或防止乱序传输,它不假定下层网络是否可靠,是否按顺序传送数据包。RTP 包含的序列号允许接受方重构发送方的数据包顺序,但序列号也用来确定一个数据包的正确位置,例如,在视频解码的时候不用按顺序的对数据包进行解码。但是 RTP 原先的设计是用来满足多参与者的多媒体会议的需要,它没有限定于专门的应用。连续数据的储存,交互分布式仿真,动态标记,以及控制和测量应用程序也可能会适合使用 RTP

RTP协议格式:

图2 RTP固定头结构

由上图中可知道RTP报文由两个部分构成--RTP报头和RTP的负载:

RTP报文由两部分组成:报头和有效载荷。RTP报头格式如图6.7所示,其中:

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的时候,网络状况不好的时候可以用来检查丢包。同时出现网络抖动的情况可以用来对数据进行重新排序,在helix服务器中这个字段是从0开始的,同时音频包和视频包的sequence是分别记数的。

8. 时戳(Timestamp):占32位,时戳反映了该RTP报文的第一个八位组的采样时刻。接收者使用时戳来计算延迟和延迟抖动,并进行同步控制。

9. 同步信源(SSRC)标识符:占32位,用于标识同步信源。该标识符是随机选择的,参加同一视频会议的两个同步信源不能有相同的SSRC。

10. 特约信源(CSRC)标识符:每个CSRC标识符占32位,可以有0~15个。每个CSRC标识了包含在该RTP报文有效载荷中的所有特约信源。

如果扩展标志被置位则说明紧跟在报头后面是一个头扩展,其格式如下:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |      defined by profile       |           length              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                        header extension                       |
 |                             ....                              |

RTP扩展头结构

RTP 提供扩展机制以允许实现个性化:某些新的与负载格式独立的功能要求的附加信息在RTP 数据包头中传输。设计此方法可以使其它没有扩展的交互忽略此头扩展。RTP扩展头格式如图3所示。

图3 RTP扩展头格式

若 RTP 固定头中的扩展比特位置 1,则一个长度可变的头扩展部分被加到 RTP 固定头之后。头扩展包含 16 比特的长度域,指示扩展项中 32 比特字的个数,不包括 4 个字节扩展头(因此零是有效值)。RTP 固定头之后只允许有一个头扩展。为允许多个互操作实现独立生成不同的头扩展,或某种特定实现有多种不同的头扩展,扩展项的前 16 比特用以识别标识符或参数。这 16 比特的格式由具体实现的上层协议定义。基本的 RTP 说明并不定义任何头扩展本身。

RTCP的封装

RTP需要RTCP为其服务质量提供保证,因此下面介绍一下RTCP的相关知识。

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

从图 1可以看到,RTCP也是用UDP来传送的,但RTCP封装的仅仅是一些控制信息,因而分组很短,所以可以将多个RTCP分组封装在一个UDP包中。RTCP有如下五种分组类型。

类型

缩写表示

用途

200

SR(Sender Report)

发送端报告

201

RR(Receiver Report)

接收端报告

202

SDES(Source Description Items)

源点描述

203

BYE

结束传输

204

APP

特定应用

表 1 RTCP的5种分组类型

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

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

图4

版本(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包到发送本报告的延时。

RTP的会话过程

当应用程序建立一个RTP会话时,应用程序将确定一对目的传输地址。目的传输地址由一个网络地址和一对端口组成,有两个端口:一个给RTP包,一个给RTCP包,使得RTP/RTCP数据能够正确发送。RTP数据发向偶数的UDP端口,而对应的控制信号RTCP数据发向相邻的奇数UDP端口(偶数的UDP端口+1),这样就构成一个UDP端口对。 RTP的发送过程如下,接收过程则相反。

1) RTP协议从上层接收流媒体信息码流(如H.263),封装成RTP数据包;RTCP从上层接收控制信息,封装成RTCP控制包。

2) RTP将RTP 数据包发往UDP端口对中偶数端口;RTCP将RTCP控制包发往UDP端口对中的接收端口。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2016-06-30,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 音视频开发训练营 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
RTP协议–图文解释
当应用程序建立一个RTP会话时,应用程序将确定一对目的传输地址。目的传输地址由一个网络地址和一对端口组成,有两个端口:一个给RTP包,一个给RTCP包,使得RTP/RTCP数据能够正确发送。RTP数据发向偶数的UDP端口,而对应的控制信号RTCP数据发向相邻的奇数UDP端口(偶数的UDP端口+1),这样就构成一个UDP端口对。 RTP的发送过程如下,接收过程则相反。
全栈程序员站长
2022/09/13
3K0
RTP协议–图文解释
RTP 协议
原博客地址:http://www.cnblogs.com/qingquan/archive/2011/07/28/2120440.html
全栈程序员站长
2022/09/13
7190
RTP 协议
RTP协议头详解
前 12 个字节出现在每个 RTP 包中,仅仅在被混合器插入时,才出现 CSRC 识别符列表。各个域的含义如下所示:
全栈程序员站长
2022/09/13
1.9K0
RTP协议头详解
手撕RTSP协议系列(12)——RTP包格式
前面我们花了较多的篇幅来介绍了RTSP协议的一些细节,但是rtsp传输,本质上涉及三种协议,RTSP、RTP以及RTCP。RTSP主要负责连接建立,销毁及一些其他的控制。而实际涉及媒体数据传输使用的是RTP协议,本节我们来介绍一下RTP协议。
视界音你而不同
2020/10/30
7.9K1
手撕RTSP协议系列(12)——RTP包格式
手撕RTSP协议系列(13)——RTCP协议
之前的文章,介绍了RTSP和RTP协议,RTSP用于建立连接及发送请求等,RTP用于实际的媒体数据传输。整个RTSP的流程中,还有一种不可或缺的协议, 那就是RTCP。RTCP的全称是RTP Control Protocol,从英文名称可以看出,其是针对RTP的控制协议!RTCP主要用于提供数据分发质量反馈信息,本文详细介绍一下RTCP协议!
视界音你而不同
2020/10/30
4.9K1
手撕RTSP协议系列(13)——RTCP协议
RTP协议与实战
在实时音视频通话中,我们通常使用 UDP 作为传输层协议,使用 RTP 协议包荷载音视频数据,RTP(Real-time Transport Protocol)是一种在 Internet 上传输多媒体数据的应用层协议,它通常建立在 UDP 之上(也可以建立在 TCP 上)。UDP 协议没有序号等信息,而 RTP 协议可以补充许多音视频传输必要的信息,让音视频数据到达对端后可以重新组合完整,RTP 本身只保证实时数据的传输,并不能提供可靠传输保证,也没有流量控制,拥塞控制机制,它通常与 RTCP 配合使用以提供这些服务。
全栈程序员站长
2022/09/13
1.5K0
RTP协议与实战
音视频传输:RTP协议详解和H.264打包方案
前面讲解了PS、TS、FLV这三种媒体封装格式,现在新开一个系列讲解下传输协议,这里面会包含RTP、RTSP、HLS、RTMP等。当然最复杂的封装格式MP4在准备中,后面会把封装格式这个系列讲完。今天要说的RTP传输协议,有人也认为这是封装格式,因为协议中打包音视频要填写时间戳的相关信息,FFmpeg就把这个作为封装格式。我觉得都没啥问题,不过我更偏向认为是传输协议。
潇湘落木
2020/11/12
6.8K0
音视频传输:RTP协议详解和H.264打包方案
可靠互联网传输协议(RIST)简介
视频压缩技术的进步和互联网基础设施的普及,使得流媒体在互联网上广泛传输。但是网络丢包一直是一个困扰人们的问题。市面上已经有许多私有的解决方案用于解决流媒体传输的丢包问题,但是由于是私有协议,各个厂商的设备之间无法实现互操作性。为解决在公共网络上的丢包问题,同时解决各厂商设备之间缺乏互操作性的问题,Video Services Forum (VSF) 于2017年初成立了可靠的互联网流传输协议(Reliable Internet Stream Transport,RIST)小组,为协议创建通用规范[1][2]。
用户1324186
2019/08/14
5.3K0
可靠互联网传输协议(RIST)简介
RTP协议分析
RTP全名是Real-time Transport Protocol(实时传输协议)。它是IETF提出的一个标准,对应的RFC文档为RFC3550(RFC1889为其过期版本)。RFC3550不仅定义了RTP,而且定义了配套的相关协议RTCP(Real-time Transport Control Protocol,即实时传输控制协议)。RTP用来为IP网上的语音、图像、传真等多种需要实时传输的多媒体数据提供端到端的实时传输服务。RTP为Internet上端到端的实时传输提供时间信息和流同步,但并不保证服务质量,服务质量由RTCP来提供。
全栈程序员站长
2022/08/03
1.2K0
RTP协议分析
WebRTC中的RTP协议、RTCP协议、DSP协议
实时互动直播系统必须使用UDP作为数据传输的协议,为什么一定是UDP。TCP是一种可靠的传输协议,会保证在传输的过程中不丢包,UDP传输的速度快,但是不可靠,尤其是用户网络质量很差的情况下,会出现大量的丢包,基本无法保证音视频的服务质量。
码农帮派
2021/01/12
2.6K0
WebRTC中的RTP协议、RTCP协议、DSP协议
流媒体协议介绍(rtp/rtcp/rtsp/rtmp/mms/hls)
         Real-time Transport Protocol)是用于Internet上针对多媒体数据流的一种传输层协议。RTP协议详细说明了在互联网上传递音频和视频的标准数据包格式。RTP协议常用于流媒体系统(配合RTCP协议),视频会议和一键通(Push to Talk)系统(配合H.323或SIP),使它成为IP电话产业的技术基础。RTP协议和RTP控制协议RTCP一起使用,而且它是建立在UDP协议上的。 
雪影
2018/08/02
6.6K0
流媒体协议介绍(rtp/rtcp/rtsp/rtmp/mms/hls)
rtp协议详解
RTP全名是Real-time Transport Protocol(实时传输协议)。它是IETF提出的一个标准,对应的RFC文档为RFC3550。RFC3550不仅定义了RTP,而且定义了配套的相关协议RTCP(Real-time Transport Control Protocol,即实时传输控制协议)。RTP用来为IP网上的语音、图像、传真等多种需要实时传输的多媒体数据提供端到端的实时传输服务。RTP为Internet上端到端的实时传输提供时间信息和流同步,但并不保证服务质量,服务质量由RTCP来提供。
全栈程序员站长
2022/09/07
1.6K0
rtp协议详解
手撕RTSP协议系列(6)——SETUP
SETUP请求的作用是指明媒体流该以什么方式传输;每个流PLAY之前必须执行SETUP操作;发送SETUP请求时,客户端会指定两个端口,一个端口用于接收RTP数据;另一个端口接收RTCP数据,偶数端口用来接收RTP数据,相邻的奇数端口用于接收RTCP数据!
视界音你而不同
2020/10/30
3.6K0
手撕RTSP协议系列(6)——SETUP
Web前端WebRTC攻略(三) 传输协议UDP/RTP/RTC
导语 | 音视频时代,WebRTC在形形色色的产品和业务场景下均有落地。在熟悉如何在浏览器获取设备的音视频数据和WebRTC是如何将获取的音视频数据进行网络传输的同时,我们更要夯实一下网络传输协议相关的基础知识,这能帮助我们更深入地学习WebRTC。推荐和前端音视频专题中的文章一起食用。 1. 传输层协议:TCP vs. UDP 我们都知道HTTP协议,运行于TCP协议之上,是万维网的运转的基础。作为一名前端开发,我们似乎理所应当熟悉HTTP、TCP协议,以致于HTTP状态码、报文结构、TCP三次握手、四次
用户1097444
2022/06/29
3.7K0
Web前端WebRTC攻略(三) 传输协议UDP/RTP/RTC
国标GB28181协议客户端开发(四)实时视频数据传输
在GB28181协议中,在实时音视频传输过程中,使用INVITE报文携带SDP(Session Description Protocol)信息。SDP信息描述了会话的属性和参数,包括媒体类型、传输协议、编解码器、网络地址等。下面是一个示例INVITE报文的SDP内容,并对其中的每一项进行详细解释:
hbstream
2023/07/06
1.3K0
国标GB28181协议客户端开发(四)实时视频数据传输
技术解码 | GB28181协议简介及实践
GB28181协议是视频监控领域的国家标准,本文将解析如何在FFmpeg中增加对GB28181协议的支持,使其可以与支持GB28181协议的设备进行通信与控制,实现设备的注册、保活以及流媒体的传输。  GB28181协议指的是国家标准GB/T 28181—2016《公共安全视频监控联网系统信息传输、交换、控制技术要求》1,该标准规定了公共安全视频监控联网系统的互联结构, 传输、交换、控制的基本要求和安全性要求, 以及控制、传输流程和协议接口等技术要求,是视频监控领域的国家标准。GB28181协
腾讯云音视频
2021/05/13
18K1
WebRTC-FEC[通俗易懂]
本文档为封装在RTP中的媒体数据的通用前向纠错(FEC)指定了有效负载格式。它基于异或(奇偶校验)操作。本文档中描述的有效负载格式允许终端系统使用不同的保护长度和级别来应用保护,此外还使用不同的保护组大小来适应不同的媒体和信道特性。它能够根据丢包情况完全恢复受保护的数据包或部分恢复有效负载的关键部分。该方案与不支持FEC的主机完全兼容,因此不实现FEC的多播组中的接收机只需忽略保护数据即可工作。本规范淘汰了RFC 2733和RFC 3009。本文件中规定的FEC与RFC 2733和RFC 3009不向后兼容。
全栈程序员站长
2022/09/22
1.6K0
WebRTC-FEC[通俗易懂]
技术解码丨Webtrc中RTCP使用及相关指标计算
在RFC3550中,除了定义了⽤来进⾏实时数据传输的 RTP 协议外,还定义了 RTCP 协议,⽤来反馈会话传输质量、⽤户源识别、控制 RTCP 传输间隔。在 Webrtc 中,通过 RTCP 我们可以实现发送数据/接收数据的反馈,传输控制如丢包重传、关键帧请求,⽹络指标 RTT、丢包率、抖动的计算及反馈,拥塞控制相关的带宽 反馈,以及⽤户体验相关的⾳视频同步等等。为了让开发者获取以上数据指标,Webrtc 提供了统⼀的接⼝调用,如在GoogleChrome中,可以通过 RTCPeerConnection
腾讯即时通信IM
2021/04/19
2.5K0
音视频 RED 与 FEC 的 RTP 格式封装[通俗易懂]
对于语音通信来说,语音的码率较低,添加适当的冗余是对抗网络丢包常见的方式。冗余方式分为多种,包括数据冗余,或者编码冗余等,RED,FEC等都是冗余的一种。如果冗余分数较多,可以采取交织的方式实现。RFC 2198 是冗余数据 RTP 封装的标准协议,RFC 3550 为RTP的基础标准协议,RFC 5109 为FEC数据的 RTP 封装标准协议。webrtc中有RED和FEC相关的实现与处理,这也是在看代码时才决定重新整理协议并记录下来。
全栈程序员站长
2022/09/22
1.7K0
音视频协议-RTP协议
音视频传输的基石:RTP和RTCP。对于协议的讲解主要是是对于RFC文档的阅读和理解。不同的使用场景用到的字段也有所侧重,RTP和RTCP定义在RFC3550中。其中RTP用于数据流的传输;RTCP用于数据流的控制。可以说rtp/rtcp协议是即时通讯不可或缺的组成。RTCP协议介绍见:音视频协议-RTCP协议介绍
全栈程序员站长
2022/09/13
8330
音视频协议-RTP协议
相关推荐
RTP协议–图文解释
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档
本文部分代码块支持一键运行,欢迎体验
本文部分代码块支持一键运行,欢迎体验