macros for performing repeated dialplan actions?
Hi again, I'm trying to build up a soho dialplan to replicate an existing Asterisk setup I want to replace. I'm editing /usr/local/freeswitch/conf/dialplan/default/00_mydomain.com.xml to add some dialplan rules for various destination numbers I'm using. These dialplans may use one of several gateways I have configured. I currently have: <include> <extension name="spanish_mobiles.mydomain.com"> <condition field="destination_number" expression="^(6\d{8})$"> <action application="set" data="effective_caller_id_number=${outbound_caller_id_number}"/> <action application="set" data="effective_caller_id_name=${outbound_caller_id_name}"/> <action application="bridge" data="sofia/gateway/asterisk/$1"/> </condition> </extension> <extension name="spanish_fijos.mydomain.com"> <condition field="destination_number" expression="^(9\d{8})$"> <action application="set" data="effective_caller_id_number=${outbound_caller_id_number}"/> <action application="set" data="effective_caller_id_name=${outbound_caller_id_name}"/> <action application="bridge" data="sofia/gateway/asterisk/$1"/> </condition> </extension> ... more stuff not shown ... </include> Which routes out to my existing asterisk installation. I now want to record all calls. Looking at http://wiki.freeswitch.org/wiki/Misc._Dialplan_Tools_record_session it seems I need to add a section like into each entry prior to the application="bridge". <action application="set" data="gateway_name=XXXXX"/> <action application="set" data="RECORD_TITLE=Recording ${destination_number} ${caller_id_number} ${strftime(%Y-%m-%d %H:%M)}"/> <action application="set" data="RECORD_COPYRIGHT=(C) 2009 my data here."/> <action application="set" data="RECORD_SOFTWARE=FreeSwitch"/> <action application="set" data="RECORD_ARTIST=My name"/> <action application="set" data="RECORD_COMMENT=My comment"/> <action application="set" data="RECORD_DATE=${strftime(%Y-%m-%d %H:%M)}"/> <action application="set" data="RECORD_STEREO=true"/> <action application="record_session" data="$${base_dir}/recordings/${gateway_name}_${strftime(%Y-%m-%d-%H-%M-%S)}_${destination_number}_${caller_id_number}.wav"/> My question is how do I avoid repeatedly using these same 8-9 lines and "merge" this into some macro which given the right parameters allows me to define various extensions using different gateways but all configured "the same way"? Thanks for any pointers to how this should be done. Simon
On Wed, Oct 14, 2009 at 3:01 PM, Simon J Mudd <sjmudd@pobox.com> wrote:
Hi again,
I'm trying to build up a soho dialplan to replicate an existing Asterisk setup I want to replace.
I'm editing /usr/local/freeswitch/conf/dialplan/default/00_mydomain.com.xml to add some dialplan rules for various destination numbers I'm using. These dialplans may use one of several gateways I have configured.
I currently have:
<include> <extension name="spanish_mobiles.mydomain.com"> <condition field="destination_number" expression="^(6\d{8})$"> <action application="set" data="effective_caller_id_number=${outbound_caller_id_number}"/> <action application="set" data="effective_caller_id_name=${outbound_caller_id_name}"/> <action application="bridge" data="sofia/gateway/asterisk/$1"/> </condition> </extension>
<extension name="spanish_fijos.mydomain.com"> <condition field="destination_number" expression="^(9\d{8})$"> <action application="set" data="effective_caller_id_number=${outbound_caller_id_number}"/> <action application="set" data="effective_caller_id_name=${outbound_caller_id_name}"/> <action application="bridge" data="sofia/gateway/asterisk/$1"/> </condition> </extension>
... more stuff not shown ...
</include>
Which routes out to my existing asterisk installation.
I now want to record all calls. Looking at http://wiki.freeswitch.org/wiki/Misc._Dialplan_Tools_record_session it seems I need to add a section like into each entry prior to the application="bridge".
<action application="set" data="gateway_name=XXXXX"/>
<action application="set" data="RECORD_TITLE=Recording ${destination_number} ${caller_id_number} ${strftime(%Y-%m-%d %H:%M)}"/> <action application="set" data="RECORD_COPYRIGHT=(C) 2009 my data here."/> <action application="set" data="RECORD_SOFTWARE=FreeSwitch"/> <action application="set" data="RECORD_ARTIST=My name"/> <action application="set" data="RECORD_COMMENT=My comment"/> <action application="set" data="RECORD_DATE=${strftime(%Y-%m-%d %H:%M)}"/> <action application="set" data="RECORD_STEREO=true"/> <action application="record_session" data="$${base_dir}/recordings/${gateway_name}_${strftime(%Y-%m-%d-%H-%M-%S)}_${destination_number}_${caller_id_number}.wav"/>
My question is how do I avoid repeatedly using these same 8-9 lines and "merge" this into some macro which given the right parameters allows me to define various extensions using different gateways but all configured "the same way"?
Thanks for any pointers to how this should be done.
Try using the execute_extension app. It's kinda like a gosub in BASIC: it'll go and execute an extension and then come back and continue executing. Put all those lines into a single extension and then call them from other extensions via execute_extension. -MC
Hi Michael, msc@freeswitch.org (Michael Collins) writes:
On Wed, Oct 14, 2009 at 3:01 PM, Simon J Mudd <sjmudd@pobox.com> wrote:
I'm trying to build up a soho dialplan to replicate an existing Asterisk setup I want to replace.
...
My question is how do I avoid repeatedly using these same 8-9 lines and "merge" this into some macro which given the right parameters allows me to define various extensions using different gateways but all configured "the same way"?
Thanks for any pointers to how this should be done.
Try using the execute_extension app. It's kinda like a gosub in BASIC: it'll go and execute an extension and then come back and continue executing. Put all those lines into a single extension and then call them from other extensions via execute_extension.
OK. That looks clear. However it doesn't look as if it's possible to pass parameters this way which means that data can only be passed to the "extension" via variables. That works but isn't so clean. I'll check this out further shortly. I'm planning later to pass info like "which gateway to talk to" and perhaps some sort of flag which indicates "record: yes/no", and even include the bridge application into this extension/macro. That reduces the original dialplan pattern matching to a much simpler and easier to configure setup for me. excecute_extension does avoid a lot of redundancy, so thanks for the pointer. I'll get that working first. Simon
On Oct 15, 2009, at 11:03 AM, Simon J Mudd wrote:
OK. That looks clear. However it doesn't look as if it's possible to pass parameters this way which means that data can only be passed to the "extension" via variables. That works but isn't so clean. I'll check this out further shortly. I'm planning later to pass info like "which gateway to talk to" and perhaps some sort of flag which indicates "record: yes/no", and even include the bridge application into this extension/macro. That reduces the original dialplan pattern matching to a much simpler and easier to configure setup for me.
here's a tip from a recovering asterisk user: don't feel like you have to do everything via the dialplan. this was a constant mantra in asterisk, because calling AGI scripts was expensive. this is not the case with FreeSWITCH. the general rule of thumb is: as soon as it gets hard to do in the dialplan, farm it out to a script. it's the way FreeSWITCH is designed, so don't fight it ;) that said, you still might be able to use execute_extension along with setting some channel variables before you call it. those channel variables will be available in the executed extension, and can act pretty much like the arguments to a macro.
chad@apartmentlines.com (Chad Phillips -- Apartment Lines) writes:
On Oct 15, 2009, at 11:03 AM, Simon J Mudd wrote:
OK. That looks clear. However it doesn't look as if it's possible to pass parameters this way which means that data can only be passed to the "extension" via variables. That works but isn't so clean. I'll check this out further shortly. I'm planning later to pass info like "which gateway to talk to" and perhaps some sort of flag which indicates "record: yes/no", and even include the bridge application into this extension/macro. That reduces the original dialplan pattern matching to a much simpler and easier to configure setup for me.
here's a tip from a recovering asterisk user: don't feel like you have to do everything via the dialplan. this was a constant mantra in asterisk, because calling AGI scripts was expensive. this is not the case with FreeSWITCH. the general rule of thumb is: as soon as it gets hard to do in the dialplan, farm it out to a script. it's the way FreeSWITCH is designed, so don't fight it ;)
OK. That makes a lot of sense. Perhaps I'm just missing examples to copy which do some of the things I want to do. Since there are indications on this list that FreeSWITCH can do many things the changeover from Asterisk to FreeSWITCH is quite difficult at least once you start to try and do more complex things. I've other plans like: 1. choose the cheapest gateway based on some scripts which download rates from the various gateways web pages and let me compare rates. Hard partly as the "charges pages" aren't designed to allow me to match a number to a charge. Shame the VoIP community can't come up with a common format "charge/rate file" to make this easier. 2. Try one gateway and if that fails try another one. Many of the gateways I've been using are low cost and don't always work, so to avoid me having to adjust things each time this might be useful. 3. Remove a lot of the "intelligence" about what to do to a backend script/program or whatever which decides how to route calls and tells FreeSWITCH what it decides. This may not scale for a large setup but for SOHO is never going to be an issue. It also avoids me writing so many xml configuration files which seems to get spread all over various places of the conf/ tree. However I've still got a lot of experimenting to do yet. Simon
On Sat, Oct 17, 2009 at 1:44 AM, Simon J Mudd <sjmudd@pobox.com> wrote:
I've other plans like:
1. choose the cheapest gateway based on some scripts which download rates from the various gateways web pages and let me compare rates. Hard partly as the "charges pages" aren't designed to allow me to match a number to a charge. Shame the VoIP community can't come up with a common format "charge/rate file" to make this easier.
Look at mod_lcr. The only part you have to write is the part that loads the database from your providers.
2. Try one gateway and if that fails try another one. Many of the gateways I've been using are low cost and don't always work, so to avoid me having to adjust things each time this might be useful.
bridge to ${lcr_auto_route} after calling the lcr application.
3. Remove a lot of the "intelligence" about what to do to a backend script/program or whatever which decides how to route calls and tells FreeSWITCH what it decides. This may not scale for a large setup but for SOHO is never going to be an issue. It also avoids me writing so many xml configuration files which seems to get spread all over various places of the conf/ tree.
This is for incoming calls to your DIDs? Or something else? I'm not sure what you mean here.
However I've still got a lot of experimenting to do yet.
Simon
-- -Rupa
rupa@rupa.com (Rupa Schomaker) writes:
On Sat, Oct 17, 2009 at 1:44 AM, Simon J Mudd <sjmudd@pobox.com> wrote:
I've other plans like:
1. choose the cheapest gateway based on some scripts which download rates from the various gateways web pages and let me compare rates. Hard partly as the "charges pages" aren't designed to allow me to match a number to a charge. Shame the VoIP community can't come up with a common format "charge/rate file" to make this easier.
Look at mod_lcr. The only part you have to write is the part that loads the database from your providers.
Sounds good. Thanks for the pointer.
2. Try one gateway and if that fails try another one. Many of the gateways I've been using are low cost and don't always work, so to avoid me having to adjust things each time this might be useful.
bridge to ${lcr_auto_route} after calling the lcr application.
You make it sound easy in FreeSWITCH. :-)
3. Remove a lot of the "intelligence" about what to do to a backend script/program or whatever which decides how to route calls and tells FreeSWITCH what it decides. This may not scale for a large setup but for SOHO is never going to be an issue. It also avoids me writing so many xml configuration files which seems to get spread all over various places of the conf/ tree.
This is for incoming calls to your DIDs? Or something else? I'm not sure what you mean here.
Well it seems/ed that the dialplan actions and xml files get complex if you want to do anything complicated. however it seems that I'm doing things the wrong way and perhaps that's part of the problem. I'll look at the mod_lcr and see how it works. Thanks for the pointers. Simon
participants (4)
-
Chad Phillips -- Apartment Lines
-
Michael Collins
-
Rupa Schomaker
-
Simon J Mudd