[Freeswitch-users] Regeneration of DTMF

[Michael Lutz]

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 at 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 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
>>
>>
>
> _________________________________________________________________________
> 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/20130404/eba9e1c7/attachment.html