On 2013-04-12 14:08, Christian Vogler wrote:
I hope you mean:
- on the sender and receiver side I do modulo 2**31 arithmetic
- on the sender side I limit the maximum random sequence restart
number to 2**30.
actually yes, I do - but the difference between 2**31 and 2**30 is a
cool billion, so wraparound really is never ever going to happen if
the sender implements this strategy. Under these circumstances, doing
modulo arithmetic is a mere precaution against clients that ignore
this issue. I'm fine with specifying something re the wraparound in
the standard, though - in fact, I would feel better if there were
something.
Right, I agree, it is sufficient the way you state it.
-----------------------------------------
Looking at how others have handled wrap around issues, I found this
exotic but relevant statement in RFC 3550 RTP section 4 on NTP wrap around:
----------------------------------------------------
The NTP timestamp will wrap around to zero some time in the year 2036,
but for RTP purposes, only differences between pairs of NTP timestamps
are used. So long as the pairs of timestamps can be assumed to be within
68 years of each other, using modular arithmetic for subtractions and
comparisons makes the wraparound irrelevant.
------------------------------------------------------
So, we are in good company if we devote a few words to rare wrap-around
issue prevention.
/Gunnar
