Dialplan

Contents

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 backend as other systems may be employed. Instead they are unique, independent methods through which you can access information.

Unlike some other switches, the dialplan is not designed to be an end all be 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 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 you might want to use, such as bridge, can be found in the documentation of the dptools module.

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: FreeSWITCH uses multiple contexts to prevent internal extensions from being exposed to everyone. As per default the contexts are called "Public" and "Default" (but these names are arbitrary and are used in the default config that ships with FreeSWITCH). Everything in the public context is available to everyone, while everything in "default" context are only available to users that have registered with FreeSWITCH. You can define in the user profiles (in the directory) which context they belong to, and you can define the public context in the sofia configuration.

Anywhere you can specify a dialplan to route with (such as mod_sofia's configuration), you may specify multiples by comma separating them.