[Freeswitch-users] inband dtmf

Wed Jan 28 17:45:56 MSK 2015

thanks for your answers.
Jeff, i will try your suggestion.
Brian, we tried that already but unfortunately did no effect. also we tried
bunch of some other rtp parameters from freeswitch wiki but they also did
not solve the problem.

On Wed, Jan 28, 2015 at 4:26 PM, Brian West <brian at freeswitch.org> wrote:

> You'll want
>
> <action application="set" data="rtp_manual_rtp_bugs=ignore_dtmf_duration"/>
>
> Either in the {} or set as a profile flag, that should fix the issue with
> time skew.
>
>
>
> On Wed, Jan 28, 2015 at 7:29 AM, Jeff Pyle <jpyle at fidelityvoice.com>
> wrote:
>
>> I've been working on a configuration to solve the same problem.  In my
>> case it's a simple in-and-out bridging configuration on a single sofia
>> profile, where the a-leg can be inband or RFC2833 an any number of codecs,
>> but the b-leg must be inband on G.711u.  I have the profile configured with
>> dtmf-mode=rfc2833 as a default.  Then, in the dialplan:
>>
>> <context name="default">
>>
>>   <extension name="detect-2833" continue="true">
>>     <condition field="${switch_r_sdp}" expression="a=rtpmap:\d+
>> telephone-event\/\d+">
>>       <action application="set" data="ringback=${us-ring}"/>
>>       <action application="start_dtmf_generate"/>
>>       <action application="export"
>> data="nolocal:execute_on_answer=start_dtmf"/>
>>       <anti-action application="set" data="dtmf_type=none"/>
>>     </condition>
>>   </extension>
>>
>>   <extension name="sendit">
>>     <condition field="destination_number" expression="(.*)">
>>       <action application="bridge" data="{dtmf_type=none}sofia/public/$1@
>> ${host2}"/>
>>     </condition>
>>   </extension>
>>
>> </context>
>>
>>
>> The first extension seems to do a decent job at detecting whether or not
>> RFC2833-style DTMF is present in the SDP ("telephone-event"), and if so:
>>
>>   - start_dtmf_generate:  This will cause b-leg inband tones when DTMF is
>> detected on the a-leg.  This solves the 2833-to-inband (a to b) direction.
>>
>>   - export nolocal:execute_on_answer=start_dtmf:  This enables DSP
>> detection of inband tones on the b-leg, causing them to relay back to the
>> a-leg as RFC2833 events.
>>
>>   - set ringback:  Turning on this DTMF stuff causes the a-leg to see a
>> 183 Session Progress, probably due to the media processing.  Without
>> setting the ringback, a 180 Ringing from the b-leg doesn't indicate at all
>> on the a-leg.  With setting, it's effectively converted into a 183 Session
>> Progress with inband ringback.
>>
>> If the a-leg does not have RFC2833 indicated, I assume it's inband
>> because I don't support DTMF over SIP INFO.  In this case the detect-2833
>> extension's anti-action sets the dtmf-mode appropriately, overriding the
>> 2833 default in the profile.  This causes the inband tones to pass straight
>> through FS without any detection or manipulation, which is just fine for my
>> case.
>>
>> The good news is this configuration seems to do everything I've
>> described.  The bad news is that it does not mute the inband tones as they
>> travel from b-leg to a-leg.  I haven't figured out that piece yet.
>> Suggestions welcome!
>>
>>
>> - Jeff
>>
>>
>> On Wed, Jan 28, 2015 at 3:53 AM, huseyin kalyoncu <hkalyoncu at gmail.com>
>> wrote:
>>
>>> i found the following statement on freeswitch wiki:
>>>
>>> "*DTMF intercept w/ DTMF detection, removal and regeneration*
>>> Detect DTMF using Goertzel and drop samples identified as containing
>>> DTMF tones. Regenerate the detected DTMF tones on the opposite leg. *This
>>> AFAIK is the only DTMF intercept mode supported by FreeSWITCH ATM.**"*
>>>
>>> according to this can we convert outband(rfc2833) dtmf to inband dtmf?
>>>
>>>
>>> On Mon, Jan 26, 2015 at 3:26 PM, huseyin kalyoncu <hkalyoncu at gmail.com>
>>> wrote:
>>>
>>>> hello
>>>>
>>>> first i want to thank the developers and contributors of this amazing
>>>> product.
>>>> we have been using freeswitch for almost 4 years without a major
>>>> problem.
>>>>
>>>> i have a question regarding inband dtmf.
>>>> we have receiving calls from telco using dtmf rfc2833.  most of
>>>> outgoing calls also
>>>> dtmf rfc2833. but we have a new outgoing profile which is behind a
>>>> firewall. we did
>>>> not make a successful call with transport UDP. so we set the transport
>>>> to TCP and
>>>> now we have successful calls but the only problem is with dtmf. when we
>>>> set the dtmf to
>>>> rfc2833 for this profile, we saw that dtmf packets do not arrive
>>>> correctly to outgoing
>>>> destination. when we dig up the problem we realized that there is
>>>> always a time skew
>>>> on dtmf packets. for this reason we tried to set dtmf inband for this
>>>> particular outgoing
>>>> profile. to accomplish this we used start_dtmf_generate just before the
>>>> bridge action.
>>>> but this time no dtmf package arrive at destination. is this dtmf
>>>> conversion (from rfc2833
>>>>  to inband) even possible?
>>>> what should be the correct configuration to achieve this?
>>>>
>>>> thanks
>>>> huseyin
>>>>
>>>>
>>>
>>> _________________________________________________________________________
>>> Professional FreeSWITCH Consulting Services:
>>> consulting at freeswitch.org
>>> http://www.freeswitchsolutions.com
>>>
>>> Official FreeSWITCH Sites
>>> http://www.freeswitch.org
>>> http://confluence.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://confluence.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
>>
>
>
>
> --
>
> *Brian West*
> brian at freeswitch.org
>
>
> *Twitter: @FreeSWITCH , @briankwest*
> http://www.freeswitchbook.com
> http://www.freeswitchcookbook.com
>
> *T:*+19184209001 | *F:*+19184209002 | *M:*+1918424WEST (9378)
> *iNUM:*+883 5100 1420 9001 | *ISN:*410*543 | *Skype:*briankwest
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://confluence.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/20150128/8cff328d/attachment-0001.html 