This is valid for playback, gentones, record and speak
value may be a string of valid terminator characters, or the word 'none'
the default of * will always work unless overridden by 'none'. This is for backward compat.
<extension name="8000">
<condition field="destination_number" expression="^8000$">
<action application="answer"/>
<!--both * and # will stop the playback-->
<action application="set" data="playback_terminators=#*"/>
<action application="playback" data="/ram/swimp.raw"/>
</condition>
</extension>
git-svn-id: http://svn.freeswitch.org/svn/freeswitch/trunk@5888 d0543943-73ff-0310-b7d9-9358b9ac24b2
fire SWITCH_EVEHT_CHANNEL_EXECUTE
<execute app>
fire SWITCH_EVEHT_CHANNEL_EXECUTE_COMPLETE
This can be used in async socket connections to tell
when a queued application has finished executing.
Add the "event" application to the dialplan:
<action application="event" data="header1=val1,header2=val2"/>
Events fired from this applcation will always have the type SWITCH_EVENT_CHANNEL_APPLICATION.
You can add up to 25 headers of your own to the event via the application arguements.
git-svn-id: http://svn.freeswitch.org/svn/freeswitch/trunk@5448 d0543943-73ff-0310-b7d9-9358b9ac24b2
This patch adds a scheduler thread to the core and moves the heartbeat
event to use the new scheduler as an example.
Also The following features are implemented that use this scheduler:
sched_hangup dialplan application:
<action application="sched_hangup" data="+10 normal_clearing bleg"/>
** The cause code is optional and the optional bleg keyword will only hangup the
channel the current channel is bridged to if the call is in a bridge.
sched_transfer dialplan application:
<action application="sched_transfer" data="+10 1000 XML default"/>
** The last 2 args (dialplan and context) are optional
sched_broadcast dialplan application:
<action application="sched_broadcast" data="+10 playback:/tmp/foo.wav"/>
<action application="sched_broadcast" data="+10 playback!normal_clearing:/tmp/foo.wav"/>
** The optional !<cause_code> can be added to make the channel hangup after broadcasting the file.
sched_hangup api function:
sched_hangup +10 <uuid_string> normal_clearing
** The cause code is optional
sched_transfer api function:
sched_transfer +10 <uuid_string> 1000 XML default
** The last 2 args (dialplan and context) are optional
sched_broadcast api function:
sched_broadcast +10 <uuid_str> playback:/tmp/foo.wav
sched_broadcast +10 <uuid_str> playback!normal_clearing:/tmp/foo.wav
** The optional !<cause_code> can be added to make the channel hangup after broadcasting the file.
The new C functions in the core are documented in the doxeygen.
*NOTE* This commit should satisfy at least 2 bounties on the wiki
git-svn-id: http://svn.freeswitch.org/svn/freeswitch/trunk@4785 d0543943-73ff-0310-b7d9-9358b9ac24b2
change most char * values in ivr_menu functions to const char *
change switch_core_strdup to get passed const char * instead of char *
change switch_xml_find_child to get passed const char * instead of char *
change the ivr dialplan application to free the xml config as soon as it is done building the xml menu and not hold it until the menu is done being run, so that you can do a reloadxml while someone is in a menu without blocking.
git-svn-id: http://svn.freeswitch.org/svn/freeswitch/trunk@4260 d0543943-73ff-0310-b7d9-9358b9ac24b2
This changes the core to have the necessary tools to create
a speech detection interface.
It also changes the code in javascript (mod_spidermonkey)
there are a few api changes in how it handles callbacks
It also adds grammars as a system dir to store asr grammars
git-svn-id: http://svn.freeswitch.org/svn/freeswitch/trunk@3291 d0543943-73ff-0310-b7d9-9358b9ac24b2
BTW, forget what I said yesterday RE: the strftime app I was at McDonalds, how can I concentrate there eh?
see below....
The Definitive Guide To XML Dialplan:
The "dialplan" section of the freeswitch.xml meta document may contain several contexts
<?xml version="1.0"?>
<document type="freeswitch/xml">
<section name="dialplan" description="Regex/XML Dialplan">
<!-- the default context is a safe start -->
<context name="default">
<!-- one or more extension tags -->
</context>
<!-- more optional contexts -->
</section>
</document>
The important thing to remember is that the dialplan is parsed once when the call
hits the dialplan parser in the RING state. With one pass across the XML the result
will be a complete list of instructions installed into the channel based on
parsed <action> or <anti-action> tags.
Those accustomed to Asterisk may expect the call to follow the dialplan by executing the
applications as it parses them allowing data obtained from one action to influence the next action.
This not the case with the exception being the %{api func} {api arg} field type where an pluggable api call from
a module may be executed as the parsing occurs but this is meant to be used to draw realtime info such as
date and time or other quickly accessible information and shold *not* be abused.
The anatomy of an <extension> tag.
Legend:
Text wrapped in [] indicates optional and is not part of the actual code.
a '|' inside [] indicates mutiple possible values and also is not part of the code.
Text wrapped in {} indicates it's a description of the parameter in place of the param itself.
<extension name="{exten_name}" [continue="[true|false]"]>
continue=true means even if an extension executes to continue
parsing the next extension too
The {exten_name} above may anything but if it's
an exact match with the destination number the parser will leap to this extension
to begin the searching that does not mean it will execute the extension.
Searching will either begin at the first extension in the context or at the point
the the parser has jumped to in the case described above.
Each condition is parsed in turn first taking the 'field' param.
The parser will apply the perl regular expression to each 'field' param encountered.
If the expression matches, it will parse each existing <action> tag in turn and add
the data from the <application> tags to the channels todo list.
If a matched expression contains any data wrapped in () the variables
$1,$2..$N will be valid and expanded in any of 'data' params from the subsequent action tags.
If the expression does NOT match, it will parse each <anti-action> tag in turn and add
the data from the <application> tags to the channels todo list.
*NOTE* since there was no match the () feature is not availabe in anti-actions
The 'break' param indicates how to behave in relation to matching:
*) 'on-true' - stop searching conditions after the first successful match.
*) 'on-false' - stop searching after the first unsuccessful match.
*) 'always' - stop at this conditon regardless of a match or non-match.
*) 'never' - continue searching regardless of a match or non-match.
<condition field="[{field name}|${variable name}|%{api func} {api arg}]" expression="{expression}" break="[on-true|on-false|always|never]">
<action application="{app name}" data="{app arg}"/>
<anti-action application="{app name}" data="{app arg}"/>
</condition>
<!-- any number of condition tags may follow where the same rules apply -->
</extension>
git-svn-id: http://svn.freeswitch.org/svn/freeswitch/trunk@2167 d0543943-73ff-0310-b7d9-9358b9ac24b2
Use in the dialplan like so:
<!-- continue="true" means keep searching even when you have a match -->
<extension name="set-date" continue="true">
<condition>
<action application="strftime" data="NOW=%H:%M"/>
</condition>
</extension>
<extension name="route-date">
<condition field="$NOW" expression="^0[34].*">
<action application="playback" data="/tmp/cluecon1.wav"/>
</condition>
</extension>
git-svn-id: http://svn.freeswitch.org/svn/freeswitch/trunk@2144 d0543943-73ff-0310-b7d9-9358b9ac24b2
Michael Jerris