<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7655.11">
<TITLE>Several problems with RTP-over-TCP</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->
<P><FONT SIZE=2 FACE="Arial">Hello all!</FONT>
</P>
<P><FONT SIZE=2 FACE="Arial">The last days I was debugging some problems when using an On-Demand Server to stream MPEG4/H.264 video as RTP-over-TCP. After taking a deeper look into the TCP code, it seems that they are not too easily fixable, but a major rewrite of the RTP-over-TCP code would be needed to fix them all. Are there currently any efforts underway in that direction?</FONT></P>
<P><FONT SIZE=2 FACE="Arial">If they're not already known, here are the problems I'm dealing with at the moment (you can reproduce them with the "testOnDemandRTSPServer" from the latest 2011.01.24 release). All problems arise when you use RTP-over-TCP streaming mode.</FONT></P>
<P><FONT SIZE=2 FACE="Arial">* "No response to TEARDOWN when the source ended"</FONT>
<BR><FONT SIZE=2 FACE="Arial">If the source ends playing (e.g. EOF), StreamState::reclaim will be called by the afterPlayingStreamState handler. The RTCPInstance and RTPSink will be deleted, which causes them to de-register the TCP socket from the RTPInterface. This turns off reading of this socket. The delete of the RTCPInstance also will send a BYE-Event to the client. The client will try to TEARDOWN, but as nobody is listening on the still open TCP socket, it never get's an answer. VLC (1.1.7) totally locks up in that situation - nice.</FONT></P>
<P><FONT SIZE=2 FACE="Arial">* "Defective reuseFirstSource when using OnDemandServerMediaSubsession with RTP-over-TCP"</FONT>
<BR><FONT SIZE=2 FACE="Arial">Again, if the source ends (e.g. EOF) the StreamState will "reclaim", but the OnDemandServerMediaSubsession will not be informed by that. So on the next request, it will readily re-use the StreamState that is already dead, no data at all. This will only be cured if eventually the RTSPClientSession owning the StreamTokens are garbage collected by the liveness timeout. If they (for whatever reason) are kept alive, it is impossible to open a new Stream with this Subsession.</FONT></P>
<P><FONT SIZE=2 FACE="Arial">* "RTSP is dead after stopping all RTP-over-TCP streams"</FONT>
<BR><FONT SIZE=2 FACE="Arial">I'm not too sure about that one, as I'm not too deep into RTSP RFC and I don't have any testcode to prove it. But from what I see, if within a RTSP session you start RTP-over-TCP streams and stop them all, also the RTSP session will be dead. It seems to be impossible to start any other streams now.</FONT></P>
<P><FONT SIZE=2 FACE="Arial">* "No error handling on TCP Socket errors"</FONT>
<BR><FONT SIZE=2 FACE="Arial">There are already some posts about this on the list. Personally I think not doing error handling on serious errors (socket closed => "Broken pipe") is not good. The server will continue to try to put packets into a socket that is known closed. So you will have extra load until some time a liveness check will kill the RTSPClientSession.</FONT></P>
<P><FONT SIZE=2 FACE="Arial">It seems that handing over the ownership of the TCP socket to the RTPInterface when doing RTP-over-TCP is the root of all evil here. Wouldn't it be better to let the RTSPClientSession still own the socket, do the read-handling and de-muxing and give a delegate to the RTPInterface for sending data?</FONT></P>
<P><FONT SIZE=2 FACE="Arial">Best regards,</FONT>
<BR><FONT SIZE=2 FACE="Arial"> Andreas.</FONT>
</P>
<BR>
<BR>
</BODY>
</HTML>