Dialplan
0. About
The FreeSWITCH dialplan is a decision tree that provides routing services to bridge call legs together, execute dialplan applications, and invoke custom scripts that you write, among other things.
Much of your effort will be focused on configuring a dialplan to suit your application, whether it is the built–in XML dialplan, a database lookup query sent to a web server via mod_xml_curl or via PostgreSQL using freeswitch.dbh connection pooling.
The FreeSWITCH dialplan is NOT a scripting language.
1. Introduction
The FreeSWITCH dialplan is not a single entity. You have the option to run different dialplan subsystems natively. These are not all translated into the same back–end as other systems may be employed. Instead each is a unique, independent method through which you can access information.
Enter the show dialplan command on fs_cli to see what other dialplans are loaded.
For example:
freeswitch@your_host> show dialplan
type,name,ikey
dialplan,LUA,mod_lua
dialplan,XML,mod_dialplan_xml
dialplan,asterisk,mod_dialplan_asterisk
dialplan,inline,mod_dptools
dialplan,signalwire,mod_signalwire
5 total.
See mod_commands) for all the commands available on FreeSWITCH's command line interface.
Unlike some other switches, the dialplan is not designed to be a be-all and end-all configuration language that you put a bunch of logic into. The dialplan, quite simply, is designed to take a call request, decide where it should be handled, and then forward it to that application (or, in FreeSWITCH parlance, modules).
FreeSWITCH modules
Modules are applications that extend FreeSWITCH with extra functionality. In the context, the most used commands / applications are in mod_dptools (i.e., dialplan tools), but check out the rest of the modules as well.
For example, routing a call to the mod_dptools:bridge application will spawn a new channel and connect it to the incoming one.
The design allowing for multiple dialplan processing modules, as well as routing calls to applications which do all the hard work, gives you the flexibility to do what you need, the way that you need it to work. It does not force you to adapt your infrastructure around FreeSWITCH™, but lets FreeSWITCH™ more readily mesh with your existing infrastructure.
IMPORTANT
Contexts
FreeSWITCH uses multiple contexts to prevent internal extensions from being exposed to the world. The two contexts in the vanilla FreeSWITCH configuration are called public and default, but these names are arbitrary and can be carefully changed. New contexts can also be added.
Everything in the public context is available to the world, while everything in the default context is only available to users who have registered with FreeSWITCH.
Contexts can be used in
- the Directory (usually in conf/directory/), to assign each user (i.e., registered devices) to a context
- SIP profiles to route calls to a specific context (related pages/articles: Configuring FreeSWITCH#SIPProfilessip-profiles, Sofia Configuration Files), Sofia SIP Stack, mod_sofia)
Anywhere you can specify a dialplan to route calls (such as mod_sofia's configuration), you may specify multiple ones by separating them with commas.
2. Modules
- Dialplan XML - XML Dialplan Module (the most common).
- LDAP Directory - LDAP Directory Dialplan Module
- mod_dialplan_asterisk - Asterisk compatible dialplan module.