FreeSWITCH 1.2
上QQ阅读APP看书,第一时间看更新

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.