[Freeswitch-users] Regeneration of DTMF

[Michael Lutz]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20130404/1b0aa801/attachment.html