[Freeswitch-users] SBC In-band DTMF

Mon Jan 21 03:47:05 MSK 2013

Hi Richard

many thanks for your message.

We're having some odd issues that is for sure (and it is likely us no doubt).

Tried the settings you suggested (strip down FS and just proxy the media) - however we still can't get the PBX's on the inside of the SBC to detect inband, very strange - if we record the call or tcpdump the RTP and play it back in wireshark the DTMF tones are present.

Moving forward from that, I am happy to use start_dtmf to convert inband->rfc2833, however we have a major problem with start_dtmf.

The issue is that in FS 1.2/1.3 (and NOT in FS 1.0.6) when we start_dtmf it causes the auto to break up on some message playbacks from the internal PBX's.

We've wiresharked both the A and B leg and I can confirm that the audio on the B leg (PBX ->FS SBC) is perfect, but the audio on the A-Leg (FS-SBC -> TELCO/SIPPROVIDER) has significant breakups.

If you browse

www.ecn.net.au/rtp_stream_pbx_to_fs.jpg    (the rtp stream from wireshark from PBX->FS)
www.ecn.net.au/rtp_stream_fs_to_telco.jpg    (the rtp stream from FS->TELCO).

On the stream from FS to the Telco the arrows show sections of the rtp where there is no audio, however it's getting to the FS just that FS seems to be dropping audio.

(we are running G711).

This only happens with using start_dtmf before bridging the call and when we are running FS 1.2/1.3 (on 1.0.6 the start_dtmf does not exhibit this issue).

The stream is an audio stream from an IVR on an Asterisk platform.

Very odd! Any ideas much appreciated.  What we don't get is why 1.0.6 doesn't show the problem, where as all 1.2's we've tried do (change of functionality or are we missing some configuration directives?)

Best Regards
Mark

________________________________________
From: Richard Brady [rnbrady at gmail.com]
Sent: Sunday, 20 January 2013 9:08 AM
To: FreeSWITCH Users Help
Subject: Re: [Freeswitch-users] SBC In-band DTMF

Hey Mark

A few thoughts:

1. If you are using start_dtmf on the FS box then you are making it do media processing which is fine but this is a change from what the OpenSER / RTPproxy were doing for you. If you want it to be a drop-in replacement you might want to look at some of the following:

proxy_media
inbound-proxy-media
http://wiki.freeswitch.org/wiki/Proxy_Media
disable-transcoding
codec_string / ep_codec_string
inherit_codec
http://wiki.freeswitch.org/wiki/Codec_negotiation

2. It's dtmf-type in the profile or dtmf_type in the dialplan. Not dtmf_mode as you mention in an earlier message.

3. Your post mentioning PT 18 and the annexb parameter suggests you are using G729, which does not support inband DTMF reliably, if at all.

4. You will need to put the sip_append_audio_sdp before the pre_answer (which you should get rid off as suggested already).

5. if you do want FS to convert from inband to rfc2833, there was a previous post suggesting spandsp_start_dtmf may perform better than start_dtmf (although I can't verify this).

Regards,
Richard

On 18 January 2013 16:12, Steven Ayre <steveayre at gmail.com<mailto:steveayre at gmail.com>> wrote:
Did you try removing the rfc2833-pt param and setting <param name="dtmf-type" value="none"/> on the outgoing sofia profile to the PBX?

Inband tones will always be passed over, FS would actively need to detect the tone and remove it from the media to avoid doing so. So the PBX is not looking inband for it. Since there's no way in SIP to notify that inband tones are in use the PBX is probably checking for out-of-band DTMF and not checking inband at all if out-of-band has been negotiated - so what you probably need to is disable out of band media entirely.

As far as comparing FS behaviour to OpenSER goes I would avoid it. They're very different products. Understand the difference between a SIP proxy (OpenSER) and a B2BUA (FreeSWITCH). OpenSER only forwards SIP messages with media terminating on the endpoints. FS negotiates 2 separate calls including media and terminates both calls on FS and passes media between them. As such OpenSER doesn't do any media negotiation and FS does which will make their behaviour rather different.

-Steve

On 18 January 2013 15:20, support at ecn.net.au<mailto:support at ecn.net.au> <support at ecn.net.au<mailto:support at ecn.net.au>> wrote:
Yes, we read that and tried to set that when attempting multiple configurations (attempting to pass inband dtmf).

Currently we can't get Freeswitch in an SBC role to pass the inband in the media stream at all (see earlier email) - also having odd issues with start_dtmf when accessing Asterisk IVR's (again very odd).  the only difference we can see (between FS and our legacy openser) is the Invite pushed on the bleg on Openser included the fmtp:18 annexb=no directive (as per the telco's SDP to us); however on FS it doesn't forward these (and we can't seem to force FS to add these attributes to the SDP on the bleg).

Again the start_dtmf issues exists only in 1.2 and 1.3 FS , in the 1.0.6 the issue is not present (is this a bug possibly?)

Any ideas?

Kind Regards,

Mark

________________________________________
From: Paul Cupis [paul at cupis.co.uk<mailto:paul at cupis.co.uk>]
Sent: Friday, 18 January 2013 8:26 PM
To: FreeSWITCH Users Help
Subject: Re: [Freeswitch-users] SBC In-band DTMF

On Fri, Jan 18, 2013 at 01:57:36AM +0000, Steven Ayre wrote:
>      <param name="rfc2833-pt" value="0"/>
>
>    What're you hoping to do here? This sets the payload type value. 0 is a
>    valid pt. This won't disable it, it'll instead use the value 0. That
>    happens to be the one for G711, so if that codec is enabled you're just
>    going to get a conflict.

If the rfc2833-pt is set to a value <96 it is outside the allowed range
for dynamic payload negotiation and FS will not offer RFC2833 support
in the SDP.

ref: sofia_glue.c

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

_________________________________________________________________________
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