|
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.
Unlike some other switches, the dialplan is not designed to be a be-all and end-all scripting language that you put a bunch of logic into. The dialplan, quite simply, is designed to take a call request, decide where it should forward to, and then forward to an application. For example, you can route a call to the bridge application, and that application will spawn a new channel, and then connect the two channels; it can route to the conference application, or any other registered application in the FreeSWITCH™ system. Some of the most common applications can be found in the mod_dptools, but check out the rest of the modules as well.
The design to allow 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.
