[Live-devel] Several problems with RTP-over-TCP

[Gaer, A.]

Hello all!

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?

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.

* "No response to TEARDOWN when the source ended"
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.

* "Defective reuseFirstSource when using OnDemandServerMediaSubsession
with RTP-over-TCP"
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.

* "RTSP is dead after stopping all RTP-over-TCP streams"
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.

* "No error handling on TCP Socket errors"
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.

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?

Best regards,
 Andreas.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20110303/37e122ee/attachment-0001.html>