[Freeswitch-users] SBC In-band DTMF

[jay binks]

Id be suggesting that you get PCaps on all legs of the call and just be
100% sure where the audio is clipped.



On 16 January 2013 22:55, support at ecn.net.au <support at ecn.net.au> wrote:

> Hi
>
> This is what we now have, however there is an interesting side effect
> (major issues actally) we're getting when using start_dtmf on the aleg from
> the "dodgy" telco.  the oddity is that when start_dtmf is executed prior to
> bridge some audio content from the back end PBX's (behind the Freeswitch
> SBC) does not seem to transmit back through to the caller (on the aleg of
> the freeswitch SBC (for example play back of a canned audio file from an
> IVR on an Asterisk PBX behind the SBC).
>
> In testing Freeswitch on version 1.2 (1.2.5 and 1.2.3) and 1.3 testing all
> versions have this issue, however on an old 1.0.6 legacy version that we
> compiled today -  does not produce the same problem (it works perfectly);
> could it be a bug in the 1.2/3 freeswitch do you think?  Or is it something
> we've missed?
>
> To reconfirm:
>
> context A (telco context) we have a sip profile (dtmf_mode=none),
> context B (to.pbx context) we have a sip profile (dtmf_mode=rfc2833)
>
> On the xml dial plan for context A we start_dtmf before we bridge the call
> from the telco to the backend pbx.
>
> When executing start_dtmf the system correctly transmits the dtmf digits
> to the backend pbx's however the by product (which we earlier thought was
> clipping the start of the call) is that some audio content (such as some
> audio file playback) doesn't get heard by the caller (dialed via the telco
> through the SBC to the pbx).
>
> Any help appreciated!  Is there a change in how start_dtmf effects calls
> from the 1.2 and onward versions?
>
> Regards
> Mark
>
>
>
>
> ________________________________________
> From: jay binks [jaybinks at gmail.com]
> Sent: Wednesday, 16 January 2013 7:17 PM
> To: FreeSWITCH Users Help
> Subject: Re: [Freeswitch-users] SBC In-band DTMF
>
> on your internal sip profile ( one facing PBX's ) set  <param
> name="dtmf-type" value="rfc2833"/>
>
> then note the dialplan context that super dodgey sip carrier ( the one
> doing inband only )
> sends calls to, and use <action application="start_dtmf" /> on calls from
> them.
>
> Id advise against <action application="pre_answer"/> in that location
> unless you REALLY want that.
>
> that should do what you want.
>
>
> On 16 January 2013 14:02, support at ecn.net.au<mailto:support at ecn.net.au> <
> support at ecn.net.au<mailto: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<mailto:sofia
> /external/123456 at INTERNAL.PBX.IP:5060%22/>/external/123456 at INTERNAL.PBX.IP
> :5060"/<mailto:sofia/external/123456 at INTERNAL.PBX.IP:5060%22/>>
>
>         </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<mailto: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<mailto:
> 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
>
>
>
>
> --
> Sincerely
>
> Jay
>
> _________________________________________________________________________
> 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
>



-- 
Sincerely

Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20130117/ddf51845/attachment-0001.html