[Live-devel] Status of Live555 RTPS Client and Server using Stream over TCP

[Matt Schuckmann]

Ross Finlayson wrote:
>> After doing a bit more digging in the code and on the web I've 
>> discovered that the problem of not receiving RTSP commands after the 
>> play command when using RTP-over-TCP streaming is a known problem 
>> (although it is usually associated with the keep-a-live feature 
>> (cough hack
>
> The standard way for clients (using either RTP/UDP *or* RTP/TCP) to 
> indicate their 'liveness' to the server is be sending back RTCP "RR" 
> packets (which are a required part of the RTP/RTCP standard).  Our 
> (server and client) supports this OK, even when doing RTP/RTCP-over-TCP.
>
Understand and I agree that the client sending back the RR packets is 
the right way for a server to know that a client is still there. 
Remember I want the client/server to be responsive to RTSP commands when 
doing RTP over TCP so the client can send SET_PARAMETER commands to 
control a live camera while it is streaming.

> I'm sorry, but once you've made modifications to the supplied code I 
> won't (in general) be able to help you.  However, if you want to 
> experiment with RTP/RTCP-over-TCP streaming, I suggest that you start 
> using the (original, unmodified) "live555MediaServer" (or 
> "testOnDemandRTSPServer" as your server, and "openRTSP -t" as your 
> client.

I understand that you can't help me once I've made changes to the 
supplied code. I'd like to be able to submit any changes I make back to 
the library if your willing to accept them (and I can find the time to 
produce a good patch, etc) and along those lines one of my questions had 
to do with a direction that you were thinking of going for fixing the 
issue of RTSP commands not working once the PLAY command sent for RTP 
over TCP streaming.

I did a good amount of thinking about the problem over the weekend and 
it seems to me that the easiest fix would be to make both the client 
server code be able to work with non-persistent TCP-IP connections for 
the RTSP commands (if I remember right both client and server rely on a 
persistent TCP-IP connection right now).

This would allow the client to continue to send and receive RTSP 
commands after the initial TCP-IP socket had been hijacked for the RTP 
over TCP streaming when the play command is sent.

Does this make sense? I might not be being clear enough.

Matt S.