[Asterisk-Users] DTMF recognition unreliable or absent, ringing lost on 2nd half of "3-way" call.

[Ryan]

On Thu, Oct 27, 2005 at 02:10:51PM -0400, Dave Grey exclaimed:

>
>These appear to be a common problems, but after spending half a day  
>reading the wiki and list archives I have not gained much useful  
>knowledge beyond the fact that these are a common problems.  I am  
>hoping for some suggestions or pointers to further info.
>
>I have an ivr in my incoming context that does a background() and...  
>well, it is an ivr, no need to explain that, I guess.
>
>So, testing locally, it works wonderfully.  Testing through my DID,  
>provided by IPKall, it is decidedly hit-or-miss.  The digits seem to  
>be either not recognized at all or recognized incorrectly better than  
>half the time. Most often, I get the "invalid extension" playback  
>that I have assigned to the i,1 exten.  For a while, I had two test  
>extensions, one 2000 and one 2001.  Dialing 2001 usually sent me to  
>2000 instead. What is making it hard for me to debug is that it  
>*sometimes* works, recognizing the extension I dialed correctly.
>
>My peer entry in sip.conf for IPKall contains dtmfmode=rfc2833 as per  
>their recommendation.  I have tried setting relaxedtmf=yes in the  
>general section, with no noticeable change.  I turned it off again,  
>since the problem seems to be too much relaxation in any case.   
>Looking at the console, I dial 7056 and it sees 7055, I dial 7056  
>again and it sees 75, I dial 7056 a third time and it sees 7055556,  
>etc.  Seems random and all over the place.  Packet loss and/or  
>ordering?  Aside from the dtmf issue, incoming calls on the DID work  
>fine and sound excellent.
>

This is a known issue that is fixed in CVS HEAD. Search for my prior
emails to track down the bug numbers. Unfortunately this is going to
require the upstream providers to upgrade to truly fix the issue.
Basically the RTP packets are coming out of order and have the wrong
sequence numbers. I started on a band-aid solution using ip_queue, but I
have not had time to finish it up. I will post here if it ever
materializes.

-Ryan