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
[email protected]
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.
_______________________________________________
live-devel mailing list
[email protected]
http://lists.live555.com/mailman/listinfo/live-devel
