FreeSWITCH: Utilizing the Built-in IVR Engine

Exclusive offer: get 50% off this eBook here
FreeSWITCH 1.0.6

FreeSWITCH 1.0.6 — Save 50%

Build robust high-performance telephony systems using FreeSWITCH

$23.99    $12.00
by Anthony Minessale Darren Schreiber Michael S. Collins | August 2010 | Open Source

The built-in IVR (Interactive Voice Response) engine is a powerful component of the FreeSWITCH system. It allows messages to be played and interactive responses (usually touch-tones) to be processed, in order to direct calls to particular destinations. It can ultimately allow callers to hear information without needing to speak to a live person, select options that enable/disable features, or enter data that can be used in account, billing, or other operations.

Most people are familiar with an IVR as an auto-attendant that answers a main number for your company and provides a list of options to reach people (that is, 'For sales press 1, for support press 2'). This avoids disruptions to unintended call recipients, and reduces or removes the need for a dedicated receptionist. More advanced IVRs can also be used for collecting information from a caller, such as a caller's account number or the PIN number for a conference bridge. In this article by Anthony Minessale, Michael S. Collins and Darren Schreiber, authors of the book FreeSWITCH 1.0.6, we will cover the following topics:

  • IVR Engine Overview
  • IVR XML Configuration File
  • IVR Menu Definitions
  • IVR Menu Destinations
  • Routing Calls to Your IVR
  • Nesting IVRs
  • Using Phrases with IVRs
  • Advanced Topics

IVR engine overview

Unlike many applications within FreeSWITCH which are built as modules, IVR is considered the core functionality of FreeSWITCH. It is used anytime a prompt is played and digits are collected. Even if you are not using the IVR application itself from your Dialplan, you will see IVR-related functions being utilized from various other applications. As an example, the voicemail application makes heavy use of IVR functionality when playing messages, while awaiting digits to control deleting, saving, and otherwise managing voicemails.

In this section, we will only be reviewing the IVR functionality that is exposed from within the ivr Dialplan application. This functionality is typically used to build an auto-attendant menu, although other functions are possible as well.

IVR XML configuration file

FreeSWITCH ships with a sample IVR menu are typically invoked by dialing 5000 from the sample Dialplan. When you dial 500, you will hear a greeting welcoming you to FreeSWITCH, and presenting your menu options. The menu options consist of calling the FreeSWITCH conference, calling the echo extension, hearing music on hold, going to a sub menu, or listening to screaming monkeys. We will start off reviewing the XML that powers this example.

Open conf/autoload_configs/ivr.xml which contains the following XML:

<configuration name="ivr.conf" description="IVR menus">
<menus>
<!-- demo IVR, Main Menu -->
<menu name="demo_ivr"
greet-long="phrase:demo_ivr_main_menu"
greet-short="phrase:demo_ivr_main_menu_short"
invalid-sound="ivr/ivr-that_was_an_invalid_entry.wav"
exit-sound="voicemail/vm-goodbye.wav"
timeout="10000"
inter-digit-timeout="2000"
max-failures="3"
max-timeouts="3"
digit-len="4">
<entry action="menu-exec-app" digits="1" param="bridge
sofia/$${domain}/888@conference.freeswitch.org"/>
<entry action="menu-exec-app" digits="2" param="transfer 9196
XML default"/>
<entry action="menu-exec-app" digits="3" param="transfer 9664
XML default"/>
<entry action="menu-exec-app" digits="4" param="transfer 9191
XML default"/>
<entry action="menu-exec-app" digits="5" param="transfer
1234*256 enum"/>
<entry action="menu-exec-app" digits="/^(10[01][0-9])$/"
param="transfer $1 XML features"/>
<entry action="menu-sub" digits="6" param="demo_ivr_submenu"/>
<entry action="menu-top" digits="9"/>
</menu>

<!-- Demo IVR, Sub Menu -->
<menu name="demo_ivr_submenu"
greet-long="phrase:demo_ivr_sub_menu"
greet-short="phrase:demo_ivr_sub_menu_short"
invalid-sound="ivr/ivr-that_was_an_invalid_entry.wav"
exit-sound="voicemail/vm-goodbye.wav"
timeout="15000"
max-failures="3"
max-timeouts="3">
<entry action="menu-top" digits="*"/>
</menu>

