Contexts
Contexts are logical groups of extensions. Think of contexts as sections of the Dialplan. Each section has a specific purpose and contains only extensions that are related to the purpose. One such purpose is to isolate extensions from one another. A typical example of this is "multi-tenancy". A FreeSWITCH server can service more than one business entity (tenant), and providing each tenant with its own context prevents numbering conflicts. Each tenant could, for example, have a "dial zero for the operator" extension. Users in one tenant can dial 0 to reach their front-desk extension, while users in another tenant can also dial 0 to reach a completely different extension. Another consideration for contexts is security. Phone calls that are being routed through a context have access only to the resources specifically allotted, perhaps long-distance or international dialing, or use other resources such as multi-party audio conference rooms.
There is no limit to the number of extensions that may be defined. The example XML Dialplan defines three different contexts, which we'll look at next.
Default
The default
context contains all of the extension definitions that are available to registered users of the system. When we added extension 1100
to conf/dialplan/default.xml
, we were actually modifying an extension in the default
context. Most of the features of the example XML Dialplan are defined in this file.
Public
The public
context is a good example of using contexts for the sake of security. All unauthorized calls coming in to the FreeSWITCH server will be handled by the public
context. The name "public" means "inherently untrusted". By default, FreeSWITCH is paranoid about what unauthorized callers can do in the system. Generally speaking, the public
context is used to route incoming DID (Direct Inward Dial) phone numbers to a specific internal extension (see conf/dialplan/public/00_inbound_did.xml
for an example). You can use the public
context to let in only the calls that you deem appropriate for your system.
Features
The features
context is a good example of grouping together extensions by function. These extensions could just as easily be added to the default
context; however, putting them in their own context helps keep things organized. The extensions defined in the features
context mostly are not Endpoints in themselves but rather helper extensions, which perform a function and then transfer the caller elsewhere. An example of this is the please_hold
extension that sets the music on hold for the caller, tells the caller, "Please hold while I connect your call", and then transfers the caller to the destination extension.