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

[Erik Montnemery]

>> 1) The proxyserver reconnects to the source, but no data frames are
>> forwarded to the clients.
>
> If no data are forwarded to the (‘front-end’) clients, then that must mean that the ‘back-end’ server was not sending any data to the proxy server.  If the ‘back-end’ server appears responsive in spite of this (i.e., the RTSP connection remains open, and the server continues responding to “OPTIONS” requests from the proxy server), then it must be broken in some way…

I am now able to reproduce this issue with additional debug prints as
well as tcpdump of traffic between proxy and 'back-end' device.
You were absolutely right, Ross, the ‘back-end' server is not sending
and data to the proxy server.

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
Note: This would happen also without incorrect behavior of the 'back
end' server if another client has already connected and been assigned
the previous SESSION identifier.

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? Would you accept a patch implementing this?