Re: [asterisk-users] Duplicate DTMF
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
> 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
jsulli...@opensourcedevel.com
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
Re: [asterisk-users] Duplicate DTMF
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 signature.asc Description: PGP signature ___ -- 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
Re: [asterisk-users] Duplicate DTMF
On Wed, Sep 9, 2009 at 10:22 PM, 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
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
___
-- 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
Re: [asterisk-users] Duplicate DTMF
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 signature.asc Description: PGP signature ___ -- 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
[asterisk-users] Duplicate DTMF
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 jsulli...@opensourcedevel.com 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
[asterisk-users] Duplicate DTMF digits
Hi, I have a system with the following configuration: - Asterisk 1.6.0.3-rc1 - DAHDI Linux 2.1.0.4 - DAHDI Tools 2.1.0.2 - wanpipe-3.3.15 - Sangoma A108E card with ISDN PRI interfaces Calls arrive over the PRI interface and users need to supply DTMF digits before asterisk decides what to do with the call. The DTMF digits are read with the Read application. With low call volumes everything works perfectly. However, with call volumes of more 40 calls I get a large number of DTMF errors, where a digit is detected more than once. For example, with I send the digits 0123456789, Read receives 001112345567899. The digits are are duplicated change on each attempt. I tried relaxdtmf setting chan_dahdi.conf to "yes" and "no" and there is no difference. Can someone help me with this problem or is this a bug? Thank you, AC ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