</menus>
</configuration>

In the preceding example, there are two IVR menus defined. Let's break apart the first one and examine it, starting with the IVR menu definition itself.

IVR menu definitions

The following XML defines an IVR menu named "demo_ivr".

<menu name="demo_ivr"
greet-long="phrase:demo_ivr_main_menu"
greet-short="phrase:demo_ivr_main_menu_short"
invalid-sound="ivr/ivr-that_was_an_invalid_entry.wav"
exit-sound="voicemail/vm-goodbye.wav"
timeout="10000"
inter-digit-timeout="2000"
max-failures="3"
max-timeouts="3"
digit-len="4">

We'll use this menu's name later when we route calls to the IVR from the Dialplan. Following the name, various XML attributes specify how the IVR will behave. The following options are available when defining an IVR's options:

greet-long

The greet-long attribute specifies the initial greeting that is played when a caller reaches the IVR. This is different from the greet-short sound file which allows for introductions to be played, such as "Thank you for calling XYZ Company". In the sample IVR, the greet-long attribute is a Phrase Macro that plays an introductory message to the caller ("Welcome to FreeSWITCH...") followed by the menu options the caller may choose from.

Argument syntax: Sound file name (or path + name), TTS, or Phrase Macro

Examples:

greet-long="my_greeting"
greet-long="phrase:my_greeting_phrase"
greet-long="say:Welcome to our company. Press 1 for sales, 2 for
support."

greet-short

The greet-short attribute specifies the greeting that is re-played if the caller enters invalid information, or no information at all. This is typically the same sound file as greet-long without the introduction. In the sample IVR, the greet-short attribute is a Phrase Macro that simply plays the menu options to the caller, and does not play the lengthy introduction found in greet-long.

Argument syntax: Sound file name (or path + name), TTS, or Phrase Macro

Examples:

greet-short="my_greeting_retry"
greet-long="phrase:my_greeting_retry_phrase"
greet-long="say:Press 1 for sales, 2 for support."

invalid-sound

The invalid-sound attribute specifies the sound that is played when a caller makes an invalid entry.

Argument syntax: Sound file name (or path + name), TTS, or Phrase Macro

Examples

invalid-sound="invalid_entry.wav"
invalid-sound="phrase:my_invalid_entry_phrase"
invalid-sound="say:That was not a valid entry"

exit-sound

The exit-sound attribute specifies the sound, which is played when a caller makes too many invalid entries or too many timeouts occur. This file is played before disconnecting the caller.

Argument syntax: Any number, in milliseconds

Examples:

exit-sound="too_many_bad_entries.wav"
exit-sound="phrase:my_too_many_bad_entries_phrase"
exit-sound="say:Hasta la vista, baby."

timeout

The timeout attribute specifies the maximum amount of time to wait for the user to begin entering digits after the greeting has played. If this time limit is exceeded, the menu is repeated until the value in the max-timeouts attribute has been reached.

Argument syntax: Any number, in milliseconds

Examples:

timeout="10000"
timeout="20000"

inter-digit-timeout

The inter-digit-timeout attribute specifies the maximum amount of time to wait in-between each digit the caller presses. This is different from the overall timeout.It is useful to allow enough time to enter as many digits as necessary, without frustrating the caller by pausing too long after they are done making their entry. For example, if both 1000 and 1 are valid IVR entries, the system will continue waiting for the inter-digit-timeout length of time after 1 is entered, before determining that it is the final entry.

Argument syntax: Any number, in milliseconds

Examples:

inter-digit-timeout="2000"

max-failures

The max-failures attribute specifies how many failures, due to invalid entries, to tolerate before disconnecting.

Argument syntax: Any number

Examples:

xx-xx="too_many_bad_entries.wav"
xx-xx="phrase:my_too_many_bad_entries_phrase"

max-timeouts

The max-timeouts attribute specifes how many timeouts to tolerate before disconnecting.

Argument syntax: Any number

Examples:

max-timeouts="3"

digit-len

The digit-len attribute specifes the maximum number of digits that the user can enter before determining the entry is complete.

Argument syntax: Any number greater than 1.

Examples:

digit-len="4"

