[Freeswitch-users] Freetdm DTMF
Shane Harrison
shane.harrison at paragon.co.nz
Thu May 10 23:55:49 MSD 2012
Hi
For calls originating from Freetdm extension I simply set up
freetdm.conf.xml to use the XML dialplan and context fxs-ports like so:
<span name="analogExtns">
<param name="hold-music" value="$${moh_uri}"/>
<param name="tonegroup" value="nz"/>
<param name="digit-timeout" value="2000"/>
<param name="max-digits" value="11"/>
<param name="callwaiting" value="true"/>
<param name="answer-polarity-reverse" value="false"/>
<param name="hangup-polarity-reverse" value="false"/>
<!-- FreeSWITCH dialplan type and context to send the calls -->
<param name="dialplan" value="XML"/>
<param name="context" value="fxs-ports"/>
</span>
Then dialplan to get it into default context is:
<context name="fxs-ports">
<extension name="outbound">
<condition field="destination_number" expression="^(.*)$">
<action application="set"
data="toll_allow=local,domestic,international"/>
<action application="transfer" data="$1 XML default"/>
</condition>
</extension>
</context>
For calls into FreeTDM I have the following dialplan:
<extension name="Local_FXS_Extension">
<condition field="destination_number" expression="^(300)$">
<action application="set" data="dialed_extension=300"/>
<action application="export" data="dialed_extension=300"/>
<!-- bind_meta_app can have these args <key> [a|b|ab] [a|b|o|s]
<app> -->
<action application="bind_meta_app" data="1 ab s
execute_extension::dx XML features"/>
<action application="bind_meta_app" data="2 ab s
record_session::$${recordings_dir}/archive/${strftime(%Y)}/${strftime(%b)}/${strftime(%d)}/${uuid}.wav"/>
<action application="bind_meta_app" data="3 ab s
execute_extension::cf XML features"/>
<action application="bind_meta_app" data="4 ab s
execute_extension::att_xfer XML features"/>
<action application="set" data="ringback=${us-ring}"/>
<action application="set" data="transfer_ringback=$${hold_music}"/>
<action application="set" data="call_timeout=30"/>
<!-- <action application="set"
data="sip_exclude_contact=${network_addr}"/> -->
<action application="set" data="hangup_after_bridge=true"/>
<!--<action application="set"
data="continue_on_fail=NORMAL_TEMPORARY_FAILURE,USER_BUSY,NO_ANSWER,TIMEOUT,NO_ROUTE_DESTINATION"/>
-->
<action application="set" data="continue_on_fail=true"/>
<action application="hash"
data="insert/${domain_name}-call_return/300/${caller_id_number}"/>
<action application="hash"
data="insert/${domain_name}-last_dial_ext/300/${uuid}"/>
<action application="set"
data="called_party_callgroup=${user_data(300@${domain_name} var
callgroup)}"/>
<!--<action application="export"
data="nolocal:sip_secure_media=${user_data(300@${domain_name} var
sip_secure_media)}"/>-->
<action application="hash"
data="insert/${domain_name}-last_dial/${called_party_callgroup}/${uuid}"/>
<action application="bridge" data="freetdm/2/1"/>
<action application="answer"/>
<action application="sleep" data="1000"/>
<!--<action application="bridge"
data="loopback/app=voicemail:default ${domain_name}
${dialed_extension}"/>-->
<action application="voicemail" data="default ${domain_name} 300"/>
</condition>
</extension>
Cheers
Shane
On Fri, May 11, 2012 at 2:07 AM, curriegrad2004 <curriegrad2004 at gmail.com>wrote:
> It would be beneficial if you can post the dialplan on how FS handles
> the part where FreeTDM comes into play. I.e. the dialplan that does
> the transfer of the FreeTDM call into the default context. This seems
> to be opening up a can of worms here with FXS cards in FreeTDM...
>
> On Wed, May 9, 2012 at 8:39 PM, Shane Harrison
> <shane.harrison at paragon.co.nz> wrote:
> > Happy for you to laugh at yourself, I'm just happy you are finding some
> time
> > to take some interest in my problem. Much appreciated.
> >
> > I think some clarity is required here. I am simply trying to do an
> attended
> > transfer as per the wiki (except I set the bind_meta_app to both legs)
> > http://wiki.freeswitch.org/wiki/Misc._Dialplan_Tools_att_xfer
> >
> > It works fine for SIP to SIP. For SIP to Freetdm it only works if the
> SIP
> > is trying to do the transfer. If the FreeTDM is trying to do it ie.
> push *3
> > on the phone keypad, then the bind_meta_app works fine and detects the *3
> > and executes the appropriate extension ie. att_xfer, however the read()
> in
> > the extension att_xfer does not see the subsequent DTMF pressed on the
> phone
> > ie. the destination extension number.
> >
> > Cheers
> > Shane
> >
> >
> > On Thu, May 10, 2012 at 2:44 PM, curriegrad2004 <
> curriegrad2004 at gmail.com>
> > wrote:
> >>
> >> I just had to laugh at my self for mixing up the 2 again...
> >> bind_meta_app is only applicable to that extension that the inbound
> >> call was made to. Since you've transferred to another extension, the
> >> bind_meta_app won't work anymore because it's not defined in the
> >> extension you're transferring to.
> >>
> >> If you want this to happen, you'd have to manually define that
> >> bind_meta_app to those target extensions too. Remember, do this at
> >> your own peril - obvious misuse of bind_meta_app can open a huge
> >> security hole if you don't know what you're doing :)
> >>
> >> On Wed, May 9, 2012 at 7:27 PM, Shane Harrison
> >> <shane.harrison at paragon.co.nz> wrote:
> >> > Thanks for the thoughts. As I said, I am already setting it to both
> >> > legs -
> >> > I will try simply trying one leg but am sceptical :-)
> >> >
> >> > I also mentioned that I called the start_dtmf just before calling the
> >> > read
> >> > so unless I am doing something wrong here..... I'll try and post the
> >> > XML
> >> > tonight when I get home. Oh and it is an FXS card not an FXO of
> course
> >> > since it has a phone plugged into it.
> >> >
> >> > The question still remains though, why is the in-band DTMF detection
> >> > working
> >> > for the bind_meta_app digit detection but not after that?
> >> >
> >> > Cheers
> >> > Shane
> >> >
> >> >
> >> > On Thu, May 10, 2012 at 12:28 PM, curriegrad2004
> >> > <curriegrad2004 at gmail.com>
> >> > wrote:
> >> >>
> >> >> and crap, since I wasn't even reading anything here, on the
> subsequent
> >> >> transfers from your FXO card, enable the in-band DTMF detector that
> FS
> >> >> has. The details on the in-band DTMF detector is here:
> >> >>
> >> >> http://wiki.freeswitch.org/wiki/Misc._Dialplan_Tools_start_dtmf
> >> >>
> >> >> But use this with caution, if there is a DTMF detector on the FXO
> card
> >> >> itself, make sure you disable it before using it.
> >> >>
> >> >> On Wed, May 9, 2012 at 5:26 PM, curriegrad2004
> >> >> <curriegrad2004 at gmail.com>
> >> >> wrote:
> >> >> > apologies for telling you the wrong thing. I was replying you from
> my
> >> >> > phone btw :P
> >> >> >
> >> >> > Yeah, bind_meta_app is the app you would use, but try changing it
> to
> >> >> > point to the b-leg, not the a-leg
> >> >> >
> >> >> > On Wed, May 9, 2012 at 4:12 PM, Shane Harrison
> >> >> > <shane.harrison at paragon.co.nz> wrote:
> >> >> >> Thanks. I am currently using bind_meta_app (set to both legs)
> >> >> >> already
> >> >> >> rather than bind_digits. I'll give bind_digits a shot and see if
> it
> >> >> >> behaves
> >> >> >> differently.
> >> >> >>
> >> >> >> Note that I do detect the initial *3 digits and because
> >> >> >> bind_meta_app
> >> >> >> is
> >> >> >> both legs, this is successful no matter which direction the call
> is
> >> >> >> setup
> >> >> >> from. However once the dialplan moves to the extension the *3 is
> >> >> >> bound
> >> >> >> to,
> >> >> >> digits are no longer received.
> >> >> >>
> >> >> >> The worrying thing for me is that ftdm_io.c doesn't even write to
> >> >> >> the
> >> >> >> log
> >> >> >> that it has received them (nor freetdm above that of course which
> is
> >> >> >> understandable) and I am surprised that the read() influences that
> >> >> >> since it
> >> >> >> works prior on the *3 digits.
> >> >> >>
> >> >> >> Cheers
> >> >> >> Shane
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> On Thu, May 10, 2012 at 10:22 AM, curriegrad2004
> >> >> >> <curriegrad2004 at gmail.com>
> >> >> >> wrote:
> >> >> >>>
> >> >> >>> I'm guessing the bind digits in your analog card was set to
> listen
> >> >> >>> for
> >> >> >>> this sequence on the a-leg given if the call was being routed
> from
> >> >> >>> the
> >> >> >>> IP side to the analog side.
> >> >> >>>
> >> >> >>> Try changing that to listen on the b-leg.
> >> >> >>>
> >> >> >>> On 5/9/12, Shane Harrison <shane at longwhitecloud.com> wrote:
> >> >> >>> > Hi All,
> >> >> >>> >
> >> >> >>> > Have a situation where I have a call between a SIP phone and a
> >> >> >>> > FreeTDM
> >> >> >>> > channel. Pushing *3 on the analog FreeTDM phone is detected
> and
> >> >> >>> > this
> >> >> >>> > is
> >> >> >>> > bound to a dialplan extension (attended transfer) that does a
> >> >> >>> > read():
> >> >> >>> > <action application="read" data="3 3
> >> >> >>> > 'tone_stream://%(10000,0,350,440)'
> >> >> >>> > digits 30000 #"/>
> >> >> >>> >
> >> >> >>> > However pushing further digits on the analog phone ie.
> extension
> >> >> >>> > number
> >> >> >>> > of
> >> >> >>> > phone we wish to do an attended transfer to , doesn't result in
> >> >> >>> > the
> >> >> >>> > DTMF
> >> >> >>> > being detected. Note that this all works the other way around
> >> >> >>> > ie.
> >> >> >>> > using
> >> >> >>> > the SIP phone.
> >> >> >>> >
> >> >> >>> > When the *3 digits are pushed on the analog phone I see the
> logs
> >> >> >>> > report:
> >> >> >>> >
> >> >> >>> > ftdm_io.c:3463 [s2c1][1:4] Queuing DTMF * (debug = 0)
> >> >> >>> > mod_freetdm.c:702 Queuing DTMF [*] in channel FreeTDM/2:1/
> >> >> >>> >
> >> >> >>> > ftdm_io.c:3463 [s2c1][1:4] Queuing DTMF 4 (debug = 0)
> >> >> >>> >
> >> >> >>> > mod_freetdm.c:702 Queuing DTMF [4] in channel FreeTDM/2:1/
> >> >> >>> >
> >> >> >>> > When the further keys are pushed ftdm_io reports nothing.
> >> >> >>> >
> >> >> >>> > I have tried inserting a start_dtmf before the read() but it
> had
> >> >> >>> > no
> >> >> >>> > effect.
> >> >> >>> > Any thoughts as to why DTMF isn't being seen from the analog
> >> >> >>> > phone
> >> >> >>> > after
> >> >> >>> > the read()?
> >> >> >>> >
> >> >> >>> > Cheers
> >> >> >>> > Shane
> >> >> >>> >
> >> >> >>>
> >> >> >>>
> >> >> >>>
> >> >> >>>
> _________________________________________________________________________
> >> >> >>> Professional FreeSWITCH Consulting Services:
> >> >> >>> consulting at freeswitch.org
> >> >> >>> http://www.freeswitchsolutions.com
> >> >> >>>
> >> >> >>>
> >> >> >>>
> >> >> >>>
> >> >> >>> Official FreeSWITCH Sites
> >> >> >>> http://www.freeswitch.org
> >> >> >>> http://wiki.freeswitch.org
> >> >> >>> http://www.cluecon.com
> >> >> >>>
> >> >> >>> FreeSWITCH-users mailing list
> >> >> >>> FreeSWITCH-users at lists.freeswitch.org
> >> >> >>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> >> >> >>>
> >> >> >>>
> >> >> >>> UNSUBSCRIBE:
> http://lists.freeswitch.org/mailman/options/freeswitch-users
> >> >> >>> http://www.freeswitch.org
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> --
> >> >> >> Paragon Electronic Design Ltd
> >> >> >> L6 Crest House
> >> >> >> 92 Queens Drive
> >> >> >> P0 Box 30449
> >> >> >> Lower Hutt 5040
> >> >> >>
> >> >> >> +64 4 5703870 Extn 875
> >> >> >> +64 21 608919 (mobile)
> >> >> >>
> >> >> >> "Solving your problems with the right technology"
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> _________________________________________________________________________
> >> >> >> Professional FreeSWITCH Consulting Services:
> >> >> >> consulting at freeswitch.org
> >> >> >> http://www.freeswitchsolutions.com
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> Official FreeSWITCH Sites
> >> >> >> http://www.freeswitch.org
> >> >> >> http://wiki.freeswitch.org
> >> >> >> http://www.cluecon.com
> >> >> >>
> >> >> >> FreeSWITCH-users mailing list
> >> >> >> FreeSWITCH-users at lists.freeswitch.org
> >> >> >> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> >> >> >>
> >> >> >>
> >> >> >> UNSUBSCRIBE:
> http://lists.freeswitch.org/mailman/options/freeswitch-users
> >> >> >> http://www.freeswitch.org
> >> >> >>
> >> >>
> >> >>
> >> >>
> _________________________________________________________________________
> >> >> Professional FreeSWITCH Consulting Services:
> >> >> consulting at freeswitch.org
> >> >> http://www.freeswitchsolutions.com
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> Official FreeSWITCH Sites
> >> >> http://www.freeswitch.org
> >> >> http://wiki.freeswitch.org
> >> >> http://www.cluecon.com
> >> >>
> >> >> FreeSWITCH-users mailing list
> >> >> FreeSWITCH-users at lists.freeswitch.org
> >> >> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> >> >>
> >> >> UNSUBSCRIBE:
> http://lists.freeswitch.org/mailman/options/freeswitch-users
> >> >> http://www.freeswitch.org
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > Paragon Electronic Design Ltd
> >> > L6 Crest House
> >> > 92 Queens Drive
> >> > P0 Box 30449
> >> > Lower Hutt 5040
> >> >
> >> > +64 4 5703870 Extn 875
> >> > +64 21 608919 (mobile)
> >> >
> >> > "Solving your problems with the right technology"
> >> >
> >> >
> >> >
> _________________________________________________________________________
> >> > Professional FreeSWITCH Consulting Services:
> >> > consulting at freeswitch.org
> >> > http://www.freeswitchsolutions.com
> >> >
> >> >
> >> >
> >> >
> >> > Official FreeSWITCH Sites
> >> > http://www.freeswitch.org
> >> > http://wiki.freeswitch.org
> >> > http://www.cluecon.com
> >> >
> >> > FreeSWITCH-users mailing list
> >> > FreeSWITCH-users at lists.freeswitch.org
> >> > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> >> > UNSUBSCRIBE:
> http://lists.freeswitch.org/mailman/options/freeswitch-users
> >> > http://www.freeswitch.org
> >> >
> >>
> >>
> _________________________________________________________________________
> >> Professional FreeSWITCH Consulting Services:
> >> consulting at freeswitch.org
> >> http://www.freeswitchsolutions.com
> >>
> >>
> >>
> >>
> >> Official FreeSWITCH Sites
> >> http://www.freeswitch.org
> >> http://wiki.freeswitch.org
> >> http://www.cluecon.com
> >>
> >> FreeSWITCH-users mailing list
> >> FreeSWITCH-users at lists.freeswitch.org
> >> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> >> UNSUBSCRIBE:
> http://lists.freeswitch.org/mailman/options/freeswitch-users
> >> http://www.freeswitch.org
> >
> >
> >
> >
> > --
> > Paragon Electronic Design Ltd
> > L6 Crest House
> > 92 Queens Drive
> > P0 Box 30449
> > Lower Hutt 5040
> >
> > +64 4 5703870 Extn 875
> > +64 21 608919 (mobile)
> >
> > "Solving your problems with the right technology"
> >
> > _________________________________________________________________________
> > Professional FreeSWITCH Consulting Services:
> > consulting at freeswitch.org
> > http://www.freeswitchsolutions.com
> >
> >
> >
> >
> > Official FreeSWITCH Sites
> > http://www.freeswitch.org
> > http://wiki.freeswitch.org
> > http://www.cluecon.com
> >
> > FreeSWITCH-users mailing list
> > FreeSWITCH-users at lists.freeswitch.org
> > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> > http://www.freeswitch.org
> >
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
>
>
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
--
Paragon Electronic Design Ltd
L6 Crest House
92 Queens Drive
P0 Box 30449
Lower Hutt 5040
+64 4 5703870 Extn 875
+64 21 608919 (mobile)
"Solving your problems with the right technology"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20120511/fd602081/attachment-0001.html
Join us at ClueCon 2011 Aug 9-11, 2011
More information about the FreeSWITCH-users
mailing list