[Freeswitch-users] SBC In-band DTMF

[Steven Ayre]

>
> However under freeswitch if we don't start_dtmf before the bridge the
> backend PBX boxes don't recognise
> the DTMF inband (even though the tones are audible ie you can hear them on
> a call recording on the
> PBX).
>
> Have we missed something here?  We would have thought with inband DTMF on
> non compressed codec (no
> transcoding) that the tones would just work with the media stream?


start_dtmf will detect inband DTMF, and then send out of band on the
outgoing leg of the bridge. This is expected. You'll will need to call
start_dtmf from dialplan, which can easily be done from dialplan by
checking for some condition identifying calls requiring it. If they're
authenticating to FS then it'd be trivial to set a variable in their user
directory entry that you can test in the dialplan.

Now this is just a guess... During the codec negotiation FS will tell your
PBX that it supports telephone-event (RFC2833). It may be that because the
PBX sees that in the SDP that it doesn't look for inband DTMF, while when
it received the SDP direct from the customer it didn't contain
telephone-event and so did check for inband DTMF. Indeed it'd probably be a
good idea for them to do so, since if you receive the same DTMF digit both
inband and through RFC2833 then you'd be  duplicating digits. So my guess
is that the PBX doesn't bother check for inband because FS tells it it's
sending out-of-band, which'd differ from before.

-Steve



-Steve




On 16 January 2013 04:02, support at ecn.net.au <support at ecn.net.au> wrote:
> Hi All
>
>
>
> We're quite new to Freeswitch and are in the process of migrating from
> OpenSer (as an SBC) to Freeswitch.
>
>
>
> Mostly all is working well, except an oddity on DTMF.
>
>
>
> Our scenario:
>
>
>
> Telco/SIP Provider A is passing us calls using DTMF inband.
>
>
>
> We have a freeswitch configured as a SBC using 2 sip profiles (telco and
> internal) to topology hide and manage
>
> distribution of calls to the PBX servers located behind the SBC.
>
>
>
> The freeswitch will be handling up to a few hundred calls so we're trying
to
> keep it lightweight.
>
>
>
> Behind the SBC is a series of Asterisk and Freeswitch PBX boxes handling
> customer needs.
>
>
>
> An example inbound call profile looks like this:
>
>
>
> <extension name="Inbound 124356">
>
>         <condition field="destination_number" expression="^(123456)$">
>
>                 <action application="pre_answer"/>
>
>                 <action application="start_dtmf" />
>
>                 <action application="bridge"
> data="sofia/external/123456 at INTERNAL.PBX.IP:5060"/>
>
>         </condition>
>
> </extension>
>
>
>
> Initially when calling into the platform IVR type applications runinng on
> our PBX boxes would not
>
> work (you could hear the DTMF but the platform did not recognise the
tones).
>
>
>
> We have had to add the appliation start_dtmf in order for Freeswitch to
pass
> the DTMF to the Asterisk
>
> PBX behind the SBC.   Interestingly on our OpenSer platform we just
proxied
> the media (rtpproxy) with
>
> inband DTMF from the Telco and our PBX boxes recognised the inband DTMF
> tones on the PBX platforms and
>
> IVR type applications just worked.
>
>
>
> However under freeswitch if we don't start_dtmf before the bridge the
> backend PBX boxes don't recognise
>
> the DTMF inband (even though the tones are audible ie you can hear them
on a
> call recording on the
>
> PBX).
>
>
>
> Have we missed something here?  We would have thought with inband DTMF on
> non compressed codec (no
>
> transcoding) that the tones would just work with the media stream?
>
>
>
> We have confirmed both legs are PCMA and when using start_dtmf the first
> second of the call is clipped.
>
>
>
>
>
>
>
> Kind Regards,
>
>
> _________________________________________________________________________
> 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/20130116/190ffa65/attachment.html