感觉单纯看理论没啥意思，结合RTCP、RTP来看一看抓包详解
RTP
实时传输协议RTP（Realtime Transport Protocol）：是针对Internet上多媒体数据流的一个传输协议, 由IETF作为RFC1889发布，现在最新的为RFC3550。RTP被定义为在一对一或一对多的传输情况下工作，其目的是提供时间信息和实现流同步。RTP的典型应用建立在UDP上，但也可以在TCP等其他协议之上工作。RTP本身只保证实时数据的传输，并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。
RTP报文头格式
之前曾经写过一个RTP报文：https://blog.csdn.net/Magic_o/article/details/130059383?spm=1001.2014.3001.5501
RTP报文头格式（见RFC3550 Page12）：
PT(Payload Type 负载类型)的值定义如下
除了上表中明确指定PT值的负载类型，还有些负载类型由于诞生的较晚，没有具体的PT值，
只能使用动态（dynamic）PT值，即96到127，这就是为什么大家普遍指定H264的PT值为96。
重新抄一遍：
Version (V)
Version 总是 2。
Padding §
Padding 是控制有效载荷是否具有填充值的布尔值。
有效负载的最后一个字节包含添加了多少填充字节的计数。
Extension (X)
如果设置的话，RTP 报头将有扩展段（可选）。这点将在下面更详细地描述。
CSRC count (CC)
在 SSRC 之后，有效负载之前的 CSRC 标识符的数量。
Marker (M)
标记位没有预设含义，用户可以根据自己的需求随意使用它。
在某些情况下，它是在用户讲话时设置的。它还通常用于标记关键帧。
对于将H.264帧封装成RTP包时，属于同一帧的RTP有相同的时间戳，且它们sequence number是连续且单调递增的。
此帧的最后一个RTP包会有一个Mark标记
Payload Type (PT)
Payload Type（负载类型）是此数据包所承载的编解码器的一个唯一标识符。
对于 WebRTC，Payload Type 是动态的。一个呼叫中的 VP8 的 PT 可能与另一个呼叫中的不同。呼叫中的 offerer 确定 Payload Type 到 Session Description（会话描述符）中的编解码器的映射。
Sequence Number
Sequence Number（序列号）用于对流中的数据包进行排序。每次发送数据包时，Sequence Number 都会增加 1。
RTP 被设计为可以在有损网络上使用。这为接收器提供了一种检测数据包何时丢失的方法。
Timestamp
此数据包的采样时刻。这不是全局时钟，而是在当前媒体流中所经过的时间。举例来说，如果多个 RTP 包都属于同一视频帧，那么它们可能具有相同的时间戳。
Synchronization Source (SSRC)
SSRC 是此流的唯一标识符。这使你可以在单个 RTP 流上传输多个媒体流。
Contributing Source (CSRC)
一个列表，用于表示哪些 SSRC 参与到了这个数据包中。
这通常用于语音指示器。假设在服务器端，你将多个音频源组合到一个单独的 RTP 流中。然后，你可以在此字段中表示 " 输入流 A 和 C 此时正在讲话 “。
Payload
实际有效负载数据。如果设置了填充（padding）标记，则可能以添加的填充字节数结尾。
CSRC count (CC)
CSRC是SSRC之后和有效载荷之前的标识符。
详细可以见到https://webrtcforthecurious.com/zh/docs/06-media-communication/#packet-format%E5%8C%85%E6%A0%BC%E5%BC%8F
RTP报文抓包分析
根据您提供的帧信息，这是一个 RTP(实时传输协议) 包，它在以太网 II 上传输，长度为 1147 字节 (9176 位)。该帧的源地址为 Cisco_ba:5a:44(00🇩🇪fb:ba:5a:44),目标地址为 fa:16:3e:d0:ca:a7(fa:16:3e:d0:ca:a7)。该帧使用 IP(互联网协议) 版本 4，源地址为 112.17.79.157，目标地址为 172.21.145.154。该帧使用 UDP(用户数据报协议),源端口为 59037，目标端口为 20309。
这是一个 RTP(实时传输协议) 包，它被 DTLS-SRTP(数据加密协议 - 安全 rtp) 协议初始化。该包的序列号为 9632，扩展序列号为 75168，时间戳为 4038466672。该包包含一个未知的同步源标识符，其定义未知。
该包包含三个 RFC 5285(现代 RTP 协议) 头扩展。
在 RTP 包中，数据部分是一个动态 RTP 类型 (DynamicRTP-Type-96),其序列号为 96。该序列号是动态分配的，用于标识当前数据传输。
该包的 SRTP(安全 rtp) 加密载荷为 f963a0958f28c30d4c526fbdc99c8c1111da25659fcfc57287b164aad3bc41870c239d，其验证标签为 2d49a54079949ef7ffb1。
根据 DTLS-SRTP 协议，初始化协议通过一个 RTP 包进行传输，该包包含一个未知的同步源标识符。在未来的数据传输中，可以使用这个标识符来标识同步源。此外，DTLS-SRTP 还支持加密和认证，以确保数据的机密性和完整性。
RTCP
实时传输控制协议RTCP（Realtime Transport Control Protocol）：负责管理传输质量,在当前应用进程之间交换控制信息，提供流量控制和拥塞控制服务。在RTP会话期间，各参与者周期性地传送RTCP包，包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料，因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。RTP和RTCP配合使用，能以有效的反馈和最小的开销使传输效率最佳化，故特别适合传送网上的实时数据。
RTCP包括五种数据包类型（RFC3550 Page69）：
RTCP报文头格式
每个RTCP包的开始部分是与RTP数据包相类似的固定部分,随后是一块结构化单元,它随负载类型不同长度发生变化,但是总以32比特终止.
发射机报告包由3部分组成,若定义,可能跟随第4个面向协议的扩展部分.
以SR报文为例，RTCP报文格式（RFC3550 Page35）如下：
Version (V)
Version 总是 2。
Padding §
Padding 是控制有效载荷是否具有填充值的布尔值。
有效负载的最后一个字节包含添加了多少填充字节的计数。
Reception Report Count (RC)
此数据包中的报告数。单个 RTCP 数据包可以包含多个事件。
Packet Type (PT)
指示 RTCP 数据包类型的唯一标识符。WebRTC Agent 不需要支持所有这些类型，并且 Agent 之间的支持能力可以是不同的。下面这些是你可能经常看到的类型：
192 - 完整的帧内请求（FIR）
193 - 否定确认（NACK）
200 - 发送方报告（SR）
201 - 接收方报告（RR）
202 - source Description (SDEC)
203 - Goodbye（BYE）
204 - Application-defined（APP）
205 - 通用 RTP 反馈
206 - 有效负载特定反馈
RTCP报文抓包分析
以NACK为例
NACK
RTCP 帧序列号 416 是一个用于在实时通信中传输控制信息的 RTCP(Real-Time Control Protocol) 帧。
RTCP 帧长度为 72 字节 (576 位),包括帧头和数据部分的长度。RTCP 帧头包含发送者和接收者的源和目标地址，以及传输协议。
通用 RTP 反馈消息是用于报告数据传输错误的 RTP 反馈消息类型。在这种情况下，NACK 消息表明在传输过程中丢失了 8 个帧
RTCP 帧的源端口号为 20309，这是发送者的应用程序端口号。目标端口号为 59037，这是接收者的应用程序端口号。
总的来说，捕获结果表明接收者接收到了一个带有通用 RTP 反馈消息的 RTCP 帧，这表明在传输过程中丢失了 8 个帧。
PID(消息类型标识符) 用于标识传输反馈消息的类型。RTCP Transport Feedback NACK PID:19163 表示一个 NACK(否定确认) 消息被发送，以通知接收方有一定数量的帧丢失。NACK 消息通常由发送方发送，以请求接收方重新传输丢失的帧。
PID:19163 是一个用于传输反馈消息的 PID，它标识了这种消息的类型。在 RTCP 传输中，有许多不同的 PID 用于不同类型的传输反馈消息。
RTCP Transport Feedback NACK PID 包用于指示 RTP 包的丢失或错误，而 RTCP Transport Feedback NACK BLP 包用于指示 RTP 包的源地址或目的地址不正确。
RTCP Transport Feedback NACK BLP: Cx027d (Frames 19164 19166 19167 19168 19169 19170 19173 lost)
Frame 19164 also lost
Frame 19166 also lost
Frame 19167 also lost
Frame 19168 also lost
Frame 19169 also lost
Frame 19170 also lost
Frame 19173 also lost文章来源：https://www.toymoban.com/news/detail-614151.html
https://zhuanlan.zhihu.com/p/350908977文章来源地址https://www.toymoban.com/news/detail-614151.html
到了这里，关于【音视频第21天】RTP、RTCP结合wireshark抓包详解的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
