[asterisk-users] Duplicate DTMF

[Kristian Kielhofner]

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.

-- 
Kristian Kielhofner
http://www.astlinux.org
http://blog.krisk.org
http://www.star2star.com
http://www.submityoursip.com
http://www.voalte.com