有这样的RTSP平？ [英] Is there such a RTSP Ping?

问题描述

我目前工作的一个WinForm的应用程序流使用C＃中的RTSP协议的IP摄像头的视频。一切正常。对于应用程序的要求部分包括函数来检查网络摄像机是否在线与否。

I am currently working on a WinForm app to stream videos from IP camera using the RTSP protocol in C#. Everything worked fine. Part of the requirement for the app includes a function to check whether the IP camera is online or not.

所以我用System.Net.NetworkInformation.Ping类来ping IP摄像机做了一个ping功能。说，如果相机的RTSP URL是如下的rtsp：// [摄像机IP] ：554 / Master0-RTSP / 1.0，我只需要提取的 [摄像机IP] 部分，并使用Ping类，看看相机在网上或不能使用的IP。

So I did a ping function using the System.Net.NetworkInformation.Ping class to ping the IP camera. Say if the RTSP url of the camera is as follows rtsp://[CAMERA IP]:554/Master0-RTSP/1.0, I would only need to extract the [CAMERA IP] part and use the Ping class to see if the camera is online or not by using its IP.

最初，它的工作原理，直到一个问题来了，说如果一个人输入IP可能不是预期的IP摄像机（比如一台计算机的IP），如果输入的设备的输入的IP是网络ping功能仍然正常工作。

Initially, it works until an issue came, say if one to enter an IP which may not be the intended IP Camera (say an IP of a computer) the ping function would still work if the entered IP of the entered device is online.

我想寻找的东西像一个RTSP平，但没能找到。希望对此事任何建议或意见。在C＃中的任何例子是极大的赞赏。感谢您的关注。

I tried to search for something like a RTSP ping but could not find one. Was hoping for any advices or opinions on this matter. Any example in C# are greatly appreciated. Thank you for your kind attention.

推荐答案

选项都不可能工作，但该标准规定了正确的方法是通过使用 GET_PARAMETER 。

OPTIONS can possibly work but the standard specifies the correct way is through using theGET_PARAMETER.

RFC2326列出了明确

RFC2326 outlines that clearly

http://www.ietf.org/rfc/rfc2326。 TXT

10.8 GET_PARAMETER

10.8 GET_PARAMETER

的GET_PARAMETER请求检索$为b的参数的值URI中指定$ b演示或流。答复
和响应的内容是留给实现。 GET_PARAMETER无
实体主体可以用于测试客户端或服务器存活（平）。

The GET_PARAMETER request retrieves the value of a parameter of a presentation or stream specified in the URI. The content of the reply and response is left to the implementation. GET_PARAMETER with no entity body may be used to test client or server liveness ("ping").

虽然 GET_PARAMETER 可能无法被服务器没有办法告诉服务器将如何在选项请求，甚至不需要一个会话ID反应的支持。为此它不能保证它会保留现有会话活着。

While GET_PARAMETER may not be supported by the server there is no way to tell how that server will react to the OPTIONS request which does not even require a sessionID. Therefor it cannot be guaranteed it will keep your existing session alive.

这是从阅读有关选项相同RFC 要求

10.1选项

该行为等同于在[H9.2]中描述。一个OPTIONS
请求可以在任何时间发出，例如，如果客户端为约了
尝试非标准请求。

The behavior is equivalent to that described in [H9.2]. An OPTIONS request may be issued at any time, e.g., if the client is about to try a nonstandard request. It does not influence server state.

Example:

例> S：OPTIONS * RTSP / 1.0
的Cseq：1
要求：隐播放
代理请求：gzip压缩的消息

S-> C： RTSP / 1.0 200 OK
的Cseq：1
公开：形容，SETUP，TEARDOWN，播放，暂停


C->S: OPTIONS * RTSP/1.0 CSeq: 1 Require: implicit-play Proxy-Require: gzipped-messages S->C: RTSP/1.0 200 OK CSeq: 1 Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE

请注意，这些都必然虚构功能（人们希望
，我们不会刻意忽略了一个真正有用的功能，只是
，使我们可以在这部分强烈的例子）。

Note that these are necessarily fictional features (one would hope that we would not purposefully overlook a truly useful feature just so that we could have a strong example in this section).

如果不支持GET_PARAMETER那么你会发出与要永葆会话的SessionID一个PLAY请求。

If GET_PARAMETER is not supported then you would issue a PLAY request with the SessionId of the session you want to keep alive.

这即使选项不作为PLAY荣誉会话ID，如果你已经玩不存在不利影响。

This should work even if OPTIONS doesn't as PLAY honors the Session ID and if you are already playing there is no adverse effect.

对于C＃RtspClient看应该工作我的项目@ https://net7mma.codeplex.com/

For the C# RtspClient see my project @ https://net7mma.codeplex.com/

和CodeProject上@ HTTP的文章：//www.codeproject.com/Articles/507218/Managed-Media-Aggregation-using-Rtsp-and-Rtp

And the article on CodeProject @ http://www.codeproject.com/Articles/507218/Managed-Media-Aggregation-using-Rtsp-and-Rtp

这篇关于有这样的RTSP平？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！