[Live-devel] Making RTSP commands work when streaming RTP over TCP

[Matt Schuckmann]

Matt Schuckmann wrote:
> I need to make RTSP commands work when streaming RTP over TCP because 
> I need to be able to use the SET_PARAMETER and GET_PARAMETER commands 
> to control my live camera during the session.
>
> The way I thought I understood the problem with the current 
> implementation is that once the PLAY command is issued the TCP 
> connection is hijacked to stream the RTP data and the server and the 
> client no longer have a communication channel, does that sound right?
>
>
> My initial thoughts on how to fix this was to change the RTSPServer 
> class to support non-persistent connections for the RTSP commands and 
> accept multiple connections for each RTSP session.
> I'd then modify the client to open another TCP connection to the 
> server once the initial connection is hijacked for streaming.
> So far modifying the server to accept multiple connections per session 
> (persistent or non-persistent) was pretty easy (took me about a day) 
> and I'm moving on to the client side which seems a little more tricky.
> Looking at the RTSPClient code it looks like the simplest thing to do 
> might be to add some sort of connected boolean that the send() method 
> could use to determine a new TCP connection needs to be established. 
> Then the PlayMediaSession() and PlayMediaSubSession() could clear this 
> flag if we are streaming over TCP so that the next command that called 
> send() would open a new connection. The thing I'm not completely sure 
> about is how to make sure the original connection is properly cleaned 
> up when the session is torn down, I don't fully understand if the 
> RTPSource and RTCPSource objects will clean it up or if the RTSPClient 
> client needs to keep track and clean it up.
>
> Does this sound like a reasonable approach to fixing RTSP support when 
> streaming RTP over TCP? or had you intended something else or does the 
> standard for RTSP and RTP over TCP specify something else (where is 
> the standard).
>
> I am actively working on this and will submit anything I do back to 
> the Live555 project so any guidance would be very helpful.
>
> Thanks
> Matt S.
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>

Ok the more I look at this (and the longer I don't get any response) the 
more I wonder if I'm going at this the wrong way.
I'm starting think that the problem is even more insidious than just 
RTSP replys don't get recognized by the client. I think the current 
implementation prevents multiple streams in the same session from being 
received using RTP over TCP, I think I experienced this the first time I 
tried it. Does this sound correct?

Is the problem that the RTPSource that is created for the first stream 
now owns the TCP socket and it has no way to forward data that's not for 
it on to the other interested parties (other RTPSources and the 
RTSPClient)?

Thanks,
Matt S.