[Live-devel] Reordering packets issue.

[Ross Finlayson]

First, the title of this thread is a bit misleading, because the issue has nothing to do with packet "reordering".  The message would have been better titled "Receiving stream with bad RTP sequence numbers issue".


> In file MultiFramedRTPSource.cpp the sequence number checking:
> 
> // Ignore this packet if its sequence number is less than the one
> // that we're looking for (in this case, it's been excessively delayed).
> if (seqNumLT(rtpSeqNo, fNextExpectedSeqNo)) return False;
> 
> has an issue that can causes packets to be rejected and thus freezing of the streaming for a long time. We have observed that sometime a streaming server can reset the streaming and restart with a new random sequence number.

Then the server is broken.  There's nothing in the RTP specification that allows for a sender to arbitrarily change the RTP sequence number.


> It could be caused for example by a failover stream protection that doesn't use the same RTP Sequence number.

Then it's a different stream, in which case the original receiver cannot expect to continue to be able to receive it.

I presume that you're referring to multicast streaming here.  (Because, if the streaming is unicast, there's absolutely no expectation that a server should be able to restart and continue streaming to the same unicast clients, without the clients noticing - and certainly not if the sequence number changes.)

If you were receiving unicast streams, then a robust receiving client application would have some mechanism (at the application level; not in the LIVE555 RTP reception code) for detecting when no data has been received within a certain timeout period, and, if so, restarting the reception code, to receive a new stream.  Your (presumed multicast) client application should do the same thing.

I.e., add a timer to your client application.  If no new data has been received within a certain time, then stop reception of the existing stream (by closing "Groupsock" objects, "RTPSource"s, etc.), and start again, receiving a new stream.


> Some protection mechanism is needed to overcome this potential issue.

Perhaps, but - as noted above - this "protection mechanism" is best done at the application level (because this would also allow it to recover from a wider range of problems than just "buggy server sends streams with broken RTP sequence numbers").  I won't be adding anything to the LIVE555 RTP reception code to attempt to accommodate buggy servers like this.


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20120405/67687cdb/attachment.html>