SRS 的 RTSP 拉流用 UDP 传输报 Unsupported Transport 怎么排查-迪斯科星球

SRS 的 RTSP 拉流用 UDP 传输报 Unsupported Transport 怎么排查

【免费下载链接】srsSRS is a simple, high-performance, AI-driven real-time media server supporting RTMP, WebRTC, HLS, HTTP-FLV, HTTP-TS, SRT, MPEG-DASH, and GB28181, with codec support for H.264, H.265, AV1, VP9, AAC, Opus, and G.711.项目地址: https://gitcode.com/GitHub_Trending/sr/srs

用 ffplay 等播放器拉取 SRS 的 RTSP 流时，如果播放器在 SETUP 阶段协商使用 UDP 作为媒体传输，客户端会收到method SETUP failed: 461 Unsupported Transport，随后报Protocol not supported。这不是网络或配置故障：SRS 7.0.47+ 的 RTSP 服务器只实现 TCP/interleaved 媒体传输，UDP transport 被明确拒绝，且文档说明目前没有支持 UDP 的计划。这篇排查文章的目标是确认错误来源，然后把播放器切到 TCP 传输完成拉流，并给出验证方式。

错误长什么样：客户端和服务端各看到什么

文档给出的 UDP 拉流失败现场（以下为文档示例输出）：

ffplay -rtsp_transport udp -i rtsp://localhost:8554/live/livestream [rtsp @ 0x7fbc99a14880] method SETUP failed: 461 Unsupported Transport rtsp://localhost:8554/live/livestream: Protocol not supported [2025-07-05 21:30:52.738][WARN][14916][7d7gf623][35] RTSP: setup failed: code=2057 (RtspTransportNotSupported) : UDP transport not supported, only TCP/interleaved mode is supported

两行信息分别来自两端：

客户端的461 Unsupported Transport是 RTSP 信令层面的应答，说明失败发生在 SETUP，而不是信令（DESCRIBE/SETUP/PLAY）都走 TCP 的 8554 端口连接本身有问题。
服务端的RtspTransportNotSupported日志是 SRS 主动拒绝的明确标记。源码中 SrsRtspConnection::do_setup 会检查 SETUP 请求的 transport 字段，只要不是TCP就直接返回该错误：

// Only support TCP transport, reject UDP if (req->transport_->lower_transport_ != "TCP") { return srs_error_new(ERROR_RTSP_TRANSPORT_NOT_SUPPORTED, "UDP transport not supported, only TCP/interleaved mode is supported"); }

错误号核对时有一个版本差异要注意：上面的文档示例日志里是code=2057，而当前源码树 srs_kernel_error.hpp 中ERROR_RTSP_TRANSPORT_NOT_SUPPORTED的编号是5038。两个来源不一致，说明错误号随版本会变，排查时按错误名RtspTransportNotSupported匹配最稳妥。

为什么 SRS 不支持 UDP：RTSP 协议由信令和媒体传输两部分组成，媒体可以走 TCP 或 UDP，但 UDP 传输需要 SRS 为每个会话分配端口。文档原话是 “UDP transport is not supported because it requires port allocation”，并且 “There are currently no plans to support UDP transport. In practice, UDP is rarely used; the vast majority of RTSP traffic uses TCP.”（见 RTSP 文档 Port 一节）。所以这不是待修复的 bug，而是设计边界。

先确认环境：RTSP 服务是否按文档启用

如果你还没在本地完整跑通过 RTSP 拉流，先按 RTSP 文档的最短路径把环境搭起来，确认报错确实发生在 UDP 传输这一环，而不是别处。以下版本要求7.0.47+，且 RTSP 默认关闭，必须在编译时显式开启：

cd srs/trunk && ./configure --rtsp=on && make ./objs/srs -c conf/rtsp.conf

关键配置在 conf/rtsp.conf：

rtsp_server { enabled on; listen 8554; } vhost __defaultVhost__ { rtsp { enabled on; rtmp_to_rtsp on; } }

端口说明：RTSP 信令默认端口是554，但某些系统上监听 554 需要 root 权限，所以 SRS 改用8554。

拉流前必须先有流在播。RTSP 拉流依赖已有流来确定音频编码，不支持 play-then-publish，所以先用 RTMP 推流：

ffmpeg -re -i doc/source.flv -c copy -f flv rtmp://localhost/live/livestream

这一步也解释了文档中的一个细节：SRS 不支持直接推 RTSP 进 SRS（RTSP 推流不是推荐用法），RTSP 拉流的数据源头是 RTMP 流经rtmp_to_rtsp转换而来（FAQ RTSP 小节）。

解决：把播放器切到 TCP 传输

确认服务端已按上述配置运行且流已推入后，拉流命令只改传输参数，从 UDP 换回 TCP：

ffplay -rtsp_transport tcp -i rtsp://localhost:8554/live/livestream

之前用-rtsp_transport udp时 SETUP 失败返回461 Unsupported Transport的请求，换-rtsp_transport tcp后走文档给出的正常拉流路径。TCP 传输复用信令阶段建立的连接，媒体在同一个连接上以 interleaved 方式传输（每个 RTP/RTCP 包带 4 字节头：首字节0x24、1 字节 channel、2 字节长度，见 RTSP 文档 RTP 一节对应的 RFC2326 10.12 节），不需要额外开放端口，这也是 SRS 选择只做 TCP 的原因。

验证拉流链路是否恢复

两级验证：

业务级：上面的ffplay -rtsp_transport tcp命令能正常出画面/出音频，说明 TCP interleaved 传输已生效，此前的461 Unsupported Transport不再出现。
回归测试级：文档提供了对应的 RTSP 拉流回归用例，前提是 SRS 已启动：

cd srs/trunk/3rdparty/srs-bench go test ./srs -mod=vendor -v -count=1 -run=TestRtmpPublish_RtspPlay

该用例覆盖 RTMP 推流 + RTSP 拉流的完整链路，通过即可确认服务端 RTSP 播放能力正常。

企业官网建设流程全解析