[Live-devel] Server getting confused with RTCP message before PLAY command (when using RTP over TCP)

[Matt Schuckmann]

This is sort of related to my last message, mostly because I found the 2 
problems at the same time and around the same place in the code.

I'm testing RTP over TCP (client and server are both based on LiveMedia) 
and occasionally (perhaps 50% of the time) the server is responding to 
the PLAY command with a "400 Bad Request " response.  It looks like what 
is a happening is just before the RTSPClient object sends the PLAY 
command a RTCP message is being sent from the client (probably from one 
of the RTCP objects that got created as a result of the earlier SETUP 
command.
Anyway the RTSPServer::RTSPClientSession::incomingRequestHandler() 
method is getting very confused by the RTCP message that precedes the 
PLAY command (in fact it never sees the PLAY command because it stops 
parsing when it sees $\001).

I would assume that the 
RTSPServer::RTSPClientSession::incomingRequestHandler() code should 
watch for RTCP messages and properly ignore them or forward them on to 
the session or sub session RTCP handler objects (I'm really not clear on 
how it could forward the data but maybe it's possible).

Or perhaps the client code shouldn't be allowed to send RTCP messages 
until after the PLAY command has been issued.

Any suggestions on what should be done here?

Thanks
Matt S.

PS. I should probably note my code isn't like openRTSP in that it 
doesn't do DESCRIBE, SETUP, and PLAY all at once I do DESCRIBE followed 
by SETUP, then I let the TaskScheduler run while I let my UI do some 
work, then I do a couple of SET_PARAMETER commands, then some more UI 
work followed by the PLAY command.
I might be able to change my code to do everything at once, but I figure 
somebody isn't working according to the standard and it would be nice if 
a general purpose server like liveMedia could handle this type of sequence.