About

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.

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.

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

Modules


Tools


See Also