[Asterisk-Dev] jitterbuf timestamps range

[Steve Kann]

Kris Boutilier wrote:

>>-----Original Message-----
>>From: Steve Kann [mailto:stevek at stevek.com]
>>Sent: Tuesday, May 10, 2005 6:45 AM
>>To: Asterisk Developers Mailing List
>>Subject: Re: [Asterisk-Dev] jitterbuf timestamps range
>>
>>
>>Slav Klenov wrote:
>>
>>    
>>
>>>Hi all,
>>>
>>>According to the RTP RFC the timestamp field of an rtp 
>>>      
>>>
>>frame is 32 bit.
>>    
>>
>{clip}
>  
>
>>I'm not sure why I chose long for all the timestamping, etc, in the 
>>jitterbuffer, and I haven't really examined what, exactly, 
>>will happen when they overflow, however overflow on a 32-bit system will happen 
>>after 596 hours (24.85 days).   It seems like something to think about 
>>eventually, but calls that last longer than 24 days seem 
>>pretty unusual (and, who knows how asterisk itself handles this).
>>
>>    
>>
>
>With the current implementation of newjb, there will essentially be permanent loss of audio when the timestamps jump backwards massively (ie. the TS wraps). This was the essence of bugs 3965/4221.
>  
>

Those issues weren't really related to this one.

4221 was a bug in trunking, where the 32 bit timestamps weren't being 
properly recreated from the short 16 bit timestamps.

3965 also addressed some of these issueswith 16bit timestamps, and some 
other issues.

Neither of these addressed the 32bit timestamp overflowing.

There's another patch in the works (not yet in mantis, I believe), which 
will allow the jitterbuffer to automatically resync when we get huge 
discontinuities in timestamps (i.e. those which cannot be reasonably 
explained by network jitter).  This is a situation which "shouldn't 
happen" with IAX2, and should only happen with RTP when a "mark" bit is 
sent, but in the real world sometimes does happen.  In the case of an 
RTP "mark" bit, though, the jitterbuffer should just be reset manually, 
(or, the rtp layer should adjust the timestamps to compensate).

This patch might ameliorate the effects of a timestamp wrap, although 
that's not one of the use cases we've been looking at.

-SteveK