<div>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.</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>Our issue was solved btw, by using inband DTMF exclusively. Not ideal bt any means. <br><br></div>
<div class="gmail_quote">On Fri, Aug 13, 2010 at 4:24 AM, Dennis <span dir="ltr"><<a href="mailto:odermann@googlemail.com">odermann@googlemail.com</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">thanks for your help!<br><br>just as a short info inbetween, while we are still trying to fix the problem.<br>
<br>the cirpack of our carrier always receives dtmf-inputs as inband tones<br>(because, at least in germany, all dtmf-inputs are sent over the<br>landline as inband tones).<br>because we always had problems with the carriers cirpack and fs in<br>
conjunction with inband tones (sometimes they where sent two or three<br>times), our carrier added rfc-2833 to their cirpack. now the carrier<br>sends both: rfc-2833 AND inband tones. the problem is, that the<br>carrier tells us, that the cirpack can not filter the inband tones, so<br>
that they just can send rfc-2833. but they tell us, that they add some<br>stops (or something like this) to the inband tones, so that the inband<br>tones are not functional anymore. but this does not seem to work<br>correctly.<br>
<br>if we listen to dtmf-inputs only on fs, we do not have any problems,<br>because fs ignores the inband tones and only reacts to the rfc-2833<br>signal. therefor we never had any problems.<br>now, we have a project, where not fs listens to the dtmf-inputs, but a<br>
callcenter on the other side (outbound). therefor the cirpack has to<br>send clean dtmf-inputs to the callcenter. but we believe, that the<br>cirpack on the outgoing side is receiving his own inband tones AND<br>rfc-2833 signals from the incoming side of the cirpack. so the cirpack<br>
on the outgoing side send his own inband tones PLUS the converted<br>rfc-2833 signals to the other side (callcenter).<br>we have to go on testing.<br><br>we spoke with someone from nokia about their iwsd and they told us,<br>
that they filter all inband tones, so that we only receive rfc-2833.<br>we will do some testing with them.<br>but i wonder, why the nokia iwsd can filter inband tones and the cirpack can't.<br><br>any ideas?<br><br>will keep you informed, what we found out.<br>
<div>
<div></div>
<div class="h5"><br>_______________________________________________<br>FreeSWITCH-users mailing list<br><a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br><a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br><a href="http://www.freeswitch.org/" target="_blank">http://www.freeswitch.org</a><br>
</div></div></blockquote></div><br>