>>> 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.
I've attached a patch to this mail which adds a new option [-D <max-inter-packet-gap-time>] to the live555ProxyServer example program. The new functionality is based on the implementation of the same option in openRTSP. When the -D option is used, the proxy server will reset the connection to a 'back end' server if at least one subsession *might* be in state playing, but no data has been received during max-inter-packet-gap-time seconds. Note 1: As explained by Ross in this thread, this option does not make sense for all streams. I use it for IP cameras where the camera should be sending data at all times. Note 2: As discussed in another thread, there’s no good way for the proxy server code to know exactly what subsession(s) are and are not currently streaming. The patch is using the same logic as for PAUSE of substreams in ProxyServerMediaSubsession::closeStreamSource(), which means connection to 'back end'-server might be reset although no client was playing. I hope the patch is useful for some readers of this mailing list.
Proxyserver_check_interPacketGap.patch
Description: Binary data
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
