rtp介绍

RTP为实时应用提供端到端的运输,但不提供任何服务质量的保证。多媒体数据块经过压缩编码处理后,先送给RTP封装成为RTP分组,RTP分组再装入UDP用户数据报,然后再向下地交给IP层。RTP是一个协议框架,因为它只包含了实时应用的一些共同的功能。
RTP分组只包含RTP数据,而控制是由另一个配套协议RTCP提供。
RTP在端口号1025到65535之间选择一个未使用的偶数UDP端口号,而在同一次会话中的RTCP则使用下一个奇数UDP端口号。但端口号5004和5005则分别用作RTP和RTCP的默认端口号。
RTP位于传输层(通常是UDP)之上,应用程序之下。它提供同步播放媒体数据所需要的时间戳和序列号,并不具有差错和流量控制机制,这些需要应用程序实现。
RTCP通常和RTCP一起提供流量控制和拥塞控制服务。在RTP会话期间,各参与者周期的发送RTCP数据报。RTCP数据报含有已发送数据的数量丢失的数据报的数量等统计资料,因此,服务器可以利用这些信息动态的改变传输速率,甚至改变净荷的类型。
(照我目前的理解是:RTP和RTCP提供了这些信息给应用程序,但是RTP和RTCP并不定义根据这些信息的动作,
就像TCP的重发和滑动窗口等都是协议自己完成的。但是RTP并不自己做这些事情。)
RTP分组首部结构:






V:版本号;

P:填充字段标识;

X:扩展头标识;

CSRC count(CC):贡献源数目,和后面的CSRC有关。CSRC,贡献源,指的是不同步的源。在网络中,可能会有混合器将来自不同地点的RTP流混合成一个RTP流以节省带宽, CSRC用来区分不同的源;

M:标记一些重要的事件(由应用程序定义);

PT:净荷数据类型;

SN:序列号,每个分组的序列号(初始值随机),用来检测分组的丢失并恢复分组的序列;

TS:时间戳,反映RTP净荷中的第一个采样数据的采样时间。时间的粒度是净荷类型相关的。

例如,如果采样间隔是125微妙,在分组n+1中的第一个样本和在分组n中的第一个样本之间相差10毫秒,那么在这两个样本之间的采用数目将等于:

两个分组之间的时间/每个样本的时间=80

假定时钟颗粒度与采用间隔相同,那么分组n+1中的时标将比在分组n中的时标大80。

注意:时标和序列号的区别。由于像MPEG的交错帧的时标不是顺序发送的;但是顺序号必须是单调的。

SSRC:同步源标识符,用于标识同步源。同步源指的是,例如,一段影片的音频和视频通过不同的RTP流传输,它们是同步的。每个同步源是负责发送RTP分组并在RTP中设置序列号和时间戳的实体。

RTCP的主要功能是:服务质量的监视与反馈,媒体间的同步,以及多播组中成员的标识。由于RTCP分组很短,因此把多个RTCP分组封装在一个UDP用户数据报中。RTCP分组周期性的在网上传送,它带有发送端和接收端对服务质量的统计信息报告(如已发送的分组数和字节数,分组丢失率,分组到达时间间隔的抖动等)。

RTCP可以说是控制交通的协议,它提供了:

1)SR发送者报告分组:用来使发送端周期的向所有接收端用多播方式进行报告。内容包括:

该RTP流的SSRC;该RTP流中最新产生的RTP分组的时间戳和绝对时钟时间(或称墙上时间:wall clock time);该RTP流包含的分组数;该RTP流包含的字节数。

绝对时钟时间是必要的。因为RTP要求每一种媒体使用一个流。有了绝对时钟时间就可以进行图形和声音的同步。

2)RR接收者报告分组:用来使接收端周期性的向所有的点用多播方式进行报告。内容包括:

所接收到的RTP流的SSRC;该RTP流的分组丢失率;在该RTP流中的最后一个RTP分组的序号;分组到达时间间隔的抖动等。

发送RR分组有两个目的。第一,可以使所有的接收端和发送端了解当前网络的状态。

第二,可以使所有发送RTCP分组的站点自适应的调整自己发送RTCP分组的速率,RTCP分组的通信量不超过网络中的数据分组的通信量的5%,而接收端分组报告分组的通信量又应小于所有RTCP分组的通信量的75%。

3)SDES源描述分组:给出会话中参加者的描述,包括参加者的规范名(CNAME)

4)BYE分组:关闭一个数据流。

5)APP分组:应用程序能够定义新的分组类型。

