[Freeswitch-users] SBC In-band DTMF
support at ecn.net.au
support at ecn.net.au
Thu Jan 17 07:30:01 MSK 2013
We've tcpdumped the data and exported this from wireshark.
The dialplan for this b-leg of the bridged call is:
<action application="export" data="sip_append_audio_sdp=a=fmtp:18 annexb=no"/>
<action application="bridge" data="sofia/external/0737370000 at 10.0.0.2:5060"/<mailto:sofia/external/0737370000 at 10.0.0.2:5060"/>>
10.0.0.1 was the Freeswitch, 10.0.0.2 is the backend PBX.
tcpdump SIP capture on the backend PBX for the invite from the Freeswitch SBC.
(Note the SDP does not contain the media attribute for fmtp).
INVITE sip:0737370000 at 10.0.0.2:5060 SIP/2.0
Via: SIP/2.0/UDP 10.0.0.1:5080;rport;branch=z9hG4bKZc0gp7rpvB2Xe
Max-Forwards: 69
From: "0731050000" <sip:0731050000 at 10.0.0.1>;tag=QcNe52a9KZmtK
To: <sip:0737370000 at 10.0.0.2:5060>
Call-ID: a4944ebb-dafe-1230-f389-002219a7c712
CSeq: 38861844 INVITE
Contact: <sip:mod_sofia at 10.0.0.1:5080>
User-Agent: FreeSWITCH-mod_sofia/1.2.5.3+git~20121229T001759Z~e04eab7902
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY
Supported: timer, precondition, path, replaces
Allow-Events: talk, hold, conference, refer
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 155
X-Nortel-Profile: DEFAULT
X-FS-Support: update_display,send_info
Remote-Party-ID: "0731050000" <sip:0731050000 at 10.0.0.1>;party=calling;screen=yes;privacy=off
v=0
o=FreeSWITCH 1358367831 1358367832 IN IP4 10.0.0.1
s=FreeSWITCH
c=IN IP4 10.0.0.1
t=0 0
m=audio 27986 RTP/AVP 8 0 3 13
a=ptime:20
Kind Regards,
________________________________
From: jay binks [jaybinks at gmail.com]
Sent: Thursday, 17 January 2013 2:16 PM
To: FreeSWITCH Users Help
Subject: Re: [Freeswitch-users] SBC In-band DTMF
the problem with doing the sip traces how you have, is that you dont have the RTP Stream.
id be using tcpdump on your boxes, so you can see does the RTP ( that appears to be cut off ) even get to your FS node.
http://wiki.freeswitch.org/wiki/Packet_Capture
do something like
tcpdump -nq -s 0 -i eth0 -w /tmp/dump.pcap
On 17 January 2013 12:58, support at ecn.net.au<mailto:support at ecn.net.au> <support at ecn.net.au<mailto:support at ecn.net.au>> wrote:
Hi
This sounds quite posible.
I've tcpdumped sip headers on both the freeswitch and the backend PBX.
The only significant difference I can see between our old SBC and FS is that the old SBC
asserted a media attribute fmtp:18 annexb=no where as FS doesn't forward this.
To test it out we have set dtmf_mode to none on both contexts (the context facing the telco
and the context facing the pbx), and set
<param name="rfc2833-pt" value="0"/>
(this may not be needed).
then in the dialplan we have
<action application="export" data="sip_append_audio_sdp=a=fmtp:18 annexb=no"/>
set prior to the bridge.
--
When we sip trace however we are not appending the attribute to the SDP on the INVITE.
Logs and sip headers below:
EXECUTE sofia/aapt/0731111111 at X.Y.Z.A:5060<mailto:sofia/aapt/0731111111 at X.Y.Z.A:5060> export(sip_append_audio_sdp=a=fmtp:18 annexb=no)
2013-01-17 12:34:19.702102 [DEBUG] switch_channel.c:1135 EXPORT (export_vars) [sip_append_audio_sdp]=[a=fmtp:18 annexb=no]
EXECUTE sofia/aapt/0731111111 at X.Y.Z.A:5060<mailto:sofia/aapt/0731111111 at X.Y.Z.A:5060> bridge(sofia/external/0737111111 at A.B.C.X:5060<mailto:sofia/external/0737111111 at A.B.C.X:5060>)
2013-01-17 12:34:19.702102 [DEBUG] switch_channel.c:1089 sofia/aapt/0731111111 at X.Y.Z.A:5060<mailto:sofia/aapt/0731111111 at X.Y.Z.A:5060> EXPORTING[export_vars] [sip_append_audio_sdp]=[a=fmtp:18 annexb=no] to eve
nt
2013-01-17 12:34:19.702102 [DEBUG] switch_ivr_originate.c:2022 Parsing global variables
2013-01-17 12:34:19.702102 [NOTICE] switch_channel.c:968 New Channel sofia/external/0737111111 at A.B.C.X:5060<mailto:sofia/external/0737111111 at A.B.C.X:5060> [a30c650a-87d3-4027-9010-213547d698aa]
2013-01-17 12:34:19.702102 [DEBUG] mod_sofia.c:4977 (sofia/external/0737111111 at A.B.C.X:5060<mailto:sofia/external/0737111111 at A.B.C.X:5060>) State Change CS_NEW -> CS_INIT
2013-01-17 12:34:19.702102 [DEBUG] switch_core_session.c:1283 Send signal sofia/external/0737111111 at A.B.C.X:5060<mailto:sofia/external/0737111111 at A.B.C.X:5060> [BREAK]
2013-01-17 12:34:19.702102 [DEBUG] switch_core_state_machine.c:415 (sofia/external/0737111111 at A.B.C.X:5060<mailto:sofia/external/0737111111 at A.B.C.X:5060>) Running State Change CS_INIT
2013-01-17 12:34:19.702102 [DEBUG] switch_core_state_machine.c:454 (sofia/external/0737111111 at A.B.C.X:5060<mailto:sofia/external/0737111111 at A.B.C.X:5060>) State INIT
2013-01-17 12:34:19.702102 [DEBUG] mod_sofia.c:86 sofia/external/0737111111 at A.B.C.X:5060<mailto:sofia/external/0737111111 at A.B.C.X:5060> SOFIA INIT
2013-01-17 12:34:19.702102 [DEBUG] sofia_glue.c:2647 Local SDP:
v=0
o=FreeSWITCH 1358365507 1358365508 IN IP4 A.B.C.D
s=FreeSWITCH
c=IN IP4 A.B.C.D
t=0 0
m=audio 24552 RTP/AVP 8 0 3 13
a=fmtp:18 annexb=no
a=ptime:20
a=sendrecv
But then the actual Invite doesn't contain the attribute in the SDP
send 1036 bytes to udp/[A.B.C.X]:5060 at 02:34:19.718385:
------------------------------------------------------------------------
INVITE sip:0737111111 at A.B.C.X:5060 SIP/2.0
Via: SIP/2.0/UDP A.B.C.D:5080;rport;branch=z9hG4bKpUvH6K1ppUSNp
Max-Forwards: 69
From: "0731111111" <sip:0731111111 at A.B.C.D>;tag=mH93ZHryv4H2g
To: <sip:0737111111 at A.B.C.X:5060>
Call-ID: 3ca1df3f-daf1-1230-f389-002219a7c712
CSeq: 38858965 INVITE
Contact: <sip:mod_sofia at A.B.C.D:5080>
User-Agent: FreeSWITCH-mod_sofia/1.2.5.3<http://1.2.5.3>+git~20121229T001759Z~e04eab7902
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY
Supported: timer, precondition, path, replaces
Allow-Events: talk, hold, conference, refer
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 155
X-Nortel-Profile: DEFAULT
X-FS-Support: update_display,send_info
Remote-Party-ID: "0731111111" <sip:0731111111 at A.B.C.D>;party=calling;screen=yes;privacy=off
v=0
o=FreeSWITCH 1358365507 1358365508 IN IP4 A.B.C.D
s=FreeSWITCH
c=IN IP4 A.B.C.D
t=0 0
m=audio 24552 RTP/AVP 8 0 3 13
a=ptime:20
------------------------------------------------------------------------
Are we missing something do you think?
Kind Regards,
________________________________
From: Steven Ayre [steveayre at gmail.com<mailto:steveayre at gmail.com>]
Sent: Thursday, 17 January 2013 4:14 AM
To: FreeSWITCH Users Help
Subject: Re: [Freeswitch-users] SBC In-band DTMF
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<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/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<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
--
Sincerely
Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20130117/eb40f434/attachment-0001.html
Join us at ClueCon 2011 Aug 9-11, 2011
More information about the FreeSWITCH-users
mailing list