[asterisk-users] Duplicate DTMF

[C. Chad Wallace]

Oops!  I missed the part where you said you use a SIP trunk.  My
experiences and comments are entirely irrelevant to your case.  Sorry!


At 12:02 PM on 10 Sep 2009, C. Chad Wallace wrote:

> 
> At 10:22 PM on 09 Sep 2009, John A. Sullivan III 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
> 
> When we had that problem, it turned out it was caused by the txgain
> being too high (10.0).  I dropped it down to 5.0, and the DTMF
> problems went away.
> 
> Have you tuned your gains using a milliwatt line and ztmonitor?
> 
> I followed this howto:  http://www.mattgwatson.ca/?p=14
> 
> But that led to the ridiculous txgain setting of 10.0 on all my ports,
> which I later clawed back to 5.0 to fix the DTMF issue.  Maybe I did
> it wrong?  Anyway, the rxgain settings I got from that procedure
> seemed to improve our call quality.  We've since moved to a partial
> PRI instead of those analog lines, so we don't have to worry about
> that anymore. :-)


-- 

C. Chad Wallace, B.Sc.
The Lodging Company
http://www.skihills.com/
OpenPGP Public Key ID: 0x262208A0

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-users/attachments/20090910/68c04f0b/attachment-0001.pgp