The 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 or a database lookup query sent to a web server via xmlcurl or via PostgreSQL using freeswitch.dbh connection pooling.
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.
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.
FreeSWITCH uses multiple contexts to prevent internal extensions from being exposed to the world. The two contexts in the vanilla FreeSWITCH configuration are called
Everything in the
Contexts can be used in