[Freeswitch-users] Regeneration of DTMF

[Avi Marcus]

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 at 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 at freeswitch.org
> http://www.freeswitchsolutions.com
>
> 
> 
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20130403/06c11b6f/attachment.html