<div dir="ltr">Get a PCAP of your incoming call. (pcapsipdump?)<div><br><div>Likely, your carrier is passing along the DTMF inband, perhaps as well as rfc2833. Or maybe they do clamp down as they convert it to rfc2833, but it takes time and some bleeds through.</div>

<div>(Your logs will show how the dtmf got received -- see if start_dtmf got triggered.)</div><div><br></div><div>As far as I can tell, FS has no feature to <i>remove</i> inband dtmf.</div><div><br></div><div><div><div dir="ltr">

<span style="font-family:Verdana,Arial,Helvetica,sans-serif;font-size:small">-Avi<br></span></div></div>
<br><br><div class="gmail_quote">On Mon, Mar 11, 2013 at 10:47 AM, Matt Broad <span dir="ltr">&lt;<a href="mailto:matt@inveroak.com" target="_blank">matt@inveroak.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="ltr">Hi,<div><br></div><div>I have the following dialplan in my public folder (the dest_number below is just an example):</div><div><br></div><div><div>&lt;include&gt;</div><div><span style="white-space:pre-wrap">        </span>&lt;extension name=&quot;dialExt1002&quot;&gt;</div>




<div><span style="white-space:pre-wrap">                </span>&lt;condition field=&quot;destination_number&quot; expression=&quot;^(1234)$&quot;&gt;</div><div><span style="white-space:pre-wrap">                        </span>&lt;action application=&quot;set&quot; data=&quot;drop_dtmf=true&quot;/&gt;<br>




</div><div><span style="white-space:pre-wrap">                        </span>&lt;action application=&quot;export&quot; data=&quot;drop_dtmf=true&quot;/&gt;</div><div>                        &lt;!-- Add a bind_meta_app just to make sure that the rfc2833 is still being picked up --&gt;</div>




<div><span style="white-space:pre-wrap">                </span> <span style="white-space:pre-wrap">        </span>&lt;action application=&quot;bind_meta_app&quot; data=&quot;4 b s execute_extension::att_xfer XML features&quot;/&gt;</div>
<div><span style="white-space:pre-wrap">                        </span>&lt;action application=&quot;set&quot; data=&quot;ignore_early_media=true&quot; /&gt;</div><div><span style="white-space:pre-wrap">                        </span>&lt;action application=&quot;set&quot; data=&quot;ringback=${uk-ring}&quot;/&gt;</div>




<div><span style="white-space:pre-wrap">                        </span>&lt;action application=&quot;set&quot; data=&quot;call_timeout=30&quot;/&gt;</div><div><span style="white-space:pre-wrap">                        </span>&lt;action application=&quot;bridge&quot; data=&quot;user/1002&quot;/&gt;</div>




<div><span style="white-space:pre-wrap">                </span>&lt;/condition&gt;<br></div><div><span style="white-space:pre-wrap">        </span>&lt;/extension&gt;<br></div><div>&lt;/include&gt;</div><div><br></div><div>I am trying to prevent the DTMF tones from being heard by the b-leg (in this case user/1002). </div>




<div>This works fine if the extension is called by a registered softphone (the user_context is set to public). The digits are pressed and no beeps or tones are heard by the other side.</div><div><br></div><div>If this extension is dialed by a landline/mobile number, when a digit is pressed there is a slight &quot;bleeding&quot; of the DTMF.  Enough to distinguish between different digits, though probably not enough to determin the digit pressed.</div>




<div><br></div><div>I have tried several things such as stop_dtmf in the dialplan, setting the dtmf-duration to 0 (not quite sure what this param does but tried it anyway :) ) in the sip profile but nothing seems to prevent it.<br>



</div><div><br></div><div>Could it be our provider? They have confirmed that they use out-of -band rfc2883. But without the drop_dtmf being set in the dialplan the full tone is heard. Could they be sending inband and out-of-band?</div>



<div><br></div><div>Could anyone suggest any tests I could run or any log files I could look at please?</div><div><br></div><div><br></div>Many Thanks<span class="HOEnZb"><font color="#888888"><br>Matt<br><br></font></span></div>

</div>
<br>_________________________________________________________________________<br>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a><br>
<a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
<br>
FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>
<a href="http://www.cudatel.com" target="_blank">http://www.cudatel.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://wiki.freeswitch.org" target="_blank">http://wiki.freeswitch.org</a><br>
<a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><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>
<br></blockquote></div><br></div></div></div>