[Freeswitch-users] inband dtmf

[Brian West]

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