Bear in mind that when a carrier says they 'filtered' inband DTMF, they probably mean they have clamped it. There is still DTMF on the line - a few ms, but it is there. Some devices see that clamped DTMF and will use it. For instance, HMP in rfc-2833 mode, will take the rfc-2833 and recreate the DTMF tones - so it always has to be listening for inband even thought it has negociated rfc-2833. In our situation - this resulted in echoed digits - 77227799 - etc just as you are seeing.
There only way of diagnosing this IMO, and that is with wireshark (tshark) and listening to the line - that way you know exactly what you are dealing with.
Our issue was solved btw, by using inband DTMF exclusively. Not ideal bt any means.
On Fri, Aug 13, 2010 at 4:24 AM, Dennis
<odermann@googlemail.com> wrote:
thanks for your help!
just as a short info inbetween, while we are still trying to fix the problem.
the cirpack of our carrier always receives dtmf-inputs as inband tones
(because, at least in germany, all dtmf-inputs are sent over the
landline as inband tones).
because we always had problems with the carriers cirpack and fs in
conjunction with inband tones (sometimes they where sent two or three
times), our carrier added rfc-2833 to their cirpack. now the carrier
sends both: rfc-2833 AND inband tones. the problem is, that the
carrier tells us, that the cirpack can not filter the inband tones, so
that they just can send rfc-2833. but they tell us, that they add some
stops (or something like this) to the inband tones, so that the inband
tones are not functional anymore. but this does not seem to work
correctly.
if we listen to dtmf-inputs only on fs, we do not have any problems,
because fs ignores the inband tones and only reacts to the rfc-2833
signal. therefor we never had any problems.
now, we have a project, where not fs listens to the dtmf-inputs, but a
callcenter on the other side (outbound). therefor the cirpack has to
send clean dtmf-inputs to the callcenter. but we believe, that the
cirpack on the outgoing side is receiving his own inband tones AND
rfc-2833 signals from the incoming side of the cirpack. so the cirpack
on the outgoing side send his own inband tones PLUS the converted
rfc-2833 signals to the other side (callcenter).
we have to go on testing.
we spoke with someone from nokia about their iwsd and they told us,
that they filter all inband tones, so that we only receive rfc-2833.
we will do some testing with them.
but i wonder, why the nokia iwsd can filter inband tones and the cirpack can't.
any ideas?
will keep you informed, what we found out.