<div dir="ltr"><div>One idea is to make use of an already existing loopback client at the server side on the created endpoint and if it ever receives EOS, instruct the server to unbind then bind the original RTSP again and spin the client again. keep doing this till you are back in action.<br></div><div><br></div><div>This is okay if you are adding a new purpose for the loopback client, the original purpose was meant to store the past minute or so of the stream.</div><div><br></div><div>Any other ideas?</div><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Best Regards,<br>Eslam Ahmed</div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 12, 2022 at 10:58 AM Eslam Ahmed <<a href="mailto:eslam.ahmed@avidbeam.com">eslam.ahmed@avidbeam.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hello,<div><br></div><div>Consider binding an RTSP stream from an IP camera to a new endpoint on the gst-rtsp-server. The thing is that this new endpoint will be functional for as long as the camera is reachable. But say the camera got disconnected, for a while, the endpoint will cease to work even when you bring back the camera. My question is: How to efficiently detect and remedy this behavior from the server side?</div><div><br></div><div>Any suggestions are welcome and appreciated, Thanks in advance!</div><div><br></div><div><div><div dir="ltr"><div dir="ltr">Best Regards,<br>Eslam Ahmed</div></div></div></div></div>
</blockquote></div>