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

Matt Schuckmann matt at schuckmannacres.com
Mon Feb 9 14:40:15 PST 2009


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.



More information about the live-devel mailing list