[asterisk-users] Duplicate DTMF

[John A. Sullivan III]

On Thu, 2009-09-10 at 15:26 -0400, Kristian Kielhofner wrote:
> On Wed, Sep 9, 2009 at 10:22 PM, John A. Sullivan III
> <jsullivan at opensourcedevel.com> wrote:
> > Hello, all.  I've come across a nasty problem just as we are ready to
> > put our first system into production.  During our final testing, we were
> > plagued with several "invalid extension" or "password incorrect"
> > messages when we knew the information entered was correct.  Upon
> > investigation, we saw that DTMF signals were occasionally but not
> > consistently duplicated.  We might dial extension 1234, see 1234 on the
> > phone from which we dialed, but see 112334 on the Asterisk console.
> >
> > We have seen this from cell phones calling via the PSTN (we use a SIP
> > trunking carrier and do not handle the PSTN interface ourselves); we've
> > seen it from land line phones via the PSTN, and have even seen it
> > internally from our own Snom SIP phones.
> >
> > dtmfmode=auto but we have also tried setting it to rfc2833 and we have
> > tried relaxdtmf set to both yes and no.
> >
> > We are running Asterisk 1.6.1.6 on CentOS 5.3.  We really don't know
> > what more to do to fix it.  Googling shows that others have had this
> > problem but I haven't seen a clear resolution other than playing with
> > relaxdtmf.  How do we solve this problem? Thanks - John
> 
>   Fairly typical for most SIP carriers...  My blog entry may be able
> to illuminate this a bit:
> 
> http://blog.krisk.org/2009/02/update-youve-been-waiting-for.html
> 
>   In short RFC2833 DTMF issues are fairly common.  It's troublesome
> enough when trying to go directly to the Tier 1 carriers themselves.
> More than likely you're dealing with a reseller ("carrier") that most
> likely inherits issues from their carrier and adds their own.
> 
>   A couple of weeks ago someone e-mailed me asking for RFC2833
> assistance with Asterisk and a carrier using Sonus.  Turns out:
> 
> a) The "carrier" was a reseller of various other carriers that use Sonus.
> b)  The "carrier" proxied RTP (and therefor RFC2833 events) through an
> Asterisk 1.2 machine; further mangling the RFC2833 events.
> 
>   Other than some drastic changes at the "carrier" there wasn't much
> that could be done...
> 
>   Sorry I can't offer more specific advice to your situation bit
> without an RTP packet capture there isn't much I (we) can do.
> 
> P.S. - Ignore any suggestions for gain, etc.  These are for Zap
> channels and do not apply to sip.  Changing anything in zapata.conf
> will not affect your situation.  I'm not even sure of the existence or
> purpose of relaxdtmf in sip.conf in Asterisk 1.4 or later.
> 
This may indeed be the case.  I hesitated to ask our carrier (with whom
we are quite happy thus far) since I believe we have seen this issue on
internal calls (but only once as opposed to the consistent problem with
external calls).  I did anyway and they put us on a different "switch."
That seems to have solved the problem.  Thanks - John
-- 
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan at opensourcedevel.com

http://www.spiritualoutreach.com
Making Christianity intelligible to secular society