[Asterisk-Users] Problem with IAX2 jitterbuffer and DTMF reception with 1.2.0

[Rich Adamson]

> >Had the same issue with them for some time using cvs-head. I simply
> >left the jitterbuffer turned off and really haven't had an issue.
> >  
> >
> If you guys ran ethereal on the packets coming from teliax, did you find 
> that the DTMF frames had timestamps that were around the same as the 
> surrounding voice frames? 

Yes, but the timestamps for the dtmf varies. Example, on a dialin test 
call, I entered x3000 into the ivr. The timestamps looked like:
 Test #1------
 audio: 6780ms
 dtmf:  6716  (digit "3" received)
 audio: 6733
 ...
 audio: 7573ms
 dtmf:  7576  (digit "0" received)
 audio: 7593
 ...
 audio: 8073ms
 dtmf:  8076  (digit "0" received)
 audio: 8093
 ...
 audio: 8533ms
 dtmf:  8536
 audio: 8553

The above call was properly completed with gsm, jitterbuffer=no and trunk=no.

Changed my end to jitterbuffer=yes (and no other changes) and placed another
call. The timestamps look completely different:
 Test #2------
 audio: 5340ms
 dtmf:  5370  (digit "3" received)
 audio: 3758101749
 audio: 5360
 ...
 audio: 6460ms
 dtmf:  6490  (digit "0" received)
 audio: 3758102869
 audio: 6480
etc.

In this last test, the dtmf was not accepted and the ivr continued with
its announcements.

Test #3------
Repeated the same with ilbc, jitterbuffer=yes, and trunk=no. Call was
completed and dtmf accepted. The timestamps were exactly the same as
test #1, above.

Test #1 and #3 shows the first dtmf digit arriving with a timestamp
earlier then the audio frame "just before it", but it happens to be
exactly 3ms "after" the audio frame just before that.

Its also interesting to note the messed up timestamps seem to be 
related to the first dtmf packet, with all subsequent dtmf packets
occuring with a timestamp +3ms after the last audio frame.

Unfortunately, I don't know what version of code teliax.com is running.

> If asterisk isn't seeing the DTMF frames at all, it could just be that 
> teliax is sending them with timestamps far into the future or something, 
> so the jitterbuffer is just putting them back in order.  For example, if 
> teliax sends frames that look like this

It does appear to be an issue with timestamps, but not as simple as
"in the future". The dtmf timestamps vary rather dramatically from call
to call.

The only reliable way to complete calls via teliax.com is with the
jitterbuffer turned off.

Rich