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/
_______________________________________________
live-devel mailing list
[email protected]
http://lists.live555.com/mailman/listinfo/live-devel
