<div>Hi Avi,</div>
<div> </div>
<div>Thanks for you response and explanation, the thing is my leg C does't have start_dtmf, I even tried forcing stop_dtmf, and stop_dtmf_generate on leg B and C, but still this happens., </div>
<div> </div>
<div>It looks like whats happening:</div>
<div>Leg A, has inband DTMF and is using start_dtmf. Leg B is bridged with (from) Leg-A, and is not using start_dtmf, when I eavesdrop the leg-B I can only hear dtmf's once.. (so far so good)</div>
<div>Leg C dials out to external number, and is not using start_dtmf (unless somewhere 'under water') , and is bridged with leg-B using uuid_bridge. When I eavesdrop leg-C, I can hear dtmf's twice.</div>
<div> </div>
<div>So somewhere in Leg-B or C based on receiving the generated rfc2833, FS is generating these dtmf's as 'audio'? I would expect 'stop-dtmf_generate' would stop that? (though this is not documented well)</div>
<div> </div>
<div>So what I need, is either way to stop generating (converting) the inband dtmf to rfc2833, or to stop converting rfc2833 back to inband in leg B ... (I guess?)</div>
<div> </div>
<div>Good we both know what the issue is, now find someone that can help fix it ... ;-)</div>
<div> </div>
<div>Regards,</div>
<div>Mike.<br><br></div>
<div class="gmail_quote">2013/4/3 Avi Marcus <span dir="ltr"><<a href="mailto:avi@avimarcus.net" target="_blank">avi@avimarcus.net</a>></span><br>
<blockquote style="BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PADDING-LEFT:1ex" class="gmail_quote">
<div dir="ltr">I can probably explain the issue to you, but I don't really know how to fix it:
<div><br>
<div>1) Leg A comes in with inband.</div>
<div>2) Your leg B does start_dtmf and detects the inband dtmf.</div>
<div>3) You bridge to leg C which negotiates rfc2833. It gets the rfc2833 events from leg B.</div>
<div><br></div>
<div>But! start_dtmf can't remove the dtmf from the leg A. So the leg A inband dtmf is ALSO being passed along. This however is only a problem if leg C has start_dtmf too. The default dialplan only triggers start_dtmf if there is no rfc2833 negotiated. But don't count on remote parties to do the same....</div>
<div><br></div>
<div><br></div>
<div class="gmail_extra"><br clear="all">
<div>
<div dir="ltr"><span style="FONT-FAMILY:Verdana,Arial,Helvetica,sans-serif;FONT-SIZE:small">-Avi Marcus</span><br>BestFone</div></div><br><br>
<div class="gmail_quote">
<div>
<div class="h5">On Wed, Apr 3, 2013 at 8:15 PM, Michael Lutz <span dir="ltr"><<a href="mailto:mytemike72@gmail.com" target="_blank">mytemike72@gmail.com</a>></span> wrote:<br></div></div>
<blockquote style="BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PADDING-LEFT:1ex" class="gmail_quote">
<div>
<div class="h5">
<div>Hi,</div>
<div> </div>
<div>I have a problem, which I am trying to resolve, but can not exactly figure out where it is going wrong.</div>
<div> </div>
<div>I have an inbound call, this call comes in via SIP and uses inband dtmf, at the begining of the dialplan I enable dtmf detection using spandsp_start_dtmf. this works fine, and my Lua recognizes digits correctly.</div>
<div>The tricky part is that I bridge this call in Lua using an api call "originate", this call is forwarded to the same switch, and is picked up by another Lua script. </div>
<div>This script, is waiting for a custom event, to end the lua, and is bridged with a 3rd call. so the 1st and 3rd call can hear each other. This 3rd call is initiated asynchronosly by an esl server. (this al works fine, and is not 'the issue'..)</div>
<div> </div>
<div>The problem is the receiving end (3rd leg) is receiving the DTMF pressed by the 1st leg twice. When I eavesdrop the 2nd leg, i only hear the dtmf once, when i eavesdrop the 3rd leg, I can hear the dtmf twice. So it is somewhere generated along the way.</div>
<div> </div>
<div>I have tryed several different settings, using stop_dtmf_generate on different legs, but can not seem to diable this regeneration of this extra dtmf.</div>
<div> </div>
<div>Any help would be appreciated as this is really causing issues on my side, </div>
<div> </div>
<div>ps, I know this '3rd leg' principle might look a bit weird, but cannot be avoided, </div>
<div>ps2. When my inbound call comes in using rfc2833, everything works perfectly.</div>
<div> </div>
<div> </div>
<div>Best regards,</div>
<div>Michael Lutz.</div>
<div> </div>
<div> </div>
<div> </div>
<div> </div><br></div></div>_________________________________________________________________________<br>Professional FreeSWITCH Consulting Services:<br><a href="mailto:consulting@freeswitch.org" target="_blank">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" target="_blank">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><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>