流媒体协议-RTP\RTCP协议简介

目录

1：概述：

2：RTP协议详解：

3：RTCP协议详解：

结束：

---

1：概述：

RTP（Real-time Transport Protocol）和RTCP（Real-time Transport Control Protocol）是用于实时多媒体数据传输的一对协议，常用于流媒体领域。它们位于传输层之上，为实时传输提供了必要的功能和控制。

1. RTP（实时传输协议）：

   • RTP主要用于提供端到端的实时多媒体数据传输服务。它负责将音频和视频等多媒体数据以实时的方式从发送端传输到接收端。RTP本身并不处理数据传输的可靠性和顺序性，而是专注于实时性。
   • RTP定义了数据包的格式和传输规则，包括时间戳、序列号等信息，以确保接收端能够正确地解析和播放多媒体数据，并维护正确的播放顺序。

2. RTCP（实时传输控制协议）：

   • RTCP主要用于服务质量监视、媒体同步和多播组中成员的标识。它在传输多媒体数据的同时，提供了一些控制和监控功能。
   • RTCP负责收集端到端传输质量的统计信息，例如丢包率、网络延迟等，以便监视网络的性能并作出调整。
   • RTCP还用于多播组中成员的标识，以便组织成员间的通信和同步。

3. 服务质量保证：

   • RTP本身并不保证数据传输的服务质量，它仅提供了实时传输的基础机制，如数据格式定义和时间戳等。
   • 服务质量的保证主要由RTCP提供，通过收集和分析端到端传输质量的统计信息，RTCP可以帮助监视和调整传输过程，以提供更好的用户体验。例如，当网络出现拥塞或丢包时，RTCP可以通知发送端调整传输速率或重传丢失的数据包，以减少数据丢失和延迟。

因此，RTP和RTCP两者共同协作，使得在网络上能够实现实时多媒体数据的可靠传输和同步播放，从而实现流媒体应用的稳定运行和良好的用户体验

RTP/RTCP协议体系结构图如下：

2：RTP协议详解：

RTP协议头部包括版本号（Version）、填充位（Padding）、扩展头标志位（Extension）、CSRC计数（CSRC count）、标记位（Marker bit）、有效负荷类型（Payload type）、序列号（Sequence number）、时间戳（Timestamp）、同步源标识符（SSRC）和CSRC列表（CSRC list）。 扩展头用于实现个性化功能，允许在RTP数据包头中传输与负载格式独立的附加信息。 RTP提供时间信息和流同步，但不保证服务质量。

RTP协议格式如下图所示：

1. 版本号（Version）：这是一个2位字段，用于指示RTP协议的版本号。默认版本为2.

2. 填充位（Padding）：这是一个1位字段，用于指示RTP数据包中是否包含填充字节。填充字节用于确保RTP数据包的总长度符合特定的要求。如果P被置位，在结尾处包含有一个或多个附加的填充字节，这些填充字节不是有效负荷的一部分,填充是一些需要固定块大小的加密算法所要求的，或是为了在低层PDU搬运RTP包。如果P=1，payload最后一位表示填充字节长度，负载数据需要去掉其尾部的填充字节。

3. 扩展头标志位（Extension）：这是一个1位字段，用于指示RTP数据包是否包含扩展头。扩展头用于传输与负载格式独立的附加信息，如额外的控制信息或解码器配置信息。如果被置位，固定的头后面紧跟了一个头的扩展

4. CSRC计数（CSRC count(CC)）： 这个域长度为4位，指示CSRC（Contributing Source）标识符的数量。CSRC是指导致RTP数据包生成的贡献源的标识符列表。这个域表示了跟在固定头后面的CSRC标识符的数目，这个域只有在通过一个混合器才有非零值。