tts-voice

The tts-voice attribute specifes the specifc text-to-speech voice that should be used.

Argument syntax: Any valid text-to-speech engine.

Examples:

tts-voice="Mary"

tts-engine

The tts-engine attribute specifies the specific text-to-speech engine that should be used.

Argument syntax: Any valid text-to-speech engine.

Examples:

tts-engine="flite"

confirm-key

The confirm-key attribute specifes the key which the user can press to signify that they are done entering information.

Argument syntax: Any valid DTMF digit.

Examples:

confirm-key="#"

These attributes dictate the general behavior of the IVR.

IVR menu destinations

After defining the global attributes of the IVR, you need to specify what specific destinations (or options) are available for the caller to press. You do this with <entry > XML elements. Let's review the first five XML options used by this IVR:

<entry action="menu-exec-app" digits="1" param="bridge
sofia/$${domain}/888@conference.freeswitch.org"/>
<entry action="menu-exec-app" digits="2" param="transfer 9196 XML
default"/>
<entry action="menu-exec-app" digits="3" param="transfer 9664 XML
default"/>
<entry action="menu-exec-app" digits="4" param="transfer 9191 XML
default"/>
<entry action="menu-exec-app" digits="5" param="transfer 1234*256
enum"/>
<entry action="menu-exec-app" digits="/^(10[01][0-9])$/"
param="transfer $1 XML features"/>

Each preceding entry defines three parameters—an action to be taken, the digits the caller must press to activate that action, and the parameters that are passed to the action. In most cases you will probably use the menu-exec-app action, which simply allows you to specify an action and parameters to call just as you would from the regular Dialplan (bridge, transfer, hangup, and so on.). These options are all pretty simple—they define a single digit which, when pressed, either bridges a call or transfers the call to an extension.

There is one entry that is a bit different from the rest, which is the fnal IVR entry. It deserves a closer look.

 

<entry action="menu-exec-app" digits="/^(10[01][0-9])$/"
param="transfer $1 XML features"/>

This entry definition specifes a regular expression for the digits feld. This regular expression feld is identical to the expressions you would use in the Dialplan. In this example, the IVR is looking for any four-digit extension number from 1000 through 1019 (which is the default extension number range for the predefined users in the directory). As the regular expression is wrapped in parenthesis, the result of the entry will be passed to the transfer application as the $1 channel variable. This effectively allows the IVR to accept 1000-1019 as entries, and transfer the caller directly to those extensions when they are entered into the IVR.

The remaining IVR entry actions are a bit different. They introduce menu-sub as an action, which transfers the caller to an IVR sub-menu, and menu-top, which restarts the current IVR and replays the menu.

<entry action="menu-sub" digits="6" param="demo_ivr_submenu"/>
<entry action="menu-top" digits="9"/>

Several other actions exist that can be used within an IVR. The complete list of actions you can use from within the IVR include the following:

menu-exec-app

The menu-exec-app action, combined with a param field, executes the specified application and passes the parameterslisted to that application. This is equivalent to using <action application="app" data="data"> in your Dialplan. The most common use of menu-exec-app is to transfer a caller to another extension in the Dialplan.

Argument syntax: application <params>

Examples:

<entry digits="1" action="menu-exec-app" param="application param1
param2 param3 ...">
<entry digits="2" action="menu-exec-app" param="transfer 9664 XML
default">

menu-exec-api

The menu-exec-api action, combined with a param feld, executes the specifed API command and passes the parameters listed to that command. This is equivalent to entering API commands at the CLI or from the event socket.

Argument syntax: api_command <params>

Examples:

<entry digits="1" action="menu-exec-api" param="eval Caller Pressed
1!">

menu-play-sound

The menu-play-sound action, combined with a param field, plays a specified sound file.

Argument syntax: valid sound file

<entry digits="1" action="menu-play-sound"
param="screaming_monkeys.wav">

menu-back

The menu-back action returns to the previous IVR menu, if any.

Argument syntax: none

Examples:

<entry digits="1" action="menu-back">

menu-top

The menu-top action restarts this IVR's menu.

Argument syntax: None.

Examples:

<entry digits="1" action="menu-top">

Take a look at the XML for the sample sub-menu IVR and see if you can fgure out what it does. Also note how it is called above, when clicking 6 from the main menu.

