使用 RTSP/UDP,服务器如何知道向何处发送回复?

发布于 2024-11-02 15:33:22 字数 132 浏览 0 评论 0原文

尽管我还没有看到支持 RTSP 的播放器使用 UDP 作为 RTSP 控制通道,但 RFC2326 允许使用 UDP。但是,它没有指定客户端应如何告诉服务器将 RTSP 回复发送到何处。是否有任何既定的约定,或者我必须制定一个约定?

Although I have yet to see an RTSP-capable player that uses UDP for the RTSP control channel, RFC2326 allows for UDP to be used. However it does not specify how a client should tell the server where to send the RTSP replies. Is there any established convention for this, or am i going to have to make one up?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

━╋う一瞬間旳綻放 2024-11-09 15:33:22

这不是您想听到的答案,但您真的需要它吗?就像你说的,我没有看到任何玩家或服务器。来自 Martin Stiemerling 的网站 ,RTSP 2 草案的作者之一:

本备忘录描述了 RTSP 在基于可靠连接的传输层协议(例如 TCP)上的使用。 RTSP 可以通过不可靠的无连接传输协议(例如 UDP)来实现。虽然 RTSP 中没有任何内容排除这一点,但需要将此问题领域的附加定义作为核心规范的扩展来处理。

RTSP 通过 UDP 运行的机制未包含在此规范中。因为它们在 [RFC2326] 中的定义不明确,并且在有限的问题空间中为了获得微小的收益而在本备忘录的规模和复杂性上进行权衡被认为是不合理的。

仅供参考,最新版本的 RTSP 2 草案可在此处。

Not the answer you want to hear but do you really need it? Like you said I haven't seen any players or servers out there. From Martin Stiemerling's site, one of the authors of the RTSP 2 draft:

This memorandum describes the use of RTSP over a reliable connection based transport level protocol such as TCP. RTSP may be implemented over an unreliable connectionless transport protocol such as UDP. While nothing in RTSP precludes this, additional definition of this problem area needs to be handled as an extension to the core specification.

The mechanisms of RTSP's operation over UDP were left out of this spec. because they were poorly defined in [RFC2326] and the tradeoff in size and complexity of this memorandum for a small gain in a limited problem space was not deemed justifiable.

FYI, latest version of the RTSP 2 draft is available here.

﹎☆浅夏丿初晴 2024-11-09 15:33:22

嗯,有一个默认端口:554。但是,如果您不能使用它,那么您将不得不制定自己的约定。

如果您深入研究这个问题,您还会遇到 NAT 遍历问题,这意味着 554 可能会被 NAT 转换为任何其他端口号。这是一个不同问题,本 RFC 未涵盖,但它是真实存在的,如果您在 ipv4 上运行,您将需要一个解决方案。

Well, there is a default port: 554. But, if you can't use it, then yes, you are going to have to make your own convention.

If you dig deeper in this problem, you'll hit the NAT traversal issue too, which implies that 554 may be translated into any other port number by NATs. This is a different issue not covered by this RFC, but it is real and you will need a solution if you operate on ipv4.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文