<html dir="ltr"><head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="GENERATOR" content="MSHTML 9.00.8112.16457">
</head>
<body ocsi="x">
<font color="#000000" size="2" face="Tahoma">
<div dir="ltr">Thanks for the replies so far, your input is greatly appreciated</div>
<div dir="ltr"> </div>
<div dir="ltr"><br>
Our configuration is</div>
<div dir="ltr"><br>
TELCO --SIP--> FREESWITCH/SBC --SIP--> PBX</div>
<div dir="ltr"><br>
Our Telco uses Inband DTMF for tones.</div>
<div dir="ltr"><br>
Our legacy SBC platform (openser) simply proxied the content through and the PBX's recognised the inband dtmf tones and<br>
acted accordingly.</div>
<div dir="ltr"><br>
Since moving onto FreeSwitch an SBC DTMF on calls made from the telco through to a PBX are not being recognised by the PBX<br>
as inband (ie no DTMF).</div>
<div dir="ltr"><br>
A few notes:</div>
<div dir="ltr"><br>
1) We can add start_dtmf as an application prior to bridge and set dtmf_mode none in the Telco facing context and<br>
dtmf_mode rfc2833 in the pbx facing context, and DTMF is recognised on the PBX (as rfc2833), However we had a resultant<br>
issue that audio file playback from IVR's on the Asterisk PBX is clipped (first 2 seconds or so of each sound file<br>
being played and this does not occur on voice mail box recordings - tested with the same audio file) - interestingly on
<br>
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
<br>
remote IVR on PBX clipped). An interesting notes using the record session application, the clipping is not apparent, only to the
<br>
calling party. (Could this possibly be legitimate bug that should be submitted?)</div>
<div dir="ltr"><br>
So we considered that we should be able to just pass the dtmf inband without looking at the media, however so far<br>
we can not seem to make the PBX's recognise DTMF inband on inbound sip calls.</div>
<div dir="ltr"><br>
The earlier post <br>
<a href="http://lists.freeswitch.org/pipermail/freeswitch-users/2013-January/091332.html">http://lists.freeswitch.org/pipermail/freeswitch-users/2013-January/091332.html</a></div>
<div dir="ltr"><br>
suggested to look at the way freeswitch was setting up the invite to the PBX (perhaps not telling the PBX that<br>
we are using inband).</div>
<div dir="ltr"><br>
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<br>
on our legacy openser SBC as well.</div>
<div dir="ltr"><br>
the only defined difference that we could ascertain was that when using Freeswitch as the SBC the fmtp:18 media<br>
attribute (present between on the telco's invite on the a leg, and present on the openser->pbx invite on the legacy<br>
is missing on the Freeswitch Invite to the PBX.</div>
<div dir="ltr"><br>
Reading suggested to add the</div>
<div dir="ltr"><br>
<action application="export" data="sip_append_audio_sdp=a=fmtp:18 annexb=no"/></div>
<div dir="ltr"><br>
directive to add this media attribute to the b-leg SDP.</div>
<div dir="ltr"><br>
However (and we may be missing the point here) when we do this it has no impact on the SDP INVITE sent from
<br>
the Freeswitch to the PBX (using tcddump to capture the network traffic).</div>
<div dir="ltr"><br>
--</div>
<div dir="ltr"><br>
It seems we have 2 issues;</div>
<div dir="ltr"><br>
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)</div>
<div dir="ltr"><br>
the Second is why doesn't adding the sip_append_audio_sdp actually add the attribute or how can we make<br>
Freeswitch do this (it appears in reading fmtp:18 and dtmf inband have some relationship, we've made an assumption<br>
that this may be why the PBX's are not looking for inband dtmf on these calls.</div>
<div dir="ltr"> </div>
<div dir="ltr">any help is really appreciated as we're currently stuck until we figure this out!</div>
<div dir="ltr"></font> </div>
<div dir="ltr"><font size="2" face="tahoma"></font> </div>
<div dir="ltr"><font size="2" face="tahoma"></font> </div>
<div>
<div><font size="2" face="Tahoma">Kind Regards,</font></div>
<div><font size="2" face="tahoma"></font>
<hr tabindex="-1">
<font size="2" face="Tahoma"><b>From:</b> Steven Ayre [steveayre@gmail.com]<br>
<b>Sent:</b> Friday, 18 January 2013 11:57 AM<br>
<b>To:</b> FreeSWITCH Users Help<br>
<b>Cc:</b> FreeSWITCH Users Help<br>
<b>Subject:</b> Re: [Freeswitch-users] SBC In-band DTMF<br>
</font><br>
</div>
</div>
<div></div>
<div>
<div>
<div dir="ltr">
<blockquote type="cite"><font size="+0"><param name="rfc2833-pt" value="0"/></font></blockquote>
</div>
<div dir="ltr"><br>
</div>
<div dir="ltr"><span>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.</span></div>
<div dir="ltr"><span><br>
</span></div>
<div dir="ltr"><span>More likely you want:</span></div>
<div dir="ltr">
<pre style="BORDER-BOTTOM: rgb(47,111,171) 1px dashed; BORDER-LEFT: rgb(47,111,171) 1px dashed; PADDING-BOTTOM: 1em; PADDING-LEFT: 1em; PADDING-RIGHT: 1em; BORDER-TOP: rgb(47,111,171) 1px dashed; BORDER-RIGHT: rgb(47,111,171) 1px dashed; PADDING-TOP: 1em"><font face="Helvetica"><span style="WHITE-SPACE: normal"><param name="dtmf-type" value="none"/></span></font><span>
</span></pre>
<div><br>
</div>
</div>
<div dir="ltr">
<blockquote type="cite"><font size="+0"><action application="export" data="sip_append_audio_sdp=a=fmtp:18 annexb=no"/></font></blockquote>
</div>
<div><br>
</div>
<div>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.</div>
<br>
<span>Steve on iPhone</span></div>
<div><span><br>
</span></div>
<div><span><br>
</span></div>
<div><span><br>
</span></div>
<div>On 17 Jan 2013, at 02:58, "<a href="mailto:support@ecn.net.au">support@ecn.net.au</a>" <<a href="mailto:support@ecn.net.au">support@ecn.net.au</a>> wrote:<br>
<br>
</div>
<blockquote type="cite">
<div><style title="owaParaStyle"><!--P {
MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
--></style>
<div dir="ltr"><font size="2" face="tahoma">Hi</font></div>
<div dir="ltr"><font size="2" face="tahoma"></font> </div>
<div dir="ltr"><font size="2" face="tahoma">This sounds quite posible.</font></div>
<div dir="ltr"><font size="2" face="tahoma"></font> </div>
<div dir="ltr"><font size="2" face="tahoma">I've tcpdumped sip headers on both the freeswitch and the backend PBX.</font></div>
<div dir="ltr"><font size="2" face="tahoma"></font> </div>
<div dir="ltr"><font size="2" face="tahoma">The only significant difference I can see between our old SBC and FS is that the old SBC</font></div>
<div dir="ltr"><font size="2" face="tahoma">asserted a media attribute fmtp:18 annexb=no where as FS doesn't forward this.</font></div>
<div dir="ltr"><font size="2" face="tahoma"></font> </div>
<div dir="ltr"><font size="2" face="tahoma">To test it out we have set dtmf_mode to none on both contexts (the context facing the telco</font></div>
<div dir="ltr"><font size="2" face="tahoma">and the context facing the pbx), and set
</font></div>
<div dir="ltr"><font size="2" face="tahoma"></font> </div>
<div dir="ltr"><font size="2" face="tahoma"><param name="rfc2833-pt" value="0"/></font></div>
<div dir="ltr"><font size="2" face="tahoma"></font> </div>
<div dir="ltr"><font size="2" face="tahoma">(this may not be needed).</font></div>
<div dir="ltr"><font size="2" face="tahoma"></font> </div>
<div dir="ltr"><font size="2" face="tahoma">then in the dialplan we have</font></div>
<div dir="ltr"><font size="2" face="tahoma"></font> </div>
<div dir="ltr"><font size="2" face="tahoma"><action application="export" data="sip_append_audio_sdp=a=fmtp:18 annexb=no"/></font></div>
<div dir="ltr"><font size="2" face="tahoma"></font> </div>
<div dir="ltr"><font size="2" face="tahoma">set prior to the bridge.</font></div>
<div dir="ltr"><font size="2" face="tahoma"></font> </div>
<div dir="ltr"><font size="2" face="tahoma">--</font></div>
<div dir="ltr"><font size="2" face="tahoma"></font> </div>
<div dir="ltr"><font size="2" face="tahoma">When we sip trace however we are not appending the attribute to the SDP on the INVITE.</font></div>
<div dir="ltr"><font size="2" face="tahoma"></font> </div>
<div dir="ltr"><font size="2" face="tahoma">Logs and sip headers below:</font></div>
<div dir="ltr"><font size="2" face="tahoma"></font> </div>
<div dir="ltr"><font size="2" face="tahoma"></font> </div>
<div dir="ltr"><font size="2" face="tahoma">EXECUTE <a href="mailto:sofia/aapt/0731111111@X.Y.Z.A:5060">
sofia/aapt/0731111111@X.Y.Z.A:5060</a> export(sip_append_audio_sdp=a=fmtp:18 annexb=no)</font></div>
<div dir="ltr"><font size="2" face="tahoma">2013-01-17 12:34:19.702102 [DEBUG] switch_channel.c:1135 EXPORT (export_vars) [sip_append_audio_sdp]=[a=fmtp:18 annexb=no]</font></div>
<div dir="ltr"><font size="2" face="tahoma">EXECUTE <a href="mailto:sofia/aapt/0731111111@X.Y.Z.A:5060">
sofia/aapt/0731111111@X.Y.Z.A:5060</a> bridge(<a href="mailto:sofia/external/0737111111@A.B.C.X:5060">sofia/external/0737111111@A.B.C.X:5060</a>)</font></div>
<div dir="ltr"><font size="2" face="tahoma">2013-01-17 12:34:19.702102 [DEBUG] switch_channel.c:1089
<a href="mailto:sofia/aapt/0731111111@X.Y.Z.A:5060">sofia/aapt/0731111111@X.Y.Z.A:5060</a> EXPORTING[export_vars] [sip_append_audio_sdp]=[a=fmtp:18 annexb=no] to eve</font></div>
<div dir="ltr"><font size="2" face="tahoma">nt</font></div>
<div dir="ltr"><font size="2" face="tahoma">2013-01-17 12:34:19.702102 [DEBUG] switch_ivr_originate.c:2022 Parsing global variables</font></div>
<div dir="ltr"><font size="2" face="tahoma">2013-01-17 12:34:19.702102 [NOTICE] switch_channel.c:968 New Channel
<a href="mailto:sofia/external/0737111111@A.B.C.X:5060">sofia/external/0737111111@A.B.C.X:5060</a> [a30c650a-87d3-4027-9010-213547d698aa]</font></div>
<div dir="ltr"><font size="2" face="tahoma">2013-01-17 12:34:19.702102 [DEBUG] mod_sofia.c:4977 (<a href="mailto:sofia/external/0737111111@A.B.C.X:5060">sofia/external/0737111111@A.B.C.X:5060</a>) State Change CS_NEW -> CS_INIT</font></div>
<div dir="ltr"><font size="2" face="tahoma">2013-01-17 12:34:19.702102 [DEBUG] switch_core_session.c:1283 Send signal
<a href="mailto:sofia/external/0737111111@A.B.C.X:5060">sofia/external/0737111111@A.B.C.X:5060</a> [BREAK]</font></div>
<div dir="ltr"><font size="2" face="tahoma">2013-01-17 12:34:19.702102 [DEBUG] switch_core_state_machine.c:415 (<a href="mailto:sofia/external/0737111111@A.B.C.X:5060">sofia/external/0737111111@A.B.C.X:5060</a>) Running State Change CS_INIT</font></div>
<div dir="ltr"><font size="2" face="tahoma">2013-01-17 12:34:19.702102 [DEBUG] switch_core_state_machine.c:454 (<a href="mailto:sofia/external/0737111111@A.B.C.X:5060">sofia/external/0737111111@A.B.C.X:5060</a>) State INIT</font></div>
<div dir="ltr"><font size="2" face="tahoma">2013-01-17 12:34:19.702102 [DEBUG] mod_sofia.c:86
<a href="mailto:sofia/external/0737111111@A.B.C.X:5060">sofia/external/0737111111@A.B.C.X:5060</a> SOFIA INIT</font></div>
<div dir="ltr"><font size="2" face="tahoma">2013-01-17 12:34:19.702102 [DEBUG] sofia_glue.c:2647 Local SDP:</font></div>
<div dir="ltr"><font size="2" face="tahoma">v=0</font></div>
<div dir="ltr"><font size="2" face="tahoma">o=FreeSWITCH 1358365507 1358365508 IN IP4 A.B.C.D</font></div>
<div dir="ltr"><font size="2" face="tahoma">s=FreeSWITCH</font></div>
<div dir="ltr"><font size="2" face="tahoma">c=IN IP4 A.B.C.D</font></div>
<div dir="ltr"><font size="2" face="tahoma">t=0 0</font></div>
<div dir="ltr"><font size="2" face="tahoma">m=audio 24552 RTP/AVP 8 0 3 13</font></div>
<div dir="ltr"><font size="2" face="tahoma">a=fmtp:18 annexb=no</font></div>
<div dir="ltr"><font size="2" face="tahoma">a=ptime:20</font></div>
<div dir="ltr"><font size="2" face="tahoma">a=sendrecv</font></div>
<div dir="ltr"><font size="2" face="tahoma"></font> </div>
<div dir="ltr"><font size="2" face="tahoma"></font> </div>
<div dir="ltr"><font size="2" face="tahoma">But then the actual Invite doesn't contain the attribute in the SDP</font></div>
<div dir="ltr"><font size="2" face="tahoma"></font> </div>
<div dir="ltr"><font size="2" face="tahoma">send 1036 bytes to udp/[A.B.C.X]:5060 at 02:34:19.718385:</font></div>
<div dir="ltr"><font size="2" face="tahoma"> ------------------------------------------------------------------------</font></div>
<div dir="ltr"><font size="2" face="tahoma"> INVITE sip:0737111111@A.B.C.X:5060 SIP/2.0</font></div>
<div dir="ltr"><font size="2" face="tahoma"> Via: SIP/2.0/UDP A.B.C.D:5080;rport;branch=z9hG4bKpUvH6K1ppUSNp</font></div>
<div dir="ltr"><font size="2" face="tahoma"> Max-Forwards: 69</font></div>
<div dir="ltr"><font size="2" face="tahoma"> From: "0731111111" <sip:0731111111@A.B.C.D>;tag=mH93ZHryv4H2g</font></div>
<div dir="ltr"><font size="2" face="tahoma"> To: <sip:0737111111@A.B.C.X:5060></font></div>
<div dir="ltr"><font size="2" face="tahoma"> Call-ID: 3ca1df3f-daf1-1230-f389-002219a7c712</font></div>
<div dir="ltr"><font size="2" face="tahoma"> CSeq: 38858965 INVITE</font></div>
<div dir="ltr"><font size="2" face="tahoma"> Contact: <sip:mod_sofia@A.B.C.D:5080></font></div>
<div dir="ltr"><font size="2" face="tahoma"> User-Agent: FreeSWITCH-mod_sofia/1.2.5.3+git~20121229T001759Z~e04eab7902</font></div>
<div dir="ltr"><font size="2" face="tahoma"> Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY</font></div>
<div dir="ltr"><font size="2" face="tahoma"> Supported: timer, precondition, path, replaces</font></div>
<div dir="ltr"><font size="2" face="tahoma"> Allow-Events: talk, hold, conference, refer</font></div>
<div dir="ltr"><font size="2" face="tahoma"> Content-Type: application/sdp</font></div>
<div dir="ltr"><font size="2" face="tahoma"> Content-Disposition: session</font></div>
<div dir="ltr"><font size="2" face="tahoma"> Content-Length: 155</font></div>
<div dir="ltr"><font size="2" face="tahoma"> X-Nortel-Profile: DEFAULT</font></div>
<div dir="ltr"><font size="2" face="tahoma"> X-FS-Support: update_display,send_info</font></div>
<div dir="ltr"><font size="2" face="tahoma"> Remote-Party-ID: "0731111111" <sip:0731111111@A.B.C.D>;party=calling;screen=yes;privacy=off</font></div>
<div dir="ltr"><font size="2" face="tahoma"></font> </div>
<div dir="ltr"><font size="2" face="tahoma"> v=0</font></div>
<div dir="ltr"><font size="2" face="tahoma"> o=FreeSWITCH 1358365507 1358365508 IN IP4 A.B.C.D</font></div>
<div dir="ltr"><font size="2" face="tahoma"> s=FreeSWITCH</font></div>
<div dir="ltr"><font size="2" face="tahoma"> c=IN IP4 A.B.C.D</font></div>
<div dir="ltr"><font size="2" face="tahoma"> t=0 0</font></div>
<div dir="ltr"><font size="2" face="tahoma"> m=audio 24552 RTP/AVP 8 0 3 13</font></div>
<div dir="ltr"><font size="2" face="tahoma"> a=ptime:20</font></div>
<div dir="ltr"><font size="2" face="tahoma"> ------------------------------------------------------------------------</font></div>
<div dir="ltr"><font size="2" face="tahoma"></font> </div>
<div dir="ltr"><font size="2" face="tahoma"></font> </div>
<div dir="ltr"><font size="2" face="tahoma"></font> </div>
<div dir="ltr"><font size="2" face="tahoma">Are we missing something do you think?</font></div>
<div dir="ltr"><font size="2" face="tahoma"></font> </div>
<div dir="ltr"><font size="2" face="tahoma"></font> </div>
<div dir="ltr"><font size="2" face="tahoma"></font> </div>
<div>
<div><font size="2" face="Tahoma">Kind Regards,</font></div>
<div><font size="2" face="tahoma"></font> </div>
<div>
<hr tabindex="-1">
<font size="2" face="Tahoma"><b>From:</b> Steven Ayre [<a href="mailto:steveayre@gmail.com">steveayre@gmail.com</a>]<br>
<b>Sent:</b> Thursday, 17 January 2013 4:14 AM<br>
<b>To:</b> FreeSWITCH Users Help<br>
<b>Subject:</b> Re: [Freeswitch-users] SBC In-band DTMF<br>
</font><br>
</div>
</div>
<div></div>
<div>
<blockquote style="BORDER-LEFT: rgb(204,204,204) 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">
However under freeswitch if we don't start_dtmf before the bridge the backend PBX boxes don't recognise<br>
the DTMF inband (even though the tones are audible ie you can hear them on a call recording on the<br>
PBX).<br>
<br>
Have we missed something here? We would have thought with inband DTMF on non compressed codec (no<br>
transcoding) that the tones would just work with the media stream?</blockquote>
<br>
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.
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>-Steve</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>-Steve</div>
<div><br>
</div>
<div><br>
<br>
<br>
On 16 January 2013 04:02, <a href="mailto:support@ecn.net.au">support@ecn.net.au</a> <<a href="mailto:support@ecn.net.au">support@ecn.net.au</a>> wrote:<br>
> Hi All<br>
><br>
> <br>
><br>
> We're quite new to Freeswitch and are in the process of migrating from<br>
> OpenSer (as an SBC) to Freeswitch.<br>
><br>
> <br>
><br>
> Mostly all is working well, except an oddity on DTMF.<br>
><br>
> <br>
><br>
> Our scenario:<br>
><br>
> <br>
><br>
> Telco/SIP Provider A is passing us calls using DTMF inband.<br>
><br>
> <br>
><br>
> We have a freeswitch configured as a SBC using 2 sip profiles (telco and<br>
> internal) to topology hide and manage<br>
><br>
> distribution of calls to the PBX servers located behind the SBC.<br>
><br>
> <br>
><br>
> The freeswitch will be handling up to a few hundred calls so we're trying to<br>
> keep it lightweight.<br>
><br>
> <br>
><br>
> Behind the SBC is a series of Asterisk and Freeswitch PBX boxes handling<br>
> customer needs.<br>
><br>
> <br>
><br>
> An example inbound call profile looks like this:<br>
><br>
> <br>
><br>
> <extension name="Inbound 124356"><br>
><br>
> <condition field="destination_number" expression="^(123456)$"><br>
><br>
> <action application="pre_answer"/><br>
><br>
> <action application="start_dtmf" /><br>
><br>
> <action application="bridge"<br>
> data="<a href="mailto:sofia/external/123456@INTERNAL.PBX.IP">sofia/external/123456@INTERNAL.PBX.IP</a>:5060"/><br>
><br>
> </condition><br>
><br>
> </extension><br>
><br>
> <br>
><br>
> Initially when calling into the platform IVR type applications runinng on<br>
> our PBX boxes would not<br>
><br>
> work (you could hear the DTMF but the platform did not recognise the tones).<br>
><br>
> <br>
><br>
> We have had to add the appliation start_dtmf in order for Freeswitch to pass<br>
> the DTMF to the Asterisk<br>
><br>
> PBX behind the SBC. Interestingly on our OpenSer platform we just proxied<br>
> the media (rtpproxy) with<br>
><br>
> inband DTMF from the Telco and our PBX boxes recognised the inband DTMF<br>
> tones on the PBX platforms and<br>
><br>
> IVR type applications just worked.<br>
><br>
> <br>
><br>
> However under freeswitch if we don't start_dtmf before the bridge the<br>
> backend PBX boxes don't recognise<br>
><br>
> the DTMF inband (even though the tones are audible ie you can hear them on a<br>
> call recording on the<br>
><br>
> PBX).<br>
><br>
> <br>
><br>
> Have we missed something here? We would have thought with inband DTMF on<br>
> non compressed codec (no<br>
><br>
> transcoding) that the tones would just work with the media stream?<br>
><br>
> <br>
><br>
> We have confirmed both legs are PCMA and when using start_dtmf the first<br>
> second of the call is clipped.<br>
><br>
> <br>
><br>
> <br>
><br>
> <br>
><br>
> Kind Regards,<br>
> <br>
><br>
> _________________________________________________________________________<br>
> Professional FreeSWITCH Consulting Services:<br>
> <a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a><br>
> <a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
><br>
> FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>
> <a href="http://www.cudatel.com" target="_blank">http://www.cudatel.com</a><br>
><br>
> Official FreeSWITCH Sites<br>
> <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
> <a href="http://wiki.freeswitch.org" target="_blank">http://wiki.freeswitch.org</a><br>
> <a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><br>
><br>
> FreeSWITCH-users mailing list<br>
> <a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
> <a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
> UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
> <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
><br>
</div>
</div>
</div>
</blockquote>
<blockquote type="cite">
<div><span>_________________________________________________________________________</span><br>
<span>Professional FreeSWITCH Consulting Services:</span><br>
<span><a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a></span><br>
<span><a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a></span><br>
<span></span><br>
<span>FreeSWITCH-powered IP PBX: The CudaTel Communication Server</span><br>
<span><a href="http://www.cudatel.com" target="_blank">http://www.cudatel.com</a></span><br>
<span></span><br>
<span>Official FreeSWITCH Sites</span><br>
<span><a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a></span><br>
<span><a href="http://wiki.freeswitch.org" target="_blank">http://wiki.freeswitch.org</a></span><br>
<span><a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a></span><br>
<span></span><br>
<span>FreeSWITCH-users mailing list</span><br>
<span><a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a></span><br>
<span><a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a></span><br>
<span>UNSUBSCRIBE:http://<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">lists.freeswitch.org/mailman/options/freeswitch-users</a></span><br>
<span><a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a></span><br>
</div>
</blockquote>
</div>
</body>
</html>