[Asterisk-Dev] Jitterbuffer bug?

[Rich Adamson]

> > 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.

That was an excellent explaination; straight to the point.

Thanks!