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 > <[email protected]> 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 [email protected]
http://www.spiritualoutreach.com Making Christianity intelligible to secular society _______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2009 - October 13 - 15 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
