Can you get an fs_cli log and/or pcap of the call? Should help understand / see what's going on... -Avi On Thu, Apr 4, 2013 at 12:05 PM, Michael Lutz <mytemike72@gmail.com> wrote:
Hi Avi,
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.,
It looks like whats happening: 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) 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.
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)
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?)
Good we both know what the issue is, now find someone that can help fix it ... ;-)
Regards, Mike.
2013/4/3 Avi Marcus <avi@avimarcus.net>
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
_________________________________________________________________________ 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