<html><head><base href="x-msg://23019/"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>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".</div><div><br></div><div><br><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div lang="EN-US" link="blue" vlink="purple"><div class="WordSection1" style="page: WordSection1; "><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 10pt; font-family: Tahoma, sans-serif; color: black; ">In file MultiFramedRTPSource.cpp the sequence number checking:<br><br>// Ignore this packet if its sequence number is less than the one<br>// that we're looking for (in this case, it's been excessively delayed).<br>if (seqNumLT(rtpSeqNo, fNextExpectedSeqNo)) return False;<br><br>has<span class="Apple-converted-space"> </span></span><span style="font-size: 10pt; font-family: Tahoma, sans-serif; color: rgb(31, 73, 125); ">an issue</span><span style="font-size: 10pt; font-family: Tahoma, sans-serif; color: black; "><span class="Apple-converted-space"> </span>that can cause</span><span style="font-size: 10pt; font-family: Tahoma, sans-serif; color: rgb(31, 73, 125); ">s</span><span style="font-size: 10pt; font-family: Tahoma, sans-serif; color: black; "><span class="Apple-converted-space"> </span>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.</span></div></div></div></span></blockquote><div><br></div>Then the server is broken. There's nothing in the RTP specification that allows for a sender to arbitrarily change the RTP sequence number.</div><div><br></div><div><br><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div lang="EN-US" link="blue" vlink="purple"><div class="WordSection1" style="page: WordSection1; "><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 10pt; font-family: Tahoma, sans-serif; color: black; "> It could be caused for example by a failover<span class="Apple-converted-space"> </span></span><span style="font-size: 10pt; font-family: Tahoma, sans-serif; color: rgb(31, 73, 125); ">stream</span><span style="font-size: 10pt; font-family: Tahoma, sans-serif; color: black; "><span class="Apple-converted-space"> </span>protection that doesn't use the same RTP Sequence number.</span></div></div></div></span></blockquote><div><br></div>Then it's a different stream, in which case the original receiver cannot expect to continue to be able to receive it.</div><div><br></div><div>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.)</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><br><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div lang="EN-US" link="blue" vlink="purple"><div class="WordSection1" style="page: WordSection1; "><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 10pt; font-family: Tahoma, sans-serif; color: black; ">Some protection mechanism is needed to overcome this potential issue.</span></div></div></div></span></blockquote><div><br></div>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.</div><br><br><div apple-content-edited="true">
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; ">Ross Finlayson<br>Live Networks, Inc.<br><a href="http://www.live555.com/">http://www.live555.com/</a></span></span>
</div>
<br></body></html>