[Live-devel] RTSP proxy not noticing server restart

[Ross Finlayson]

> I can indeed see this running the proxy server with -V.  It is not the case of a TCP connection being misinterpreted as valid. It is the case of when the proxy server retries an OPTIONS command, it sees the TCP connection has gone away, reconnects and receives a valid response, it doesn't realise this is because the server has restarted.

OK, now I understand what's going on.

The problem here is that the proxy server can't tell that the server has restarted - merely from the fact that it needed to reopen the TCP connection in order to send an "OPTIONS" command.  It's perfectly valid (although admittedly unusual) for a server to close the RTSP (TCP) connection while the RTP (UDP) stream is ongoing.  In this case, the server's client (in this case, the proxy server) would need to reopen the RTSP (TCP) connection in order to send the next RTSP command (in this case, "OPTIONS").  Our code does this just fine.  The problem is that - because this next RTSP command ("OPTIONS") completes without error, the proxy server can't tell that the server has restarted.


>   Perhaps rather than using OPTIONS something that sends a session id should be sent and error responses checked for?

The "OPTIONS" command sent by the proxy server *does* contain a session id (when a session has been established - i.e., when there's at least one front-end client).  Unfortunately, the server (after restarting) didn't see this incoming "OPTIONS" command as being erroneous - because it didn't look at the "Session:" id.

I've now installed a new version (2014.09.22) of the "LIVE555 Streaming Media" code that changes the way in which the RTSP server handles incoming "OPTIONS" commands that contain a "Session:" header.  If the specified session id refers to a session that does not exist, the server now responds with a "Session not found" error.  (If the session id is valid, or is not present at all in the "OPTIONS" request, then the request is handled as normal.)

If you rebuild your 'back-end' server using this new version of the code, then the proxy server will now be able to better handle the case when it restarts.


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20140922/0cbb95bc/attachment.html>