[Freeswitch-users] Regeneration of DTMF

Thu Apr 4 21:41:10 MSD 2013

Can you supply a simple set of configs that we could plug into a default
freeswitch install and see if we can lab it up ourselves? Perhaps if we can
see it in a controlled environment it would be easier to diagnose.
-MC

On Thu, Apr 4, 2013 at 5:31 AM, Michael Lutz <mytemike72 at gmail.com> wrote:

> Hi Avi,
>
> I could get a pcap of leg-a, and a p-cap of leg-c, but the leg-b is an
> 'intercal' call to the same switch, by doing an originate to
> external/phonenumber at localswitchIP
> They don't appear on the wirehark logs as i suspect it be routed
> internally as it is recognized as 'self' ...
> Unless you have other ways of capturing those..
>
> The problem is, I have 6 production switches, all handling traffic, and
> these are the switches this specific (using inband dtmf) inbound provider
> routes te traffic to.
> My test switch, is not able to receive calls from this provider. I have no
> other provider that can route traffic with just inband dtmf to my test
> switch....
>
> Mike.
>
> 2013/4/4 Avi Marcus <avi at avimarcus.net>
>
>> 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
>>>
>>>
>>
>> _________________________________________________________________________
>> 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
>
>

-- 
Michael S Collins
Twitter: @mercutioviz
http://www.FreeSWITCH.org
http://www.ClueCon.com
http://www.OSTAG.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20130404/9b01e225/attachment-0001.html 