<div dir="ltr">I&#39;ve been working on a configuration to solve the same problem.  In my case it&#39;s a simple in-and-out bridging configuration on a single sofia profile, where the a-leg can be inband or RFC2833 an any number of codecs, but the b-leg must be inband on G.711u.  I have the profile configured with dtmf-mode=rfc2833 as a default.  Then, in the dialplan:<div><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div>&lt;context name=&quot;default&quot;&gt;</div></div><div><div><br></div></div><div><div>  &lt;extension name=&quot;detect-2833&quot; continue=&quot;true&quot;&gt;</div></div><div><div>    &lt;condition field=&quot;${switch_r_sdp}&quot; expression=&quot;a=rtpmap:\d+ telephone-event\/\d+&quot;&gt;</div></div><div><div>      &lt;action application=&quot;set&quot; data=&quot;ringback=${us-ring}&quot;/&gt;</div></div><div><div>      &lt;action application=&quot;start_dtmf_generate&quot;/&gt;</div></div><div><div>      &lt;action application=&quot;export&quot; data=&quot;nolocal:execute_on_answer=start_dtmf&quot;/&gt;</div></div><div><div>      &lt;anti-action application=&quot;set&quot; data=&quot;dtmf_type=none&quot;/&gt;</div></div><div><div>    &lt;/condition&gt;</div></div><div><div>  &lt;/extension&gt;</div></div><div><div><br></div></div><div><div>  &lt;extension name=&quot;sendit&quot;&gt;</div></div><div><div>    &lt;condition field=&quot;destination_number&quot; expression=&quot;(.*)&quot;&gt;</div></div><div><div>      &lt;action application=&quot;bridge&quot; data=&quot;{dtmf_type=none}sofia/public/$1@${host2}&quot;/&gt;</div></div><div><div>    &lt;/condition&gt;</div></div><div><div>  &lt;/extension&gt;</div></div><div><div><br></div></div><div><div>&lt;/context&gt;</div></div></blockquote><div><br></div><div>The first extension seems to do a decent job at detecting whether or not RFC2833-style DTMF is present in the SDP (&quot;telephone-event&quot;), and if so:</div><div><br></div><div>  - start_dtmf_generate:  This will cause b-leg inband tones when DTMF is detected on the a-leg.  This solves the 2833-to-inband (a to b) direction.</div><div><br></div><div>  - export nolocal:execute_on_answer=start_dtmf:  This enables DSP detection of inband tones on the b-leg, causing them to relay back to the a-leg as RFC2833 events.</div><div><br></div><div>  - set ringback:  Turning on this DTMF stuff causes the a-leg to see a 183 Session Progress, probably due to the media processing.  Without setting the ringback, a 180 Ringing from the b-leg doesn&#39;t indicate at all on the a-leg.  With setting, it&#39;s effectively converted into a 183 Session Progress with inband ringback.</div><div><br></div><div>If the a-leg does not have RFC2833 indicated, I assume it&#39;s inband because I don&#39;t support DTMF over SIP INFO.  In this case the detect-2833 extension&#39;s anti-action sets the dtmf-mode appropriately, overriding the 2833 default in the profile.  This causes the inband tones to pass straight through FS without any detection or manipulation, which is just fine for my case.</div><div><br></div><div>The good news is this configuration seems to do everything I&#39;ve described.  The bad news is that it does not mute the inband tones as they travel from b-leg to a-leg.  I haven&#39;t figured out that piece yet.  Suggestions welcome!</div><div><br></div><div><br></div><div>- Jeff</div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 28, 2015 at 3:53 AM, huseyin kalyoncu <span dir="ltr">&lt;<a href="mailto:hkalyoncu@gmail.com" target="_blank">hkalyoncu@gmail.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">i found the following statement on freeswitch wiki:<div><br><div>&quot;<span style="color:rgb(0,0,0);font-family:sans-serif;font-size:14.8480005264282px;line-height:19.2000007629395px"><b>DTMF intercept w/ DTMF detection, removal and regeneration</b></span></div><div><span style="color:rgb(0,0,0);font-family:sans-serif;font-size:12.8000001907349px;line-height:19.2000007629395px">Detect DTMF using Goertzel and drop samples identified as containing DTMF tones. Regenerate the detected DTMF tones on the opposite leg. </span><b style="color:rgb(0,0,0);font-family:sans-serif;font-size:12.8000001907349px;line-height:19.2000007629395px">This AFAIK is the only DTMF intercept mode supported by FreeSWITCH ATM.</b><b style="color:rgb(0,0,0);font-family:sans-serif;font-size:12.8000001907349px;line-height:19.2000007629395px">&quot;</b></div><div><b style="color:rgb(0,0,0);font-family:sans-serif;font-size:12.8000001907349px;line-height:19.2000007629395px"><br></b></div><div><font color="#000000" face="sans-serif"><span style="font-size:12.8000001907349px;line-height:19.2000007629395px">according to this can we convert outband(rfc2833) dtmf to inband dtmf? </span></font></div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 26, 2015 at 3:26 PM, huseyin kalyoncu <span dir="ltr">&lt;<a href="mailto:hkalyoncu@gmail.com" target="_blank">hkalyoncu@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">hello<div><br></div><div>first i want to thank the developers and contributors of this amazing product. </div><div>we have been using freeswitch for almost 4 years without a major problem.</div><div><br></div><div>i have a question regarding inband dtmf. </div><div>we have receiving calls from telco using dtmf rfc2833.  most of outgoing calls also </div><div>dtmf rfc2833. but we have a new outgoing profile which is behind a firewall. we did </div><div>not make a successful call with transport UDP. so we set the transport to TCP and </div><div>now we have successful calls but the only problem is with dtmf. when we set the dtmf to </div><div>rfc2833 for this profile, we saw that dtmf packets do not arrive correctly to outgoing </div><div>destination. when we dig up the problem we realized that there is always a time skew</div><div>on dtmf packets. for this reason we tried to set dtmf inband for this particular outgoing </div><div>profile. to accomplish this we used start_dtmf_generate just before the bridge action. </div><div>but this time no dtmf package arrive at destination. is this dtmf conversion (from rfc2833</div><div> to inband) even possible? </div><div>what should be the correct configuration to achieve this?</div><div> </div><div>thanks</div><span><font color="#888888"><div>huseyin </div><div><br></div></font></span></div>
</blockquote></div><br></div></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>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://confluence.freeswitch.org" target="_blank">http://confluence.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></blockquote></div><br></div></div>