[Freeswitch-users] inband dtmf

[Jeff Pyle]

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