[Live-devel] Live555 Proxy Server sometimes does not proxy source after connection loss

[Ross Finlayson]

> The proxy server only creates a whole new RTSP session under certain
> conditions, for example while waiting for an "OPTIONS" liveness reply.
> If the RTSP TCP session is interrupted when there is no pending
> request, the proxy server instead silently reconnects before sending
> the next request and reuses the existing session.

Yes, and this is entirely correct and appropriate.  Note that RTSP ‘sessions’ are independent of RTSP TCP connections.  It is allowable, for example, for a RTSP client to use a separate TCP connection for sending each RTSP command, and/or for a RTSP server to shut down a client’s TCP connection after handling and responding to each RTSP command.  Note from RFC 2326: "Note that a session identifier identifies a RTSP session across transport sessions or connections.”


> This may cause problems, for example in this scenario:
> - Proxy server has an RTSP session open towards the
> 'back-end' server, session identifier 'A'
> - A 2nd client has an RTSP session open towards the 'back-end' server,
> session identifier 'B'
> - Back-end RTSP server restarts
> - Proxy server and the 2nd clients both reconnect to the 'back-end' server
> - The 2nd client connects first and opens a new session, which happens
> to be assigned session identifier 'A'
> - The proxy server reconnects, and keeps using the session identifier ‘A'

This (the server restarting, and reusing the same session id(s) as before) is a bug in the server.  Note again from RFC 2326:
   Session hijacking:
          Since there is no relation between a transport layer
          connection and an RTSP session, it is possible for a malicious
          client to issue requests with random session identifiers which
          would affect unsuspecting clients. The server SHOULD use a
          large, random and non-sequential session identifier to
          minimize the possibility of this kind of attack.

So, please contact the manufacturer of the ‘back end’ server, notifying them of this bug in their server.  (As always, I am willing to work with the manufacturer(s) of network cameras and other RTSP servers to help fix their products, but I’d need to hear from them directly.)


> A log of this scenario is further down in the mail.
> Note: In my case, there is most likely no 2nd client, and the
> 'back-end' server is behaving incorrectly.

Correct.


>>> To detect this issue and recover, I implemented the following:
>>> Add an additional liveness check to ProxyRTSPClient
>>> ...
>>> Is this a reasonable solution?
>> 
>> No - because the 'back end’ server might have decided to stop sending RTP packets for a perfectly legitimate reason (e.g., in response to a “PAUSE” command,
> The condition I use for the additional liveness check is that:
> a) lastPacketReceptionTime is older than a certain threshold
> - and -
> b) fOurServerMediaSession.referenceCount() > 0, which it to my
> understanding is if at least one client is requesting to stream (i.e.
> is in state PLAYING)
>> or because it just happened to decide to not stream video for a while).
> The RTSP proxy does not really use the range parameter, so I didn't
> think that was a concern.

I don’t see how the “range parameter” is relevant.  As I noted earlier, it’s conceivable that the back-end server decides to stop sending RTP packets for a period of time, and I don’t want to reset/reconnect to the back-end server in this case, as long as the periodic “OPTIONS” commands (which, BTW, contain a session id) continue to be handled OK.

The manufacturer of your back-end server needs to fix their product.


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