FreeSWITCH 1.8

Anthony Minessale II, Giovanni Maruzzelli

• Publisher: Packt Publishing
• Year: 2017
• ISBN:
  9781785888298
• Edition: 1
• Topic: Computer Science
• Subtopic: Computer Science General
• Index: Computer Science

Build a robust, high-performance telephony system with FreeSWITCHAbout This Book• Learn how to install and configure a complete telephony system of your own, from scratch, using FreeSWITCH 1.6• Get in-depth discussions of important concepts such as dialplan, user directory, NAT handling, and the powerful FreeSWITCH event socket• Discover expert tips from the FreeSWITCH experts, including the creator of FreeSWITCH—Anthony MinessaleWho This Book Is ForThis book is for beginner-level IT professionals and enthusiasts who are interested in quickly getting a powerful telephony system up and running using FreeSWITCH. It would be good if you have some telephony experience, but it's not a must.What You Will Learn• Build a complete WebRTC/SIP VoIP platform able to interconnect and process audio and video in real time• Use advanced PBX features to create powerful dialplans• Understand the inner workings and architecture of FreeSWITCH• Real time configuration from database and webserver with mod_xml_curl• Integrate browser clients into your telephony service• Use scripting to go beyond the dialplan with the power and flexibility of a programming language• Secure your FreeSWITCH connections with the help of effective techniques• Deploy all FreeSWITCH features using best practices and expert tips• Overcome frustrating NAT issues• Control FreeSWITCH remotely with the all-powerful event socket• Trace packets, check debug logging, ask for community and commercial helpIn DetailFreeSWITCH is an open source telephony platform designed to facilitate the creation of voice and chat-driven products, scaling from a soft-phone to a PBX and even up to an enterprise-class soft-switch. This book introduces FreeSWITCH to IT professionals who want to build their own telephony system.This book starts with a brief introduction to the latest version of FreeSWITCH. We then move on to the fundamentals and the new features added in version 1.6, showing you how to set up a basic system so you can make and receive phone calls, make calls between extensions, and utilize basic PBX functionality.Once you have a basic system in place, we'll show you how to add more and more functionalities to it. You'll learn to deploy the features on the system using unique techniques and tips to make it work better.Also, there are changes in the security-related components, which will affect the content in the book, so we will make that intact with the latest version. There are new support libraries introduced, such as SQLite, OpenSS, and more, which will make FreeSWITCH more efficient and add more functions to it. We'll cover these in the new edition to make it more appealing for you.Style and approachThis easy-to-follow guide helps you understand every topic easily using real-world examples of FreeSWITCH tasks. This book is full of practical code so you get a gradual learning curve.

Dialplan in Deep

We have now a more than basic understanding on how the XML configuration of FreeSWITCH and its powerful XML dialplan work.

It's time to go beyond that feeling of "I know how to do things, but not quite why they work that way".

Bear with me for this long and difficult chapter, and you will be rewarded with a good understanding of all the machineries that contribute to FreeSWITCH flexibility and versatility.

We'll see:

• How to combine conditions
• How to avoid dialplan pitfalls
• All about variables and their usage
• How to execute API commands from dialplan like we're on console
• Specific idiolects to slice, dice and rinse variables and strings
• Applications for interacting with live calls (barge and hotkeys)
• A cookbook style trove of useful dialplan recipes

Where are the previous Dialplan seasons?

We saw a lot in previous chapters, Test Driving the Demo Configuration and XML Dialplan. We visited all the foundational concepts, and the basic techniques that make FreeSWITCH ticking and spinning, happily chugging along your Real Time Communication traffic growth.

Don't cheat on yourself; if you've not been there, go now. It will take little reading time, even less if you're an experienced old FreeSWITCH hand, and it will ensure we're on the same page using the same concepts and terms, and will make you happy.

I will not repeat in this chapter the bulk of those chapters, so pretty please, read those chapters already.

XML Dialplan Recap

Following, in bullet format, how the dialplan works, its various components, their interaction, and all the important terms' definitions

