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

[Matt Schuckmann]

I found this very good discussion on persistent tcp vs non-persistent 
tcp  RTSP clients.
http://www.ietf.org/mail-archive/web/mmusic/current/msg00655.html

 From reading some of this thread and the live555 RTPSClient code it 
appears that the RTSPClient is a persistent tcp client is this true?

How about the live555 RTSP server? I hope it works either way

I understand at least some of the reasons for making RTSPClient a 
persistent tcp client however it seems that some things could be made 
simpler if you could make it non-persistent (in particular this 
RTP-over-TCP streaming problem). Has any work ever been done in this 
direction?

Thanks for listening to my rambling.

Matt S.


Matt Schuckmann 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) 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
>>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>