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 -- John A. Sullivan III Open Source Development Corporation +1 207-985-7880 jsullivan at opensourcedevel.com spiritualoutreach.com Making Christianity intelligible to secular society
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 - JohnWhen 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: 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 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 : lists.digium.com/pipermail/asterisk-users/attachments/20090910/0249d10c/attachment.pgp
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 - JohnFairly typical for most SIP carriers... My blog entry may be able to illuminate this a bit: 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 astlinux.org blog.krisk.org star2star.com submityoursip.com voalte.com