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

[Matt Schuckmann]

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) and not with usages like issuing PAUSE, SET_PARAMETER,  and 
TEARDOWN commands after starting playing. I had intended to use 
RTP-over-TCP as a fall back in situations where UDP won't work (for the 
usual reasons)
Ross are there any plans or thoughts on how to fix this? I may have time 
to work on making this work in the near future.

I also discovered that the RTSPclient does indeed establish 1 and only 1 
TCP connection per session, regardless if it's TCP or UDP streaming. 
This is a bit surprising to me considering the connectionless aspects of 
RTSP. Furthermore with respect to RTP-over-TCP it seems it would 
virtually eliminate and greatly simplify the whole problem (I'm facing) 
if the client simply opened a new connection to the server for each RTSP 
command (or at least created a new one after the original had been 
subsumed for the purpose of streaming rtp over tcp).
Comments and discussion are welcome.

I'm still working on figuring out problem 1 from my original post.

Thanks
Matt S.


Matt Schuckmann wrote:
> Ok I've got a little more information.
> With respect to problem #2 I've discovered that the server is not 
> receiving or responding to any RTSP commands once the play command has 
> been issued when streaming over tcp. In particular I've tested the 
> TEARDOWN and SET_PARAMETER commands both of which the server never 
> receives when streaming over tcp.
>
> I haven't gotten far enough into the server code to figure out how 
> this is supposed to work or even if it is supposed to work?
>
> One question I have is when streaming over TCP does the client use the 
> same TCP socket connection it's streaming over to send and receive 
> further RTSP commands and responses or does it open up new connections 
> in the same way a it would if streaming over UDP?
> It seems like the later would work and be easer to implement but I'm 
> getting the feeling it's the former.
>
> Thanks,
> Matt S.
>
>
> Matt Schuckmann wrote:
>> I know this is sort of a loaded question probably without a clear 
>> answer but here goes.
>>
>> I was wondering if there are any known issues with using the 
>> StreamOverTCP option of the RTSPClient::SetupMediaSession() when both 
>> the client application and the server application are based on the 
>> Dec 4  2008 release of Live555.
>> I ask this because I'm seeing two problems when I try to use this 
>> feature.
>>
>> 1.  I've created my own RTP profile for an experimental meta data 
>> stream and I've created the necessary classes to stream and receive 
>> this stream along with my H264 video stream and it works create when 
>> I do standard UDP RTP. However, as soon as I turn on the 
>> StreamOverTCP the client starts issuing all this "Discarding 
>> interleaved RTP or RTCP packet" messages and my application never 
>> gets any of the data. If I don't stream the experimental meta data 
>> stream the video streams appears to come through fine. Is there 
>> anything I need to do with my custom meta data source or sink.
>> On the server side the MetaData stream source is derived from 
>> FramedSource, the Media subsession is derived from 
>> OnDemandServerMediaSubsession and it creates a SimpleRTPSink for the 
>> RTPSink.
>> On the client the meta data stream sink is derived from MediaSink and 
>> I've allowed the MediaSession object to create a SimpleRTPSource for 
>> this stream.
>>
>> 2. I've modifed the RTSPServer to accept, handle, and reply to the 
>> SET_PARAMETER request (a patch is coming) and it works great when I 
>> do RTP over UDP, however when I turn on the StreamOverTCP option as 
>> soon as the client tries to send a SET_PARAMETER request the client 
>> appears to hang indefinitely.
>> This is probably my problem and I've just started to work it out, but 
>> any help or suggestions anyone might have would be appreciated.
>>
>> Any suggestions you might have would be most appreciated, I was 
>> hoping that maybe there is a flag or something that I'm not 
>> respecting (particularly with problem #1).  I understand I'm sort of 
>> on the harry edge here so I understand if the only clue you can give 
>> is use the debugger.
>>
>> Thanks
>> Matt Schuckmann
>>
>>
>>
>> _______________________________________________
>> live-devel mailing list
>> live-devel at lists.live555.com
>> http://lists.live555.com/mailman/listinfo/live-devel
>>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>