I can probably explain the issue to you, but I don't really know how to fix it:
1) Leg A comes in with inband.2) Your leg B does start_dtmf and detects the inband dtmf.3) You bridge to leg C which negotiates rfc2833. It gets the rfc2833 events from leg B.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....
-Avi Marcus
BestFone
On Wed, Apr 3, 2013 at 8:15 PM, Michael Lutz <mytemike72@gmail.com> wrote:_________________________________________________________________________Hi,I have a problem, which I am trying to resolve, but can not exactly figure out where it is going wrong.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.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.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'..)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.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.Any help would be appreciated as this is really causing issues on my side,ps, I know this '3rd leg' principle might look a bit weird, but cannot be avoided,ps2. When my inbound call comes in using rfc2833, everything works perfectly.Best regards,Michael Lutz.
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.com
Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org
_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.com
Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org