RTSP 摄像机流诊断:从描述到回放的系统故障排除工作流程
RTSP 摄像机问题通常遵循某种模式:连接层、控制层或媒体层。此诊断工作流程显示要收集哪些证据、哪个协议阶段发生故障，以及如何读取 SDP、RTP 和 RTCP 以查明确切的故障。
RTSP 摄像机故障不需要猜测。协议是分层的：连接（TCP/TLS）、控制（DESCRIBE/SETUP/PLAY）和媒体（RTP/RTCP）。当流中断时，其中一层就会出现问题。你的工作就是找到哪一个。
三层模型
每个 RTSP 问题都属于三个类别之一。在深入研究特定错误代码之前，请从这里开始：
第 1 层 — 连接： 客户端能否到达摄像机？ TCP 握手、TLS 协商、端口过滤、VPN 路由。如果“telnetcamera-ip 554”无法连接，则其他一切都不重要。
第 2 层 — 控制： 连接有效，但 RTSP 命令失败。 DESCRIBE 返回 400/404/401。 SETUP 返回 461。PLAY 返回 453。控制平面存在协议级问题：URL 格式、身份验证、传输协商、会话管理。
第 3 层 — 媒体： 控制工作正常，但视频/音频损坏。 RTP 数据包到达但无法解码。时间戳漂移。帧已损坏。 RTCP 报告丢失。媒体平面存在有效负载、编解码器或网络质量问题。
快速分诊表
| Symptom | 可能层 | 首先检查 |
|---|---|---|
| “连接被拒绝” | 第 1 层 | 554端口可达吗？防火墙拦截？ |
| DESCRIBE 上的 400 错误请求 | 第2层 | RTSP URL 格式、编码、代理标头 |
| 401 未经授权 | 第2层 | 摘要身份验证参数、用户名/密码 |
| 461 不支持的运输 | 第2层 | UDP 与 TCP 传输、SETUP 标头 |
| 描述正常，设置正常，无视频 | 第3层 | RTP 负载类型、编解码器映射 |
| 视频播放，然后冻结 | 第3层 | 丢包、保活、会话超时 |
| 音频和视频渐行渐远 | 第3层 | RTP时间戳、时钟速率不匹配 |
您必须收集的证据
在诊断任何 RTSP 问题之前，请捕获以下五个证据：
- 完整的 DESCRIBE 响应 — SDP 告诉您存在哪些轨道、正在使用哪些编解码器以及分配了哪些有效负载类型。
- SETUP 请求和响应 — 传输标头显示 UDP 与 TCP、客户端端口和交错通道 ID。
- PLAY 响应 — 确认会话处于活动状态并且 RTP 正在流动。
- RTP 数据包样本 — 有效负载类型字节、序列号、时间戳、SSRC。
- RTCP 发送器/接收器报告 — 数据包丢失计数、抖动、到达间隔延迟。
没有这些，你就只能猜测了。对于他们来说，失败通常是显而易见的。
通过错误进行深入指导
- RTSP 400 错误请求：DESCRIBE 失败，URL 格式错误
- RTSP 461 不支持的传输：设置失败
- H.264 FU-A 分段：RTP 丢包和 NAL 重组
- RTP 动态负载类型不匹配：SDP 和编解码器映射
- RTSP UDP RTP 阻止：防火墙、NAT 和 VPN
- RTP 时间戳漂移：时钟速率和音频/视频同步
- RTSP 会话超时和 Keepalive
- RTCP 发送方报告：抖动和丢包分析
何时升级
如果所有三层均检查正常（TCP 连接、RTSP 命令成功、RTP 数据包以正确的负载类型和稳定的时间戳到达），但视频看起来仍然错误，则问题可能出在解码器或应用程序层，而不是 RTSP 传输。此时，捕获一个简短的 PCAP，导出几秒的 RTP，并将其交给解码器团队。