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
This modification makes it possible to change the media path of session in the switch on-the-fly and from the dialplan.
It adds some API interface calls usable from a remote client such as mod_event_socket or the test console.
1) media [off] <uuid>
Turns on/off the media on the call described by <uuid>
The media will be redirected as desiered either into the switch or point to point.
2) hold [off] <uuid>
Turns on/off endpoint specific hold state on the session described by <uuid>
3) broadcast <uuid> "<path>[ <timer_name>]" or "speak:<tts_engine>|<tts_voice>|<text>[|<timer_name>]" [both]
A message will be sent to the call described by uuid instructing it to play the file or speak the text indicated.
If the 'both' option is specified both ends of the call will hear the message otherwise just the uuid specified
will hear the message.
During playback when only one side is hearing the message the other end will hear silence.
If media is not flowing across the switch when the message is broadcasted, the media will be directed to the
switch for the duration of the call and then returned to it's previous state.
Also the no_media=true option in the dialplan before a bridge makes it possible to place a call while proxying the session
description from one endpoint to the other and establishing an immidiate point-to-point media connection with no media
on the switch.
<action application="set" data="no_media=true"/>
<action application="bridge" data="sofia/mydomain.com/myid@myhost.com"/>
*NOTE* when connecting two outbound legs by using the "originate" api command with an extension that has no_media=true enabled,
the media for the first leg will be engaged with the switch until the second leg has answered and the other session description
is available to establish a point to point connection at which time point-to-point mode will be enabled.
*NOTE* it is reccommended you rebuild FreeSWITCH with "make sure" as there have been some changes to the core.
git-svn-id: http://svn.freeswitch.org/svn/freeswitch/trunk@3245 d0543943-73ff-0310-b7d9-9358b9ac24b2
Transfers work better when both legs of the call live in thier own channel eg bridged calls
A -> B where you want a to make B -> C
when you route a call to an IVR or playback app you are not really bridging you have
A all alone executing the script so it's hard to transfer that.
I do have it aparently working but it's goofy and you are better off
putting your IVR on it's own switch so they are all inbound calls
then you have A -> B -> IVR
now A can happily transfer B who can stay on line with IVR without stopping
the execution. You can also accomplish this by calling in a loop back to the same box
if you dont want to have 2 boxes.
Also the beginning effort at bridging calls with no media is here
set this magic variable in your dialplan to convince mod_sofia
to pass A's sdp as it's own to B and return B's sdp back to A on 200 or 183
<action application="set" data="no_media=true"/>
<action application="bridge" data="sofia/id@host.com"/>
You will need a new sofia tarball for this version
There is a bunch of other odds and ends added like a function or 2 etc
Oh,
And don't be suprised if it introduces all kinds of bugs!
git-svn-id: http://svn.freeswitch.org/svn/freeswitch/trunk@2992 d0543943-73ff-0310-b7d9-9358b9ac24b2
This is the primary commit to add bugs to the core (media bugs that is)
Media bugs are kind of like what ChanSpy is in Asterisk only cooler (I wrote ChanSpy too so I can say that)
Here is an example of using them to record a call by the higher level switch_ivr functionality passed
up to the dialplan via mod_playback.
The call will be recorded while the some.wav plays then stop for the rest of the call (when some_other.wav plays)
The bugs may have bugs since this is 1 day's work so happy hunting ......
<extension name="42">
<condition field="destination_number" expression="^42$">
<action application="set" data="RECORD_TITLE=recording test"/>
<action application="set" data="RECORD_ARTIST=FreeSWITCH"/>
<action application="record_session" data="/tmp/rtest.wav"/>
<action application="playback" data="/tmp/some.wav"/>
<action application="stop_record_session" data="/tmp/rtest.wav"/>
<action application="playback" data="/tmp/some_other.wav"/>
</condition>
</extension>
git-svn-id: http://svn.freeswitch.org/svn/freeswitch/trunk@2588 d0543943-73ff-0310-b7d9-9358b9ac24b2
adding mod_park for putting channels in limbo state for remote control.
adding stuff to mod_event_socket to let you do the bgapi <command> <args>
this will let you execute a job in the bg and the result will be sent as an event with an
indicated uuid to match the reply to the command
adding switch_core_port_allocator (to be used soon)
adding "make sure" to do a full rebild of the freeswitch object files
There will be more to this committed as the week progresses
make sure you do a rebuild after this update or you'll be sowwie
./configure && make sure
git-svn-id: http://svn.freeswitch.org/svn/freeswitch/trunk@2540 d0543943-73ff-0310-b7d9-9358b9ac24b2
Ok,
This one adds a bunch of stuff on top of the framework restructuring from yesterday.
1) originate api function:
Usage: originate <call url> <exten> [<dialplan>] [<context>] [<cid_name>] [<cid_num>] [<timeout_sec>]
This will call the specified url then transfer the call to the specified extension
example: originate exosip/1000@somehost 1000 XML default
2) mutiple destinations in outbound calls:
This means any dialstring may contain an '&' separated list of call urls
When using mutiple urls in this manner it is possible to map a certian key as required
indication of an accepted call. You may also supply a filename to play possibly instructing the
call recipiant to press the desired key etc...
The example below will call 2 locations playing prompt.wav to any who answer and
completing the call to the first offhook recipiant to dial "4"
<extension name="3002">
<condition field="destination_number" expression="^3002$">
<action application="set" data="call_timeout=60"/>
<action application="set" data="group_confirm_file=/path/to/prompt.wav"/>
<action application="set" data="group_confirm_key=4"/>
<action application="bridge" data="iax/guest@somebox/1234&exosip/1000@somehost"/>
</condition>
</extension>
The following is the equivilant but the confirm data is passed vial the bridge parameters
(This is for situations where there is no originating channel to set variables to)
<extension name="3002">
<condition field="destination_number" expression="^3002$">
<action application="bridge" data=/path/to/prompt.wav:4"confirm=iax/guest@somebox/1234&exosip/1000@somehost"/>
</condition>
</extension>
Omitting the file and key stuff will simply comeplete the call to whoever answers first.
(this is similar to how other less fortunate software handles the situation with thier best effort.)
This logic should be permitted in anything that establishes an outgoing call with
switch_ivr_originate()
Yes! That means even in this new originate api command you can call mutiple targets and send
whoever answers first to an extension that calls more mutiple targets. (better test it though!)
Oh, and you should be able to do the same in the mod_conference dial and dynamic conference features
please report any behaviour contrary to this account to me ASAP cos i would not be terribly
suprised if I forgot some scenerio that causes an explosion I did all this in 1 afternoon so it probably needs tuning still.
git-svn-id: http://svn.freeswitch.org/svn/freeswitch/trunk@2311 d0543943-73ff-0310-b7d9-9358b9ac24b2
in dialplan (ivrtest <path to file>)
if the file is valid it will play the file and you will be expected to dial digits
until you dial 10 digits or press # or * (* will end the call) (# will repeat the test endlessly)
git-svn-id: http://svn.freeswitch.org/svn/freeswitch/trunk@462 d0543943-73ff-0310-b7d9-9358b9ac24b2
Michael Jerris