[Live-devel] When streaming RTP over TCP, Live555 Proxy Server sometimes does not reconnect to 'back end' device

Ross Finlayson finlayson at live555.com
Sun Feb 26 21:19:53 PST 2017


Erik,

I’m not going to be applying this patch as is, because:
	1/ You didn’t describe the specific bug that it purports to solve, and 
	2/ The ‘fix’ for the bug (whatever it is) seems to be overkill.

In particular, I don’t understand why your redefined “handleAlternativeRequestByte1()” function (which applies to the communication between the proxy server and a ‘back-end’ server, when streaming RTP/RTCP-over-TCP) needs to close all client (i.e., front-end) connections for this stream.  The "handleAlternativeRequestByte1()” function handles responses to RTSP commands (sent from the proxy server to the ‘back-end’ server), or signals an error if the TCP connection fails while the RTSP command is in progress.  In any case, if a ‘back-end’ RTSP command fails, then our proxy server code will already handle an ‘error’ response code to the command, and will already reset the ‘back-end’ connection, and (via “scheduleReset()”/“doReset()”) close all ‘front-end’ client connections.  So there doesn’t seem to be a need to do this again.

Also, your redefined "handleAlternativeRequestByte1()” treats the special 0xFE byte the same way as the special 0xFF byte.  This seems wrong, because 0xFE indicates that an error did *not* occur, but simply that ‘interleaved’ RTP/RTCP handling over the TCP connection is no longer occurring (so that, from now on, only normal RTSP request/response handling is being done over the TCP connection).

In summary, you’re going to have to describe the problem in specific detail before I can apply a ‘fix’.


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




More information about the live-devel mailing list