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

[Ross Finlayson]

> It turns out that the sequence of SESSION identifiers is the same each
> time the 'back end' server's RTSP deamon is restarted, presumably
> because dome device unique constant such as serial number or MAC is
> used as random seed for the session identifiers.
> 
> To reproduce the issue:
> - Restart 'back end' server
> - RTSP proxy will reconnect, and reuse the previous SESSION identifier
> for PLAY / PAUSE, assuming the session is still valid
> - 'Back end' server incorrectly accepts this, although the SESSION has
> not been setup

I don’t understand what you’re saying here.  When the proxy server reconnects, it will do so by sending a whole new sequence of “DESCRIBE”, “SETUP”, and “PLAY” commands - i.e., to create a whole new RTSP session.  It is the *back-end server* that selects the RTSP session identifier (in its response to the first “SETUP” command).  If the back-end server happens to select the same session id that it used before, then that shouldn’t affect the proxy server, because by this time the proxy server will have forgotten all about the previous session (that happened to have used the same session id).

Please provide a complete listing of the RTSP protocol exchange (i.e., from running the proxy server with the -V option) that illustrates this alleged problem.


> To detect this issue and recover, I implemented the following:
> Add an additional liveness check to ProxyRTSPClient, which
> periodically queries lastPacketReceptionTime of the rtpSource of each
> subsession to fOurServerMediaSession.fClientMediaSession.
> If lastPacketReceptionTime is older than a certain threshold, the same
> method as already used in a few other places in ProxyRTSPClient is
> used to trigger a full reset, i.e. calling
> continueAfterLivenessCommand with resultCode set to 1.
> This seems to work well, and doesn't add a lot of extra complexity 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, or because it just happened to decide to not stream video for a while).

The way that we (the proxy server) detect that the back end server has died is either by either (1) the RTSP (TCP) connection having died, or (2) the back-end server no longer responding to periodic “OPTIONS” commands.  Both of which we check for.

If the ‘back-end’ server is still responding to the periodic “OPTIONS” commands, then it is still alive, as far as the proxy server is concerned.  (If it’s not, then it’s broken, and needs to be fixed or replaced.  Perhaps you can do so using the money that you’re saving on software :-)


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