failed to connect: Operation was cancelled

[janniswarnat]

Hi all,

first of all thank you very much for providing this wonderful Docker image (I am currently using ullaakut/rtspatt:broadcast) :-).

We are trying to transmit an rtsp stream from a camera between two OpenWrt routers that are connected via an OpenConnect VPN connection over LTE. This can lead to all kinds of network disconnection issues of course. It seems that the RTSPATT server handles some network issues just fine with re-connecting when the connection is back. E.g. error messages like this:

default gstrtspconnection.c:961:gst_rtsp_connection_connect_with_response: failed to connect: Could not connect to 192.168.99.201: No route to host

default gstrtspconnection.c:961:gst_rtsp_connection_connect_with_response: failed to connect: Could not connect to 192.168.99.201: Connection refused

When I reboot the router next to the camera though I get the following error message and the RTSPATT server does not successfully re-establish the stream when the router is back to normal:

default gstrtspconnection.c:961:gst_rtsp_connection_connect_with_response: failed to connect: Operation was cancelled

Is there a way to tell RTSPATT to never stop trying to re-connect?

An alternative could be to consider this last error message to be fatal and stop the container. Then I could define an appropriate restart policy in my docker-compose file.

Here is the current docker-compose file for reference:

version: '3.5'
services:
  rtspatt-camera1:
    image: ullaakut/rtspatt:broadcast
    container_name: "rtspatt-camera1"
    ports:
      - "5541:8554"
    environment:
      INPUT: "rtsp://192.168.99.201:5541/ufirststream"
      RTSP_ROUTE: "/ufirststream"
      GST_DEBUG: 3

I am thankful for any clue.

Thanks in advance and best regards

Jannis

[Ullaakut]

Hi @janniswarnat !

Thanks for opening an issue :) It seems to me that unfortunately this issue is due to gst-rtsp-server unfortunately 🤔And I'm not sure where to look when it comes to bugs/issues with gst-rtsp-server.

What we could do in RTSPATT, I guess, would be to launch a loop in a separate thread from the g_main_loop_run that would be in charge of checking whether or not the connection to the source is working as expected, and that loop could restart the server if necessary.

I would consider this a hack though, so if we could avoid it by using a more recent version of gst-rtsp-server or with another simpler solution, that would be great.

Also it's important to note that unfortunately I don't have a lot of time to maintain this project these days (I'm currently in holidays so I'm sorry if I'm not very reactive on GH issues :() so I might not be able to do those modifications for quite a while :/

Let me know if you'd like to try to open a PR on this, I could try to guide you on the right path if you need any help! :)

Thanks again for using RTSPATT and for opening this issue! Have a good day! 🙏

[janniswarnat]

Hi @Ullaakut ,

thanks for your quick answer. We implemented the following workaround that works well for us:

• Monitor the RTSP stream provided by a RTSPATT container with Nagios (using plugin check_real).
• Define a Nagios event handler (shell script) to restart the RTSPATT service via docker-compose in case the RTSP stream is unavailable.

If anybody is interested in the details feel free to contact me :-).

Best regards

Jannis