[Freeswitch-users] Regeneration of DTMF

[Avi Marcus]

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 at 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 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
>>
>>
>
> _________________________________________________________________________
> 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/7812b64d/attachment-0001.html