Here is what I have been able to ascertain in the past few days.
There is a known problem in * regarding RFC2833. While this shows up, in
my case with the Sipura SPA-3000, I am sure it applies to many other
devices. Many may not know they even have a problem if they do not use
DTMF codes on an established connection. An easy way to fond out is to
call your * from your cell phone and with one phone on one ear, and one on
the other, hit keys on each phone while listening on the other. You should
be able to hear at least .5 seconds or so of DTMF. In he case where it is
not working you hear a clicking sound and just a hint of DTMF or none
I solved this for now by going to inband between * and my SPA-3000 and
limiting the codec to ulaw.
Yet another * problem that is possibly related is that if you activate any
features, "TtWw" etc. in your incoming or outgoing dial plan to the pstn
using the device, in my case the SPA-3000, even if you are using inband, *
will filter the first DTMF character that is defined. Thus if you set
transfer to *9, and you have a "T" and/or "t" in your dial plan to pstn,
the '*' key will be filtered and not heard on the other end in much the
same way it sounds when using rfc2833 without features enabled. The
correct behavior, assuming you do not want the keys to be heard at the
distant end, would be to mute the key and if a second key were not
selected in the timeout period then send that keys DTMF. This would
probably be difficult to achieve with inband but if you were using a non
inband method I expect the digit could be buffered and delayed just
enough to 'pick off' and mute/take action or send the DTMF.
Sorry for the long winded reply. So much has been written on this. Goggle
is full of complaints with few if any answers. Often the device gets
blamed and as in the case of the SPA-3000 there are hundreds of settings
and at least a half dozen that might effect this, so there is always
someone who tells you to do this or that.
I just wish that Digium would have made a statement saying they are aware
of the problem and are working on it. I did kind of dig that out of the
Digium archives but it seems to have ended back in March. If the problem
were just published as known and a possible temporary fix it would save a
lot of people the grief of having to reinvent the wheel and find out all
over again what is wrong.
Post by Nick Hoffman Post by Eric "ManxPower" Wieling Post by Doug Crompton
Ok well I am not crazy! This seems like such an important issue I am
not sure why it has lasted for so long. DTMF is the backbone of
everything we do here. Without it we would not have calls!! At least
get the DTMF stuff right. I feel a little guilty complaining since
this is free but it is also used in some high level demanding
situations (not mine) and thus is not a trivial issue.
In my experience, PSTN DTMF problems are usually a volume issue. Play
with the receive and transmit gains on the SIPura FXO port.
Of course when doing SIP you need your DTMF mode (RFC2833 is what I
recommend) correct before you start trying to fix the PSTN DTMF issues.
Hi guys. I've just read through this thread and am a bit confused. Is this
DTMF issue related only to using Sipura/Linksys ATAs with Asterisk, or
does it pertain to every device that connects to Asterisk, including
FXS/FXO PCI cards?
p: +61 7 5591 3588
f: +61 7 5591 6588
If you receive this email by mistake, please notify us and do not make any
use of the email. We do not waive any privilege, confidentiality or
copyright associated with it.
--Bandwidth and Colocation provided by Easynews.com --
Asterisk-Users mailing list
"Those that sacrifice essential liberty to obtain a little temporary safety
deserve neither liberty nor safety." -- Ben Franklin (1759)
* Doug Crompton *
* Richboro, PA 18954 *
* 215-431-6307 *
* ***@crompton.com *
* http://www.crompton.com *