一个概念:规范名字CNAME,用于标识某个实体,通常使用用户名@域名,一个实体可以产生不同的RTP流,各自有不用的SSRC,但是CNAME是固定的。
<think>我们正在讨论RTP协议,这是一个实时传输协议。根据用户的需求,我们需要详细介绍RTP协议及其相关规范。我们可以参考RFC3550,因为它是定义RTP的核心文档。此外,用户提供的引用中提到了RTP在VoIP和ONVIF中的应用,我们可以适当关联这些应用场景,但重点还是放在协议本身。回答结构:1.首先介绍RTP协议的基本概念、目的和设计原则。2.详细解释RTP的数据包格式(头部结构)。3.说明RTP的工作机制,包括时间戳、序列号、负载类型等。4.介绍RTP的控制协议RTCP,包括其作用和报文类型。5.讨论RTP的相关RFC文档(如RFC3550、RFC3551等)以及一些扩展。6.简要提及RTP在VoIP和视频监控(如ONVIF)中的应用。7.最后,生成相关问题。注意:根据用户提供的引用,我们注意到RFC3550是RTP的核心文档,同时用户之前的问题涉及RTT计算(在RFC3550中也有定义),因此我们可以强调这一点。由于用户要求详细介绍,我们将尽可能详细地描述RTP协议。</think>### RTP协议详解及其相关规范 RTP(Real-time Transport Protocol,实时传输协议)是互联网实时多媒体数据传输的核心标准,由IETF在**RFC 3550**中定义[^1]。以下从协议架构到应用场景进行系统解析: --- #### 一、RTP核心设计原理 1. **定位与目标** RTP专为**实时流媒体**(音视频、交互应用)设计,提供端到端传输服务: - 时间戳同步:解决网络抖动导致的音画不同步问题 - 丢包容忍:不保证可靠性,但通过序列号支持乱序重组 - 低延迟:优先传输时效性数据 2. **协议栈关系** $$ \text{RTP} \xrightarrow{\text{承载}} \text{UDP} \xrightarrow{\text{网络层}} \text{IP} $$ RTP通常运行在UDP之上,避免TCP重传机制引入的延迟[^1]。 --- #### 二、RTP数据包结构(RFC 3550定义) RTP头部固定12字节,格式如下: ```plaintext 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CSRC identifiers | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ``` - **关键字段**: - `V(2bit)`:版本号(固定为2) - `P(1bit)`:填充标志(加密时填充数据) - `X(1bit)`:扩展头标志 - `CC(4bit)`:CSRC计数器(混合源数量) - `M(1bit)`:标记位(视频帧边界标识) - `PT(7bit)`:负载类型(编码格式,如H.264=96) - `Sequence number(16bit)`:包序号(检测丢包) - `Timestamp(32bit)`:时间戳(采样时刻,单位1/90000秒) - `SSRC(32bit)`:同步源标识(会话唯一ID) - `CSRC(32bit×CC)`:贡献源标识(混流场景)[^1] --- #### 三、RTP控制协议(RTCP) RTCP(RFC 3550第6章)与RTP协同工作,提供**QoS反馈**: 1. **报文类型**: - SR(Sender Report):发送端统计(包数、字节数) - RR(Receiver Report):接收端统计(丢包率、抖动) - SDES:源描述信息(用户名、邮箱) - BYE:会话终止 - APP:应用自定义数据 2. **关键功能**: - **RTT计算**:通过SR/RR的时间戳计算往返延迟 $$ \text{RTT} = T_{\text{now}} - T_{\text{LSR}} - T_{\text{DLSR}} $$ 其中 $T_{\text{LSR}}$ 是最后接收SR的时间,$T_{\text{DLSR}}$ 是处理延迟[^1] - **动态码率调整**:根据丢包率反馈调整编码参数 - **会话同步**:关联音视频流的SSRC实现唇音同步 --- #### 四、关键扩展规范 1. **负载格式规范**: - **RFC 3551**:RTP Profile for Audio and Video Conferences - **RFC 6184**:RTP Payload Format for H.264 Video - **RFC 6716**:Opus音频编码的RTP封装 2. **传输优化**: - **RFC 4588**:RTP Retransmission(支持选择性重传) - **RFC 5109**:RTP Payload Format for Generic FEC(前向纠错) 3. **安全机制**: - **RFC 3711**:SRTP(Secure RTP),提供加密/认证 --- #### 五、典型应用场景 1. **VoIP系统**(基于SIP协议): - RTP承载语音数据,RTCP反馈网络质量 - 与SIP(RFC 3261)协同完成会话控制[^1] 2. **视频监控**(ONVIF标准): - ONVIF规范要求设备通过RTP/RTSP传输音视频流[^2] - 实现跨厂商设备互操作(如海康威视与Axis摄像头互通) 3. **WebRTC**: - 浏览器间实时通信的核心传输协议 - 结合ICE/STUN/TURN穿越NAT --- #### 六、协议实现要点 1. **缓冲区设计**: - 接收端需**抖动缓冲区**消除网络波动 - 深度计算公式:$ \text{JitterBuffer} = k \times \sigma $($\sigma$为抖动方差) 2. **时间戳处理**: - 音频按采样率递增(如8kHz→时间戳间隔125μs) - 视频按帧率递增(如30fps→间隔33ms) > 完整规范参见RFC 3550原文:[RFC 3550 - RTP: A Transport Protocol for Real-Time Applications](https://tools.ietf.org/html/rfc3550)
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值