Is there such a RTSP Ping?

Question

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

Answer 1

You can use RTSPClientSharp and do something like this:

public static async Task TestRTSPConnection(string rtspAddress, string user, string password)
{
        var serverUri = new Uri(rtspAddress);
        var credentials = new NetworkCredential(user, password);

        var connectionParameters = new ConnectionParameters(serverUri, credentials);
        var cancellationTokenSource = new CancellationTokenSource();

        var connectTask = ConnectAsync(connectionParameters, cancellationTokenSource.Token);

        if (await Task.WhenAny(connectTask, Task.Delay(15000 /*timeout*/)) == connectTask)
        {
            if (!connectTask.Result)
            {
                logger.Warn("Connection refused - check username and password");
            }

            logger.Info("Connection test completed");
        }
        else 
        {
            logger.Warn("Connection timed out - check username and password");
        }
    }

    private static async Task<bool> ConnectAsync(ConnectionParameters connectionParameters, CancellationToken token)
    {
        try
        {
            using (var rtspClient = new RtspClient(connectionParameters))
            {
                rtspClient.FrameReceived +=
                    (sender, frame) => logger.Info($"New frame {frame.Timestamp}: {frame.GetType().Name}");

                while (true)
                {
                    logger.Info("Connecting...");

                    try
                    {
                        await rtspClient.ConnectAsync(token);
                    }
                    catch (OperationCanceledException)
                    {
                        logger.Info("Finishing test before connection could be established. Check credentials");
                        return false;
                    }
                    catch (RtspClientException e)
                    {
                        logger.Error($"{e.Message}: {e.InnerException?.Message}");
                        return false;
                    }

                    logger.Info("Connected - camera is online");
                    return true;
                }
            }
        }
        catch (OperationCanceledException)
        {
            return false;
        }
    }

It works for me pretty well if you just care about pinging and if the camera is online or not. Also timeout happens when credentials are incorrect. You get direct failure if port is not exposed or connection is refused.

Answer 2

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

RFC2326 outlines that clearly

http://www.ietf.org/rfc/rfc2326.txt

10.8 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").

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.

This is clear from reading the same RFC about the OPTIONS request

10.1 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:

 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).

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

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.

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

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

Answer 3

Instead of ICMP ping, you might want to keep a helper RTSP session without video/audio RTP streams, checking good standing of socket connection and sending OPTIONS or DESCRIBE command on a regular basis, e.g. once a minute, in order to see if the device is responsive.

Some suggest using GET_PARAMETER instead of options, however this is inferior method. OPTIONS is mandatory, GET_PARAMETER is not. Both serve different purpose. Both have small server side execution expense. OPTIONS is clearly the better of the two.

Some servers may not support setting stream parameters and thus not support GET_PARAMETER and SET_PARAMETER.

Answer 4

Regarding RTSP in C# see this thread Using RTMP or RTSP protocol in C#

Regarding Ping ... you can implement is as DESCRIBE operation ... but pay attention do not make it too frequently, the device should be affected.

http://www.ietf.org/rfc/rfc2326.txt