Hi Ross,
Managed to isolate the problem further, the RTSP Server session timeout
triggers the RTCPInstance destructor (since the client has already
disconnected).
As soon as a RTCPInstance destructor has executed, the next RTSP client request
is handled by the RTSP handler instead of the RTCP handler.
It does not make a difference where the client's connect from, whether from the
same box as the server, other boxes, Windows and Linux clients.
The steps to replicate the problem have now been updated to:
1) Set the DynamicRTSPServer timeout to something short like 15 seconds.
2) a) add printf in ~RTCPInstance() (So you can see that the destructor has
executed)
b) add print f in RTSP request handler. (So you can see that the incorrect
handler has been called)
c) Compile with DEBUG_RR (so you can see when the correct RTCP handler is
called) and without DEBUG (which clogs the view)
3) Run the server
4) Connect an openRtsp client over tcp
5) Wait for a RTCP handler output (Everything is as should be)
5) Kill the client
6) Wait for the ~RTCPInstance printf on the server console (this will happen 15
seconds after the client was disconnected)
7) Connect a second openRTSP client (irrespective if from the same or from
another machine)
8) See the RTSP handler output appear instead of the RTCP output.
I've traced the call from RTCPInstance::~RTCPInstance() to
fRTCPInterface.stopNetworkReading() to
envir().taskScheduler().turnOffBackgroundReadHandling(fGS->socketNum())
but I can't see anything wrong, I've added a whole wad of debug info but the
flow of events always seems to be correct.
I've compared the addresses of the handler pointer that is passed through to
turnOnBackgroundReadHandling for each RTCPInstance and they are the same so I
can't understand how the other handler is being called.
Also, the only platform-dependent code is the FD_CLR macro in
turnOffBackgroundReadHandling? But this code also gets used by the other socket
connections?
Maybe now that it's narrowed down to a few lines of code, it will make sense to
you?
Please let me know if you can replicate it or if you need any other info...
Regards,
Ralf
--
This message is subject to the CSIR's copyright terms and conditions, e-mail
legal notice, and implemented Open Document Format (ODF) standard.
The full disclaimer details can be found at
http://www.csir.co.za/disclaimer.html.
This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean. MailScanner thanks Transtec Computers for their
support.
_______________________________________________
live-devel mailing list
[email protected]
http://lists.live555.com/mailman/listinfo/live-devel