• incoming call lands at the beginning of one of the dialplan contexts. This is the "routing phase" of the call, phase during which the TODO list is built
• to which context the call lands on is determined by modules' configuration (eg, which SIPprofile - IPaddress/port pair - the call comes from) or by User Directory (if call has been authorized)
• a context is a list of extensions, call enters at beginning, and proceed toward end of list. If call goes through the end, is hungup
• if an extension has been evaluated as "matching" (see later), then the call continue to the next extension depending on the value of the "continue" extension's parameter
• each extension is composed by one or more conditions, each condition may contain one or more actions/anti-actions
• the characteristics of the call (eg, dialed number), of the configuration (you can set variables in vars.xml and elsewhere) and of the system (eg, time of day) are all available via variables
• each condition checks some specified variable against some (regular) expression
• a condition is evaluated true or false, if the expression matches or not the specified variable(s)
• if condition is true its actions will be pushed in the TODO list stack, it its false its anti-actions will go in the TODO list
• in a condition, the parameter "break-on" determines if checks will continue with the next condition or stops here
• actions (and anti-actions) are dialplan applications (provided by almost each FreeSWITCH module, most of them provided by mod_dptools)
• after the traversing of the dialplan context, and the checking against the extensions, is completed then the call enters its "execution phase"
• in "execution phase"all actions that were pushed in TODO list stack are executed in order (FIFO)
• the separation between 'routing phase" and "execution phase" implies that you cannot set and check variables in the same dialplan pass (eg, not in next conditions of same extension, nor in conditions inside any following extensions). If you need that, use the "inline" parameter of the "set" application
• the original incoming call that enters the dialplan is called "A-leg". FreeSWITCH-originated calls to be bridged with the A-leg, are called "B-legs"

More about conditions

Conditions are the control elements in XML dialplan. Inside each extension there is at least one "condition" tag where the characteristics of the configuration/system/incoming call, represented by variables, are checked against a (regular) expression. If the condition is evaluated as true, the actions inside the condition are added to the call's TODO list. If evaluated as false, anti-actions (if present) are added to the TODO list. The general format is:

 <extension name="is_looking_for_2900" continue="true"> <condition field="destination_number" expression="^2900$" break="on-true"> <action application="log" data="WARNING first TRUE"/> <anti-action application="log" data="ERR first FALSE"/> </condition> <condition field="destination_number" expression=".*"> <action application="log" data="WARNING second TRUE"/> <action application="set" data="var01=value01" inline="true"/> <action application="set" data="var02=value02"/> <anti-action application="log" data="ERR second FALSE"/> </condition> <condition field="${var01}" expression="^value01$"> <action application="log" data="WARNING third TRUE"/> <anti-action application="log" data="ERR third FALSE"/> </condition> <condition field="${var02}" expression="^value02$"> <action application="log" data="WARNING fourth TRUE"/> <anti-action application="log" data="ERR fourth FALSE"/> </condition> </extension> <extension name="after_is_looking_for_2900"> <condition field="destination_number" expression="^2900$"> <action application="log" data="WARNING first of after TRUE"/> <anti-action application="log" data="ERR first of after FALSE"/> </condition> </extension> 

Let's have a quick look at this example, and please re-read previous chapters for more details.

The first extension has a "continue" parameter set to true, so if this extension is found "matching" (that is, its first condition is evaluated as true), the next extension will be checked for a match. The default is the "continue" parameter set to false, so traversing the dialplan looking for matches will stop at the first matching extension.
The first condition has a parameter "break" set to "on-true". So, if the expression is evaluated as true, the next condition(s) will not be checked. The default is to break "on-false" (eg, if the condition is false, do not check the next condition); other options include "always" and "never".

The first condition expression can be read as "a string exactly matching '2900'", because caret means "beginning-of-string" and dollar sign means "end-of-string".

The second condition will only be checked if the first condition is evaluated as false. The second condition's anti-action will never be sent to the TODO list (because the second condition expression ".*" will always match whatever the destination number is).

The third condition will be true if the destination number is anything different from 2900 (because the variable in expression is set by the second condition and the second condition is always true but is only tested if the first condition is false) while the fourth condition will never be true: this because only the variable checked by the third condition was set using the "inline" parameter. Your action of setting a variable takes place after dialplan traversing is completed, if you don't use the "inline" parameter of the "set" action.

The second...

Table of contents

• Title Page
• Copyright
• Credits
• About the Authors
• About the Reviewer
• www.PacktPub.com
• Customer Feedback
• Preface
• Architecture of FreeSWITCH
• Building and Installation
• Test Driving the Example Configuration
• User Directory, SIP, and Verto
• WebRTC, SIP, and Verto
• XML Dialplan
• Phrase Macros and XML IVRs
• Lua FreeSWITCH Scripting
• Dialplan in Deep
• Dialplan, Directory, and ALL via XML_CURL and Scripts
• ESL - FreeSWITCH Controlled by Events
• HTTAPI - FreeSWITCH Asks Webserver Next Action
• Conferencing and WebRTC Video-Conferencing
• Handling NAT
• VoIP Security
• Troubleshooting, Asking for Help, and Reporting Bugs