<menu name="demo_ivr_submenu"
greet-long="phrase:demo_ivr_sub_menu"
greet-short="phrase:demo_ivr_sub_menu_short"
invalid-sound="ivr/ivr-that_was_an_invalid_entry.wav"
exit-sound="voicemail/vm-goodbye.wav"
timeout="15000"
max-failures="3"
max-timeouts="3">
<entry action="menu-top" digits="*"/>
</menu>

FreeSWITCH 1.0.6 Build robust high-performance telephony systems using FreeSWITCH
Published: July 2010
eBook Price: $23.99
Book Price: $39.99
See more
Select your format and quantity:

Routing calls to your IVR

Routing calls to your IVR is simple and can be done from within the Dialplan. Simply add the following XML application to your Dialplan extension where you want to invoke an IVR:

<action application="ivr" data="demo_ivr"/>

This will cause FreeSWITCH to look for the IVR named demo_ivr and invoke it. Note that it is not possible to return from an IVR and continue processing Dialplan entries; the IVR must ultimately transfer, bridge, or hangup the caller.

The XML Dialplan entry for invoking the demo_ivr, which is included with the sample FreeSWITCH configuration files, is as follows:

<!-- a sample IVR -->
<extension name="ivr_demo">
<condition field="destination_number" expression="^5000$">
<action application="answer"/>
<action application="sleep" data="2000"/>
<action application="ivr" data="demo_ivr"/>
</condition>
</extension>

Note that in the preceding example, a sleep application appears before the IVR is executed. This is important as it allows for media to begin flowing between your caller and your FreeSWITCH instance, before the IVR's greeting begins playing. If the Dialplan does not do this, you may get complaints from some callers of IVRs to "clip" the beginning of the greeting.

Nesting IVRs

There are two ways to "nest" or otherwise combine IVRs.

The first way is to use the sub-menu system list, as mentioned. Simply create two or more IVR menus as if they were independent menus, with each one having a unique name. Then, from the main IVR, create an entry option with an action of menu-sub and a param containing the name of the child IVR.

<entry digits="1" action="menu-sub" param="child_ivr"/>

The advantage to creating your menus this way is that you gain the ability to use the menu-back action to allow callers to get to the previous IVR menu, useful if you might have multiple parents calling the same child menu.

The other way to use sub-menus is to assign each IVR a unique extension number and simply transfer the caller from one extension to another, in order to get to and from the parent and child menus. In this way, you can always guarantee that you can get from one specific IVR to another and back again, regardless of how an IVR was invoked.

Using phrases with IVRs

You may have noticed the greet-long and greet-short option in the examples use "phrase:demo_ivr_main_menu" as opposed to a specific sound filename and path. IVRs allow you to specify sound files using the phrase and text-to-speech macros. This is useful for several reasons, most notably the ability to chain together multiple sounds into one "phrase" and the ability to have different languages presented to the caller, based on the caller's information.

Calling Phrase Macros

Phrase Macros can be called from the Dialplan, from an IVR. Phrase Macros can be used virtually anywhere that a sound filename can be used. (Phrase Macros are used only for playback purposes, so they cannot be used when specifying a filename for a recording operation.) We have already seen examples of using phrases in our XML IVR configuration files. Following are a few examples of using Phrase Macros from the Dialplan:

<action application="playback"
data="phrase:myphrase:arg1:arg2:arg3"/>
<action application="play_and_get_digits" data="2 5 3 7000 #
phrase:myphrase:arg1 /invalid.wav my_var \d+"/>

Note, too, that there is no requirement to have an argument. The following code is valid as well:

<action application="playback" data="phrase:myphrase"/>

Now let's look at some phrases to see what they can accomplish for you.

Phrase Macro examples: voicemail

The FreeSWITCH voicemail system is exemplary in its use of Phrase Macros to simplify the task of combining pre-recorded sound prompts in a reusable way. By looking at the Phrase Macros used in the FreeSWITCH voicemail implementation, we can learn virtually all there is to know about using these powerful tools.

Open conf/lang/en/vm/sounds.xml in a text editor and scan through the file. You will notice the familiar opening <include> tag and the subsequent <macro> tags. Just by looking at the definitions of these macros, you can get an idea of what some of them do. The basic syntax of a Phrase Macro looks like the following:

