[Asterisk-Dev] Jitterbuffer bug?

[Andrew Kohlsmith]

On Saturday 11 June 2005 14:35, Rich Adamson wrote:
> maxjitterbuffer=200
> maxexccessbuffer=100

These two lines are irrelavent with the new jitter buffer.

> Immediately after pressing "3", the debug shows about 100 of the
> following messages:
> clamping target from 521 to 200
> clamping target from 521 to 200
> <snipped many more>
> clamping target from 521 to 200
> clamping target from 521 to 200

This is caused by teliax not having an up-to-date-enough CVS HEAD.  There's a 
zaptel bug I've been chasing (but stalling on lately) which causes chan_zap 
not to send any frames back to asterisk at all while playing out a DTMF 
digit.  CVS HEAD from about 3 weeks ago has a workaround patch in it which 
masks the problem.

Short and long of it: get teliax to update their server (it's a one-line patch 
which fixes this), or turn off the jitter buffer.

Now for the explanation:  the new jitter buffer can interpolate for lost/late 
frames.  When you send a DTMF digit, teliax sends the DTMF ioctl to the 
zaptel driver.  Somewhere between zaptel.c and chan_zap.c there are no frames 
received (not even silent frames, which the driver does generate) for the 
duration that the zaptel driver is playing out DTMF to the PSTN.

When the DTMF is finished playing (about 200ms) chan_zap sees frames again, 
but the timestamp on the next frame is the timestamp that the first silent 
frame should be... so the entire stream is 200ms behind.  If only one or two 
DTMF digits are sent it falls within what the new jb will handle "nicely" but 
it seems that three DTMF digits pushes it beyond what the new JB will handle 
and you get that message until enough of the frames in the large history the 
jb has "fall out".

e.g. timestamps:  
20,40,60,80,100,120
now send DTMF digit
there are 200 ms of NO frames and then the first frame is 140, not 340, and 
the timestamps continue:  160,180,200,220... instead of 340,360,380...

The one-liner fix is in chan_iax2.c, there's a #define for 
MAX_TIME_STAMP_SKEW.  The default is 640ms; we changed it to 160ms.  
Basically it's a threshhold which is used to determine whether to send 
implicit (ts=0) or explicit timestamp values.  My understanding of it is that 
when a frame is about to be sent asterisk compares its internal frame 
timestamp time to gettimeofday's "reality" and if the skew is larger than 
this value, it resync sits internal frame timestamp to reality and continues.

The CORRECT fix is to figure out why this is happenning between zaptel and 
chan_zap and that's what I've been working on, although not for a few weeks 
now since I've been busy with other things.  It's definitely not in zaptel.c 
from what I can tell though, since my test programs do not show it at all 
(actually one's been running since I last was playing with it, I should check 
if it's still running).

Hope this helps.  It's not really what you want to hear (it's a far-end 
problem that the newjb exacerbates) but it's what we've determined.

-A.