RTSP 2.0 采用和实施
新的 RTSP 2.0 草案 规范尝试解决大多数问题最初的 RTSP 规范 (RFC 2326) 中遇到的互操作性问题。它还提供了解决最可怕的问题 - NAT 穿越的方法。这激励我们将堆栈升级到这个新的规范。
我想知道目前有多少供应商和实现遵守新的 RTSP 2.0 草案。是否有支持此新规范的流媒体服务器？真的值得花费精力进行升级吗？
提前致谢。
The new RTSP 2.0 draft spec tries to solve most of the inter-operaility issues that were encountered in the initial RTSP spec (RFC 2326). Also it provide for means to solve the most dreaded issue - NAT traversal. This has been an incentive for us to upgrade our stack to this newer spec.
I would like to know how many vendors and implementations currently adhere to the new RTSP 2.0 draft. Are there any streaming servers that support this newer spec? Is it really worth the effort to make the upgrade?
Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
看起来 GStreamer 是第一个实现 RTSP 2.0（客户端和服务器）的多媒体框架之一
来源：Twitter< /a>
It looks like GStreamer is one of the first multimedia framework implementing RTSP 2.0 (both client and server)
source: Twitter
在草稿中我看到@ https://datatracker.ietf。 org/doc/html/draft-ietf-mmusic-rfc2326bis-27
看起来只是在某些中使用了一些附加值headers 和其他 headers 有更具体的信息。
其余的更改涉及如何使用这些标头来缩短到服务器所需的往返行程。
我有我自己的服务器实现@ http://net7mma.codeplex.com/
如果你能描述一下你的情况希望从草案中获得支持我将更新我的 RtspServer 以支持它。
您还可以在问题跟踪器中创建一个线程来进行监控。
如果您只是想测试一些东西，那么欢迎您下载代码并尝试添加对新规范的支持。
看起来几乎所有的事情都可以在 RtspMessage 类中处理，显然管道的东西需要添加到 RtspServer 中适当的处理程序中。
与它已经在做的事情相比，似乎没有什么复杂的！
如果您需要帮助，请告诉我！
In the draft I see @ https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-rfc2326bis-27
It only seems like some additional values are used in some of the headers and other headers have more specific information.
The rest of the changes involve how those headers can be used to shorten the required round trips to the server.
I have my own server implementation @ http://net7mma.codeplex.com/
If you can describe what you wish to support from the draft I will update my RtspServer to have support for it.
You can also make a Thread in the Issue Tracker there to monitor.
If you just wanted to test a few things out you are more then welcome to download the code and attempt to add support for the new spec.
It seems mostly all of it could be handled in just the RtspMessage classes where obviously the Pipelining stuff would need to be added to the appropriate handlers in the RtspServer.
Nothing seems to complex compared to what it is already doing!
If you need some help let me know!