<macro name="<macro name>">
<input pattern="<pattern>">
<match>
<action>

</match>
<nomatch>
<action>

</nomatch>
</input>

<input pattern="<pattern>">
<match>
<action>

</match>
<nomatch>
<action>

</nomatch>
</input>
</macro>

The macro is defined by the contents within the <macro> and </macro> tags. The input pattern is a regular expression (pattern) that is matched against any arguments that are passed to the Phrase Macro. The actions inside of the <match> and </match> tags are executed if there is a positive match, otherwise the actions inside of <nomatch> and </nomatch> are executed. If a match is found, then the special regular expression capture variables ($1, $2, and so on) are available inside the <match> node. Note that you may have multiple input patterns. This functions in a way that is very similar to the way the XML Dialplan functions. (See the following code for an example of using multiple input pattern nodes.)

Let's review a few simple macros. Locate the voicemail_goodbye macro as follows:

<macro name="voicemail_goodbye">
<input pattern="(.*)">
<match>
<action function="play-file" data="voicemail/vm-
goodbye.wav"/>
</match>
</input>
</macro>

This macro is called by the voicemail system when the caller logs out. In this case the input pattern is "(.*)" which will always match any arguments, and in fact will match even if no arguments are passed. (This pattern is very common in Phrase Macros.) If there is a match, (and there always will be) then this macro plays the vm-goodbye. wav file. That is all it does. At first glance, it may not seem advantageous to have seven lines of code just to play a single sound file. However, using this Phrase Macro allows us to customize what happens when a caller logs out of voicemail, and we can do so without editing any source code. There are, though, other advantages.

Locate the voicemail_enter_pass macro:

<macro name="voicemail_enter_pass">
<input pattern="(.*)">
<match>
<action function="play-file" data="voicemail/vm-
enter_pass.wav"/>
<action function="say" data="$1" method="pronounced"
type="name_spelled"/>
</match>
</input>
</macro>

Note that this macro captures the arguments and places them in the special variable $1. In the default configuration, the voicemail module sends # as the argument. This macro is what controls the dialog when the caller is logging into voicemail. Specifically, it plays the sound file that says, "Please enter your password, followed by…" and then uses the say application to "say" the word "pound". The net effect, then, is that the caller hears "Please enter your password, followed by pound". This macro lets us customize what the caller hears when he or she is prompted to enter a password.

Watch the fs_cli while logging into voicemail and checking messages. You can observe the phrases being parsed and executed.

At this point, we can already see that Phrase Macros are good for customization, and they stitch together various sound prompts to create meaningful sentences to play to the caller. A classic example of this is the IVR menu. The voicemail main menu really is just an IVR menu for a specific purpose. The voicemail main menu is a dialog that says to the caller, "To listen to new messages, press 1. To listen to saved messages, press 2. For advanced options, press 5. To exit, press pound". Let's look at this macro. Locate the macro voicemail_menu, listed as follow s:

<macro name="voicemail_menu">
<input pattern="^([0-9#*]):([0-9#*]):([0-9#*]):([0-9#*])$">
<match>
<!-- To listen to new messages -->
<action function="play-file" data="voicemail/vm-
listen_new.wav"/>
<action function="play-file" data="voicemail/vm-press.wav"/>
<action function="say" data="$1" method="pronounced"
type="name_spelled"/>
<action function="execute" data="sleep(100)"/>

<!-- To listen to saved messages -->
<action function="play-file" data="voicemail/vm-
listen_saved.wav"/>
<action function="play-file" data="voicemail/vm-press.wav"/>
<action function="say" data="$2" method="pronounced"
type="name_spelled"/>
<action function="execute" data="sleep(100)"/>

<!-- For advanced options -->
<action function="play-file" data="voicemail/vm-advanced.wav"/>
<action function="play-file" data="voicemail/vm-press.wav"/>
<action function="say" data="$3" method="pronounced"
type="name_spelled"/>
<action function="execute" data="sleep(100)"/>