5. 标记位（Marker bit）：这是一个1位字段，由发送方设置并由接收方使用。它可以用于指示RTP数据包的重要性，或者用于在多媒体流中标记重要的时间点或事件。如果M被置位，表示一些重要的项目如帧边界在包中被标记。但是：它并不直接指示数据包是否是最后一个包或下一帧的开始。相反，它通常用于指示帧的边界或者用于其他应用中的重要事件标记。

   在非分片的RTP打包模式中，如果标记位为1，通常意味着这个数据包可能是一个帧的开始或者是一个重要事件的标记，但不能单独根据这一位来确定。实际上，标记位的含义和使用方式是由发送端和接收端协商确定的，并且根据应用的需要来定义。

   在分片的RTP打包模式中，最后一个分片的标记位通常被设置为1，以表示这个数据包是帧的结束。其他分片的标记位通常为0，以区别于最后一个分片。

   对于接收端来说，如果标记位为1，它可以根据应用的协议和处理逻辑来处理数据包。这可能包括开始解码新的帧、处理重要事件或其他操作。但是，接收端在处理数据包时需要综合考虑其他因素，而不能仅仅依赖于标记位的状态来确定数据包的重要性或顺序。

   因此，在接收端处理数据包时，应该根据具体的应用需求和协议约定来确定是否使用之前保存的包。标记位只是提供了额外的信息，而不是决定性的依据。

6. 有效负荷类型（Payload type）：这是一个7位字段，用于指示RTP数据包中的负载类型，例如音频编码器类型或视频编码器类型。

7. 序列号（Sequence number）：这是一个16位字段，用于标识发送的RTP数据包的顺序。接收方使用序列号来检测丢失的数据包并进行恢复。每送一个RTP包数目就增加一，初始值被设为一个随机数，接收方不仅可以用这个序列号检测包丢失，也可以重组包序列。

8. 时间戳（Timestamp）：这是一个32位字段，用于指示RTP数据包中的时间信息。时间戳表示了RTP数据包中第一个数据样本的时间戳，用于同步多媒体流的播放。时间戳反映了RTP数据包的头一个字节的采样时刻， 采样时刻必须是由一个单调线性增加的时钟产生，这样做是为了接收方的同步和 抖动计算，初始值可以从0开始，例如，如果RTP源使用了一个编码器， 缓冲20ms的音频数据，那么RTP时间戳必须每个包增加160，无论包是被传递了还是被丢失了。

9. 同步源标识符（SSRC）：这是一个32位字段，用于唯一地标识RTP流中的同步源。SSRC用于区分不同的RTP流，以便接收方正确地处理和同步数据。目的是为了避免同一个RTP会话中两个源有相同的标识

10. CSRC列表（CSRC list）：这是一个32位的列表，包含了贡献源的标识符。CSRC列表用于指示参与生成RTP数据包的贡献源的信息。这个列表标识了在这个包中对有效负荷起作用的所有源，标识符的最大数目限定为15，这是由CC域所限定的（全零在CC域中是被禁止的），如果有超过15个的分配源，只有前15个被标识。

RTP提供时间信息和流同步，这意味着它能够确保多媒体流在接收端以正确的时间顺序播放，并保持音视频的同步。例如，视频流的音频和视频部分应该在播放时保持同步，RTP通过时间戳字段来确保这一点。

然而，RTP本身不保证服务质量，这意味着它不提供关于数据传输的可靠性、延迟、带宽或其他性能指标的保证。这些方面的控制通常由上层协议或应用程序来处理，例如RTCP可以提供有关服务质量的统计信息，但RTP本身不做出任何保证。因此，应用程序或协议需要自行处理这些方面，以保证实时多媒体数据的可靠传输和播放。

3：RTCP协议详解：

RTCP（Real-Time Control Protocol）是一种用于在实时传输协议（RTP）会话中进行控制和监测的协议。RTCP允许RTP端点（如发送端和接收端）在传输过程中相互通信，共享统计信息以及执行同步和质量监控。

在RTP传输过程中，客户端和服务器都需要周期性地传送RTCP包，RTCP包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料，早期为了节省传输过程中的耗时，RTP一般通过UDP方式传输，其可能存在丢包、数据不同步等问题，需要通过RTCP包进行相互监控，根据RTCP重发或者修正操作，

当前由于网络传输及极其性能的飞跃发展，网传稳定性大大提升，RTCP作用越来越小，因此很多时候RTCP只被用来作为心跳使用，有些视频对接协议规范中，甚至去掉了RTCP,不过标准的RTSP传输中，必须RTP/RTCP一起完成码流传输。

RTCP定义了不同类型的包，这些包用于在RTP会话中传递各种信息。这些包类型包括：

