RTSP 超时:何时尝试 TCP 交错、UDP 单播或修复网络路径

“RTSP 超时”是最广泛的相机故障排除短语之一。这可能意味着与 RTSP 服务器的 TCP 连接超时。这可能意味着“DESCRIBE”返回缓慢。这可能意味着“PLAY”成功，但 RTP 数据包从未到达。这可能意味着 UDP 端口被阻止、NAT 错误地重写了某些内容，或者防火墙允许控制流量但不允许控制媒体流量。

这句话含糊不清。证据不一定是。

将控制超时与媒体超时分开

RTSP 控制通常通过 TCP 进行。 RTP 媒体可以通过 UDP 流动，也可以通过 RTSP TCP 连接交织。第一个诊断分割是：

• RTSP TCP 连接是否打开？
• 服务器是否回答“选项”？
• DESCRIBE返回了SDP吗？
• ‘SETUP’成功了吗？
• ‘PLAY’成功了吗？
• RTP 在“PLAY”之后到达吗？

如果TCP连接本身失败，请检查主机、端口、路由、防火墙、VPN、RTSP服务是否开启。如果RTSP控制成功但RTP未到达，请检查传输协商和媒体路径。

为什么 UDP 经常失败而 TCP 可以工作

即使 RTSP 控制工作，UDP RTP 也可能失败。客户端和相机在“SETUP”期间协商端口。防火墙、NAT 设备、VLAN 策略和云路由可能会阻塞媒体路径。摄像机可能会将 RTP 发送到客户端无法接收的端口。安全网关可能允许 TCP 554 但丢弃 UDP。

症状：

• 描述成功
• SETUP 成功
• PLAY成功
• 没有 RTP 数据包到达
• 播放器最终报告超时或黑屏

在这种情况下，切换到 TCP 交错是一个有用的测试。它在 RTSP TCP 连接内发送 RTP。如果 TCP 交错工作而 UDP 不工作，则编解码器可能不是第一个嫌疑对象。网络媒体路径是。

TCP 交错是一种测试，并不总是最终答案

RTSP over TCP 交错可以更轻松地跨越防火墙和 NAT，因为它将控制和媒体保持在同一连接上。它还会增加延迟并改变性能行为。对于现场诊断，最好将其视为比较点。

比较：

• UDP 单播 RTP：媒体是否到达？
• TCP 交错 RTP：媒体是否到达？
• RTCP：发件人报告可见吗？
• 数据包丢失：UDP 是否显示序列间隙？
• 延迟：TCP 在带宽压力下会造成停顿吗？

如果部署需要 UDP，则 TCP 成功并不能完全验证站点。它标识需要工作的网络边界。

连接被拒绝与超时不同

“连接被拒绝”通常是指主机主动拒绝了TCP连接。常见原因：

• RTSP 服务已禁用
• 错误的端口
• 相机固件不公开 RTSP
• NVR端口与摄像机端口不同
• 防火墙拒绝而不是丢弃

超时意味着在客户端放弃之前没有得到答复。常见原因：

• 路由问题
• 防火墙丢弃
• 网络不可达
• 公共端口映射错误
• 相机离线
• VPN路径问题

不要将它们折叠到同一个支持说明中。拒绝和超时指向不同的所有者。

超时报告中要捕获的内容

有用的 RTSP 超时报告应包括：

• 目标主机和端口
• TCP是否连接
• 最后发送的 RTSP 方法
• 响应状态（如果有）
• SDP是否返回
• 选定的传输标头
• 协商的客户端/服务器端口
• RTP是否到达
• RTCP是否到达
• TCP 交错比较
• UDP比较

这是网络工程师需要的证据。 “超时”是不够的。

RTSP Inspector 适合什么地方

RTSP Inspector 通过在一个诊断流程中保持 RTSP 控制、传输协商、RTP 交付、RTCP 证据和编解码器就绪状态来提供帮助。它并不是试图成为隐藏区别的玩家。

对于 RTSP 超时搜索，最强的输出是简短的判决：

• SDP前控制超时
• 成功“PLAY”后媒体超时
• UDP 被阻止，但 TCP 交错工作
• RTSP 端口上的 TCP 被拒绝
• RTP 已交付，但编解码器未准备好解码

每个判决都有不同的修正。搜索关键字可能是“RTSP 超时”，但真正的答案位于控制和媒体之间的边界。