<!-- To exit -->
<action function="play-file" data="voicemail/vm-to_exit.wav"/>
<action function="play-file" data="voicemail/vm-press.wav"/>
<action function="say" data="$4" method="pronounced"
type="name_phonetic"/>
</match>
</input>
</macro>

Most of this phrase is self-explanatory. The key piece of information is actually found in the pattern (highlighted). The voicemail module calls this macro with an argument list that looks like this: 1:2:5:#. The input pattern is simply a regular expression that parses out those values, so that $1 contains "1", $2 contains "2", $3 contains "5", and $4 contains "#".

Let's look at one more example of using Phrase Macros to solve what may otherwise be complicated IVR scenarios. The voicemail_message_count macro solves two distinct problems. First, we have two different types of voicemail messages, namely, new and saved. Second, we have the challenge of when to use "messages" (plural) or "message" (singular), when telling the caller how many messages are present. Notice how our voicemail_message_count macro elegantly solves both problems as follows:

<macro name="voicemail_message_count">
<input pattern="^(1):(.*)$" break_on_match="true">
<match>
<action function="play-file" data="voicemail/vm-you_have.wav"/>
<action function="say" data="$1" method="pronounced"
type="items"/>
<action function="play-file" data="voicemail/vm-$2.wav"/>
<action function="play-file" data="voicemail/vm-message.wav"/>
</match>
</input>
<input pattern="^(\d+):(.*)$">
<match>
<action function="play-file" data="voicemail/vm-you_have.wav"/>
<action function="say" data="$1" method="pronounced"
type="items"/>
<action function="play-file" data="voicemail/vm-$2.wav"/>
<action function="play-file" data="voicemail/vm-messages.wav"/>
</match>
</input>
</macro>

Again, much of this is self-explanatory, and like the previous example, the key to understanding this macro is in the input patterns (highlighted). The voicemail module calls this macro with an argument of "x:new" or "x:saved" representing the number of new or saved messages, respectively. The number of messages is captured in $1, and then type of messages (either "new" or "saved") will be stored in $2. The macro uses $2 to determine whether to play voicemail/vm-new.wav or voicemail/ vm-saved.wav, so that problem is easily solved. However, what about saying "messages" versus "message"?

Notice that the first input has an extra attribute, namely, break_on_match. By setting this attribute to "true", we tell the macro to stop looking at the rest of the input patterns in the macro. If the user has a single new message, then the voicemail module will call this phrase with an argument of "1:new". (Likewise, it would call the argument with 1:saved for a single saved message.) The first pattern will match, and no more searching for matches will be performed. Then, the actions within the first <match> will be executed. In this case the Phrase Macro stitches together a phrase that says, "You have … one … new … message". However, if there is more than one message (or zero messages), then the argument would be something like 2:new. In this case, the first input pattern match would fail, and then it would continue on to the second pattern, where it would match. The actions inside this <match> node would yield a phrase that says, "You have … two … new … messages". By using a more specific input pattern first, along with setting break_ on_match to "true", and by using the more general input pattern second, we have a simple and elegant way of handling the "plural problem" that is common among many languages.

Advanced routing

IVRs are not just limited to menus. While you most likely want to program complex IVRs using a programming language, it's possible to use the built-in XML IVRs in other ways, too.

For example, let's say you wanted to require callers to enter a PIN number in order to reach a special answering service. You might create an IVR that contains the PIN number as the only available entry, and replace the sound files with a greeting, requesting the PIN number and the invalid entry sound with an invalid password message. The menu would be simple enough as follows:

<menu name="enter_pin"
greet-long="phrase:enter_your_pin"
invalid-sound="phrase:invalid_pin"
exit-sound="phrase:invalid_pin"
timeout="15000"
max-failures="3"
max-timeouts="3">
<entry digits="1828" action="menu-exec-app" param="transfer
after_hours XML default"/>
</menu>

This would effectively create a prompt, requesting a password as stated above, and disconnecting callers after three tries.

As another option, you might create an IVR that collects some data that is later used in your Dialplan. Let's say, you wanted the caller to enter the caller ID that they want appearing on their next outgoing call. You could create an IVR to collect ten digits, pass the result to another extension which sets the digits to the current caller ID, and then go to the final destination. Your IVR menu might look like the following:

