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@INTERNAL.PBX.IP:5060%22/>/external/123456@INTERNAL.PBX.IP:5060"/<mailto:sofia/external/123456@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,
16 jan 2013 kl. 05:02 skrev "support@ecn.net.au" <support@ecn.net.au>:
We're quite new to Freeswitch and are in the process of migrating from OpenSer (as an SBC) to Freeswitch.
It surprises me that you compare two very different products and migrate from one to the other. OpenSER (or Kamailio.org which is the new name) and FreeSwitch work very well together. FreeSwitch is a b2bua that handles the media and Kamailio kan handle the SIP side and add a layer of protection with modules like Pike that give DoS attack prevention, the SIP pipes for QoS and much more. Don't migrate, use both together! /O Kamailio marketing dept :-)
+1! On Wed, Jan 16, 2013 at 3:09 AM, Olle E. Johansson <oej@edvina.net> wrote:
16 jan 2013 kl. 05:02 skrev "support@ecn.net.au" <support@ecn.net.au>:
We're quite new to Freeswitch and are in the process of migrating from OpenSer (as an SBC) to Freeswitch.
It surprises me that you compare two very different products and migrate from one to the other. OpenSER (or Kamailio.org which is the new name) and FreeSwitch work very well together. FreeSwitch is a b2bua that handles the media and Kamailio kan handle the SIP side and add a layer of protection with modules like Pike that give DoS attack prevention, the SIP pipes for QoS and much more. Don't migrate, use both together!
/O
Kamailio marketing dept :-)
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Kristian Kielhofner
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@ecn.net.au <support@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<sofia/external/123456@INTERNAL.PBX.IP:5060%22/> /external/123456@INTERNAL.PBX.IP:5060"/<sofia/external/123456@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@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@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
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@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@ecn.net.au<mailto:support@ecn.net.au> <support@ecn.net.au<mailto:support@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@INTERNAL.PBX.IP:5060%22/>/external/123456@INTERNAL.PBX.IP:5060"/<mailto:sofia/external/123456@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@freeswitch.org<mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto:FreeSWITCH-users@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
Following up on this. We've tested a few more configurations and it seems that when we exec start_dtmf it is the first perhaps half a second of any sound file that is played on a back end PBX seems to be clipped. If we download the same sound file and play it it is fine, if we use Freeswitch 1.0.6 (intstead of the stable version) it is also fine. an example sounds file is www.ecn.net.au/example.gsm - this file played off an Astiersk PBX befind the Freeswitch SBC plays, however the first 1/2 second or is not heard by the caller (calling through the telco, routed off the SBC and answered in the backend PBX). (if you listen the first part that says "please press 1 to" is not heard, but the rest of the file is. Is there some Freeswitch configuration that may cause this? Regards Mark ________________________________________ From: support@ecn.net.au Sent: Wednesday, 16 January 2013 10:55 PM To: FreeSWITCH Users Help Subject: RE: [Freeswitch-users] SBC In-band DTMF 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@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@ecn.net.au<mailto:support@ecn.net.au> <support@ecn.net.au<mailto:support@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@INTERNAL.PBX.IP:5060%22/>/external/123456@INTERNAL.PBX.IP:5060"/<mailto:sofia/external/123456@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@freeswitch.org<mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto:FreeSWITCH-users@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
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@ecn.net.au <support@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@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@ecn.net.au<mailto:support@ecn.net.au> < support@ecn.net.au<mailto:support@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@INTERNAL.PBX.IP:5060%22/>/external/123456@INTERNAL.PBX.IP :5060"/<mailto:sofia/external/123456@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@freeswitch.org<mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto: FreeSWITCH-users@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@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@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
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@ecn.net.au <support@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@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@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@X.Y.Z.A:5060<mailto:sofia/aapt/0731111111@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@X.Y.Z.A:5060<mailto:sofia/aapt/0731111111@X.Y.Z.A:5060> bridge(sofia/external/0737111111@A.B.C.X:5060<mailto:sofia/external/0737111111@A.B.C.X:5060>) 2013-01-17 12:34:19.702102 [DEBUG] switch_channel.c:1089 sofia/aapt/0731111111@X.Y.Z.A:5060<mailto:sofia/aapt/0731111111@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@A.B.C.X:5060<mailto:sofia/external/0737111111@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@A.B.C.X:5060<mailto:sofia/external/0737111111@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@A.B.C.X:5060<mailto:sofia/external/0737111111@A.B.C.X:5060> [BREAK] 2013-01-17 12:34:19.702102 [DEBUG] switch_core_state_machine.c:415 (sofia/external/0737111111@A.B.C.X:5060<mailto:sofia/external/0737111111@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@A.B.C.X:5060<mailto:sofia/external/0737111111@A.B.C.X:5060>) State INIT 2013-01-17 12:34:19.702102 [DEBUG] mod_sofia.c:86 sofia/external/0737111111@A.B.C.X:5060<mailto:sofia/external/0737111111@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@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@A.B.C.D>;tag=mH93ZHryv4H2g To: <sip:0737111111@A.B.C.X:5060> Call-ID: 3ca1df3f-daf1-1230-f389-002219a7c712 CSeq: 38858965 INVITE Contact: <sip:mod_sofia@A.B.C.D: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: "0731111111" <sip:0731111111@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@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@ecn.net.au<mailto:support@ecn.net.au> <support@ecn.net.au<mailto:support@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@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@freeswitch.org<mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@ecn.net.au <support@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@X.Y.Z.A:5060export(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@X.Y.Z.A:5060 bridge( sofia/external/0737111111@A.B.C.X:5060) 2013-01-17 12:34:19.702102 [DEBUG] switch_channel.c:1089 sofia/aapt/0731111111@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@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@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@A.B.C.X:5060 [BREAK] 2013-01-17 12:34:19.702102 [DEBUG] switch_core_state_machine.c:415 ( sofia/external/0737111111@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@A.B.C.X:5060) State INIT 2013-01-17 12:34:19.702102 [DEBUG] mod_sofia.c:86 sofia/external/0737111111@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@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@A.B.C.D>;tag=mH93ZHryv4H2g To: <sip:0737111111@A.B.C.X:5060> Call-ID: 3ca1df3f-daf1-1230-f389-002219a7c712 CSeq: 38858965 INVITE Contact: <sip:mod_sofia@A.B.C.D: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: "0731111111" <sip:0731111111@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@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@ecn.net.au <support@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@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@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@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@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@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
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@10.0.0.2:5060"/<mailto:sofia/external/0737370000@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@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@10.0.0.1>;tag=QcNe52a9KZmtK To: <sip:0737370000@10.0.0.2:5060> Call-ID: a4944ebb-dafe-1230-f389-002219a7c712 CSeq: 38861844 INVITE Contact: <sip:mod_sofia@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@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@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@ecn.net.au<mailto:support@ecn.net.au> <support@ecn.net.au<mailto:support@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@X.Y.Z.A:5060<mailto:sofia/aapt/0731111111@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@X.Y.Z.A:5060<mailto:sofia/aapt/0731111111@X.Y.Z.A:5060> bridge(sofia/external/0737111111@A.B.C.X:5060<mailto:sofia/external/0737111111@A.B.C.X:5060>) 2013-01-17 12:34:19.702102 [DEBUG] switch_channel.c:1089 sofia/aapt/0731111111@X.Y.Z.A:5060<mailto:sofia/aapt/0731111111@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@A.B.C.X:5060<mailto:sofia/external/0737111111@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@A.B.C.X:5060<mailto:sofia/external/0737111111@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@A.B.C.X:5060<mailto:sofia/external/0737111111@A.B.C.X:5060> [BREAK] 2013-01-17 12:34:19.702102 [DEBUG] switch_core_state_machine.c:415 (sofia/external/0737111111@A.B.C.X:5060<mailto:sofia/external/0737111111@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@A.B.C.X:5060<mailto:sofia/external/0737111111@A.B.C.X:5060>) State INIT 2013-01-17 12:34:19.702102 [DEBUG] mod_sofia.c:86 sofia/external/0737111111@A.B.C.X:5060<mailto:sofia/external/0737111111@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@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@A.B.C.D>;tag=mH93ZHryv4H2g To: <sip:0737111111@A.B.C.X:5060> Call-ID: 3ca1df3f-daf1-1230-f389-002219a7c712 CSeq: 38858965 INVITE Contact: <sip:mod_sofia@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@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@gmail.com<mailto:steveayre@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@ecn.net.au<mailto:support@ecn.net.au> <support@ecn.net.au<mailto:support@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@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@freeswitch.org<mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto:FreeSWITCH-users@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@freeswitch.org<mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto:FreeSWITCH-users@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
<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. More likely you want: <param name="dtmf-type" value="none"/>
<action application="export" data="sip_append_audio_sdp=a=fmtp:18 annexb=no"/>
This is also probably not a good idea. These are attributes of specific codecs and those modules will set them if required. FS is negotiating and terminating media, you shouldn't be needing to play with the SDP at a low level for what you're trying to do. Steve on iPhone On 17 Jan 2013, at 02:58, "support@ecn.net.au" <support@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@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@X.Y.Z.A:5060 bridge(sofia/external/0737111111@A.B.C.X:5060) 2013-01-17 12:34:19.702102 [DEBUG] switch_channel.c:1089 sofia/aapt/0731111111@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@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@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@A.B.C.X:5060 [BREAK] 2013-01-17 12:34:19.702102 [DEBUG] switch_core_state_machine.c:415 (sofia/external/0737111111@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@A.B.C.X:5060) State INIT 2013-01-17 12:34:19.702102 [DEBUG] mod_sofia.c:86 sofia/external/0737111111@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@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@A.B.C.D>;tag=mH93ZHryv4H2g To: <sip:0737111111@A.B.C.X:5060> Call-ID: 3ca1df3f-daf1-1230-f389-002219a7c712 CSeq: 38858965 INVITE Contact: <sip:mod_sofia@A.B.C.D: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: "0731111111" <sip:0731111111@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@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@ecn.net.au <support@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@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@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@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@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Thanks for the replies so far, your input is greatly appreciated Our configuration is TELCO --SIP--> FREESWITCH/SBC --SIP--> PBX Our Telco uses Inband DTMF for tones. Our legacy SBC platform (openser) simply proxied the content through and the PBX's recognised the inband dtmf tones and acted accordingly. Since moving onto FreeSwitch an SBC DTMF on calls made from the telco through to a PBX are not being recognised by the PBX as inband (ie no DTMF). A few notes: 1) We can add start_dtmf as an application prior to bridge and set dtmf_mode none in the Telco facing context and dtmf_mode rfc2833 in the pbx facing context, and DTMF is recognised on the PBX (as rfc2833), However we had a resultant issue that audio file playback from IVR's on the Asterisk PBX is clipped (first 2 seconds or so of each sound file being played and this does not occur on voice mail box recordings - tested with the same audio file) - interestingly on Freeswitch 1.0.6 this clipping does not occur, on 1.2.x or the unstable 1.3 every version exhibits this odd behaviour. (Sound from remote IVR on PBX clipped). An interesting notes using the record session application, the clipping is not apparent, only to the calling party. (Could this possibly be legitimate bug that should be submitted?) So we considered that we should be able to just pass the dtmf inband without looking at the media, however so far we can not seem to make the PBX's recognise DTMF inband on inbound sip calls. The earlier post http://lists.freeswitch.org/pipermail/freeswitch-users/2013-January/091332.h... suggested to look at the way freeswitch was setting up the invite to the PBX (perhaps not telling the PBX that we are using inband). So we tcpdumped the SIP INVITES from the Telco to the SBC and then from the SBC to the PBX, and also did the same on our legacy openser SBC as well. the only defined difference that we could ascertain was that when using Freeswitch as the SBC the fmtp:18 media attribute (present between on the telco's invite on the a leg, and present on the openser->pbx invite on the legacy is missing on the Freeswitch Invite to the PBX. Reading suggested to add the <action application="export" data="sip_append_audio_sdp=a=fmtp:18 annexb=no"/> directive to add this media attribute to the b-leg SDP. However (and we may be missing the point here) when we do this it has no impact on the SDP INVITE sent from the Freeswitch to the PBX (using tcddump to capture the network traffic). -- It seems we have 2 issues; the First is why does start_dtmf in freeswitch 1.2.x and 1.3.x clips the sounds (when in 1.0.x it does not) the Second is why doesn't adding the sip_append_audio_sdp actually add the attribute or how can we make Freeswitch do this (it appears in reading fmtp:18 and dtmf inband have some relationship, we've made an assumption that this may be why the PBX's are not looking for inband dtmf on these calls. any help is really appreciated as we're currently stuck until we figure this out! Kind Regards, ________________________________ From: Steven Ayre [steveayre@gmail.com] Sent: Friday, 18 January 2013 11:57 AM To: FreeSWITCH Users Help Cc: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] SBC In-band DTMF <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. More likely you want: <param name="dtmf-type" value="none"/> <action application="export" data="sip_append_audio_sdp=a=fmtp:18 annexb=no"/> This is also probably not a good idea. These are attributes of specific codecs and those modules will set them if required. FS is negotiating and terminating media, you shouldn't be needing to play with the SDP at a low level for what you're trying to do. Steve on iPhone On 17 Jan 2013, at 02:58, "support@ecn.net.au<mailto:support@ecn.net.au>" <support@ecn.net.au<mailto:support@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@X.Y.Z.A:5060<mailto:sofia/aapt/0731111111@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@X.Y.Z.A:5060<mailto:sofia/aapt/0731111111@X.Y.Z.A:5060> bridge(sofia/external/0737111111@A.B.C.X:5060<mailto:sofia/external/0737111111@A.B.C.X:5060>) 2013-01-17 12:34:19.702102 [DEBUG] switch_channel.c:1089 sofia/aapt/0731111111@X.Y.Z.A:5060<mailto:sofia/aapt/0731111111@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@A.B.C.X:5060<mailto:sofia/external/0737111111@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@A.B.C.X:5060<mailto:sofia/external/0737111111@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@A.B.C.X:5060<mailto:sofia/external/0737111111@A.B.C.X:5060> [BREAK] 2013-01-17 12:34:19.702102 [DEBUG] switch_core_state_machine.c:415 (sofia/external/0737111111@A.B.C.X:5060<mailto:sofia/external/0737111111@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@A.B.C.X:5060<mailto:sofia/external/0737111111@A.B.C.X:5060>) State INIT 2013-01-17 12:34:19.702102 [DEBUG] mod_sofia.c:86 sofia/external/0737111111@A.B.C.X:5060<mailto:sofia/external/0737111111@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@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@A.B.C.D>;tag=mH93ZHryv4H2g To: <sip:0737111111@A.B.C.X:5060> Call-ID: 3ca1df3f-daf1-1230-f389-002219a7c712 CSeq: 38858965 INVITE Contact: <sip:mod_sofia@A.B.C.D: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: "0731111111" <sip:0731111111@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@gmail.com<mailto:steveayre@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@ecn.net.au<mailto:support@ecn.net.au> <support@ecn.net.au<mailto:support@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@INTERNAL.PBX.IP<mailto:sofia/external/123456@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@freeswitch.org<mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto:FreeSWITCH-users@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@freeswitch.org<mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users<http://lists.freeswitch.org/mailman/options/freeswitch-users> http://www.freeswitch.org
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,
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@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,
I would capture packet traces of SIP from FS->PBX under 1.0.6 and 1.2 and compare those here. On 18 January 2013 15:20, support@ecn.net.au <support@ecn.net.au> wrote:
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?)
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@ecn.net.au <support@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@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@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@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@ecn.net.au <support@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@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@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@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@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@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@gmail.com<mailto:steveayre@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@ecn.net.au<mailto:support@ecn.net.au> <support@ecn.net.au<mailto:support@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@cupis.co.uk<mailto:paul@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@freeswitch.org<mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto:FreeSWITCH-users@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@freeswitch.org<mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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.
The fact you can't get this working means something strange is happening. Personally I wouldn't trust this environment enough to start playing with things like DTMF transcoding. Did you verify in the capture that you are not advertising RFC2833 to the PBX? Very hard to diagnose without full traces but appreciate you can't share these on the interwebs. Richard
Static payload values (<96) can be reassigned dynamically with a=rtpmap lines, but could perhaps conflict with loaded modules already using those values. On 18 January 2013 10:26, Paul Cupis <paul@cupis.co.uk> wrote:
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@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
participants (7)
-
jay binks
-
Kristian Kielhofner
-
Olle E. Johansson
-
Paul Cupis
-
Richard Brady
-
Steven Ayre
-
support＠ecn.net.au