1. SR（Sender Report）：发送端报告，用于发送端向接收端报告发送情况。

2. RR（Receiver Report）：接收端报告，用于接收端向发送端反馈接收情况和质量统计信息。

3. SDES（Source Description Items）：源点描述，用于提供有关参与RTP会话的参与者（源点）的信息。

4. BYE：结束传输，用于通知其他参与者当前源点已经退出RTP会话。

5. APP：特定应用，用于扩展RTCP的功能以满足特定应用需求。

这些RTCP包类型中，SR（Sender Report）和RR（Receiver Report）在实时流中经常被使用。下面简要介绍SR包的格式和内容：

其SR包协议格式如下：

• 版本（V）：与RTP包头域相同，指示RTCP协议的版本。

• 填充（P）：与RTP包头域相同，用于指示RTCP包是否包含填充字节。

• 接收报告计数器（RC）：5bits ，指示该SR包中的接收报告块的数目，即报告了几个接收端的信息。可以为0

• 包类型（PT）：8bits，SR包的类型为200。

• 长度域（Length）：16bits，其中存放的是该SR包以32比特为单位的总长度减一

• 同步源（SSRC）：SR包发送者的同步源标识符，与对应RTP包中的SSRC一样。

• NTP Timestamp：SR包发送时的绝对时间值，用于同步不同的RTP媒体流。

• RTP Timestamp：与NTP时间戳对应，用于指示SR包发送时的RTP时间戳。

• Sender’s packet count：发送者发送的RTP数据包的总数。也就是从开始发送包到产生这个SR包这段时间里，发送者发送的RTP数据包的总数. SSRC改变时，这个域清零

• Sender’s octet count：发送者发送的净荷数据的总字节数。也就是从开始发送包到产生这个SR包这段时间里，发送者发送的净荷数据的总字节数（不包括头部和填充）,发送者改变其SSRC时，这个域要清零

• 同步源n的SSRC标识符：每个报告块中包含的是从该源接收到的包的统计信息。

• 丢失率：从上一个SR或RR包发出以来从同步源n来的RTP数据包的丢失率。

• 累计的包丢失数目：从开始接收到同步源n的包到发送SR时的丢失总数。

• 收到的扩展最大序列号：从同步源n收到的RTP数据包中最大的序列号。

• 接收抖动：RTP数据包接受时间的统计方差估计。

• 上次SR时间戳：最近从同步源n收到的SR包中的NTP时间戳。

• 上次SR以来的延时：上次从同步源n收到SR包到发送SR时的延时。

抓包实例：

• 0x80=10000000：V=10=2；P=0;RC=0

• 0xC8: 1bytes,PT=200表示发送端报告

• 0x0006: 2bytes,长度域为6，表示长度为7*4=28字节

• 0x4a9b57b3: 4bytes表示发送端流的SSRC

• 0xd65d72c6a10bd87b：8bytes表示NTP时间戳

• 0x8ce2d14e: 4bytes，RTP时间戳

• 0x005f3c30: 4bytes,发送端包数量

• 0xdb4d5b97: 4bytes,发送端发送的净荷数据的总字节数

wirkshark包分析示例：

RR分组类型格式如下，与SR类似，

RR抓包示例：

RR包的wirshark包分析：

结束：

通常情况下，媒体流的提供方会发送SR（Sender Report）报告，而接收方会发送RR（Receiver Report）报告。SR报告提供了发送端的统计信息，而RR报告提供了接收端的统计信息。这样做的目的是为了让发送端和接收端都能够了解到传输过程中的情况，以便进行调整和优化。

然而，当前很多厂家已经不再严格校验RTCP（Real-Time Control Protocol），即不再强制要求发送端和接收端都发送RTCP报告。这意味着，有些情况下，发送端或接收端可能会选择不发送RTCP报告，而只是简单地传输媒体流。这可能是出于性能或其他方面的考虑。

因此，如果在媒体流对接的过程中，发现对方无故关闭了媒体流，可以通过查看对方是否发送了RTCP报告来判断。如果对方没有发送RTCP报告，那么可能是因为它没有发送RTCP包，这可能是导致媒体流关闭的原因之一。因此，通过观察对方是否发送了RTCP报告，可以帮助诊断媒体流对接过程中出现的问题。