<menu name="set_callerid"
greet-long="phrase:enter_your_callerid"
invalid-sound="phrase:invalid_callerid"
exit-sound="phrase:invalid_callerid"
timeout="15000"
max-failures="99"
max-timeouts="99">
<entry digits="$(\d{10})" action="menu-exec-app"
param="transfer $1 XML set_callerid"/>
</menu>

You would then create a special context in your Dialplan that might look like this:

<context name="set_callerid">
<extension name="SetIt">
<condition field="destination_number" expression="^(\d{10})$">
<action application="set"
data="effective_caller_id_number=$1"/>
<action application="bridge"
data="sofia/external/18005551212"/>
</condition>
</extension>
</context>

The combination of the preceding IVR and helper context would allow callers to enter their Caller ID, and have it set prior to the bridge application being called.

Summary

The IVR system within FreeSWITCH is a powerful, flexible tool for use when creating anything that gathers input from a caller. When combined with the various other applications in FreeSWITCH, the possibilities for routing callers using dynamic and creative call flows are endless.

FreeSWITCH 1.0.6 Build robust high-performance telephony systems using FreeSWITCH
Published: July 2010
eBook Price: $23.99
Book Price: $39.99
See more
Select your format and quantity:

About the Author :


Anthony Minessale

Anthony Minessale has been working with computers for nearly 30 years. He is the primary author of FreeSWITCH and Director of Engineering for CudaTEL at Barracuda Networks.

He created and continues to run the ClueCon Telephony Developers Conference, held every August in Chicago.

He has extensive experience in the Internet industry and VoIP. Before creating FreeSWITCH, he contributed heavily to the Asterisk open source project, producing many features that are still in use today. At Barracuda Networks, Anthony oversees the production and development of the CudaTEL PBX appliance that uses FreeSWITCH as its core telephony engine.

Darren Schreiber

Darren Schreiber is the CEO and Co-founder of 2600 Hz. He began working heavily in open source voice with the FreeSWITCH project, where he engaged with Brian, Mike, and Anthony. His projects have since evolved into two enterprise VoIP platforms that allow a multitude of development of voice, SMS, and video applications to be delivered to customers.

He has 15 years of voice and IT experience including developing multiple enterprise SaaS infrastructures for hosting and remotely managing IT, voice, and e-commerce services. He is a guest lecturer at major universities on VoIP technology and leads paid international VoIP trainings. As a serious telephony enthusiast since a young age, he has worked extensively with VoIP technologies. He graduated from Rensselaer Polytechnic Institute with a degree in Computer Science and Business Management.

He is also a co-author of FreeSWITCH Cookbook, Packt Publishing.

Michael S. Collins

Michael Collins is a 15-year veteran of telecommunications and PBX systems. A relative newcomer to VoIP, he discovered FreeSWITCH in its very early stages and has been an enthusiastic community member ever since. He works with the core FreeSWITCH development team, assisting with documentation and community development. Michael currently works for a technology company that makes extensive use of FreeSWITCH.

Books From Packt

jQuery 1.4 Reference Guide
jQuery 1.4 Reference Guide

Nginx HTTP Server
Nginx HTTP Server

NetBeans Platform 6.9 Developer's Guide
NetBeans Platform 6.9 Developer's Guide

YUI 2.8: Learning the Library
YUI 2.8: Learning the Library

NetBeans Platform 6.9 Developer's Guide
NetBeans Platform 6.9 Developer's Guide

Joomla! Social Networking with JomSocial
Joomla! Social Networking with JomSocial

WordPress 3 Site Blueprints
WordPress 3 Site Blueprints

Python 3 Object Oriented Programming
Python 3 Object Oriented Programming

No votes yet
We had a few challenges by
We had a few challenges implementing a JavaScript IVR in FreeSWITCH, especially playing audio and capturing user input. We blogged about it and have some sample code, hope it will help a few of you http://www.onsip.com/blog/sukanya/2011/10/24/javascript-ivrs-in-freeswitch

Post new comment

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.
A
k
D
L
t
t
Enter the code without spaces and pay attention to upper/lower case.
Code Download and Errata
Packt Anytime, Anywhere
Register Books
Print Upgrades
eBook Downloads
Video Support
Contact Us
Awards Voting Nominations Previous Winners
Judges Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software
Resources
Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software