Oracle Enterprise Communications Broker Contexts

A context is a collection of rules used to manipulate strings of dialed digits. In most use cases, contexts are associated with a PBX or branch office where the users associated with a given PBX are all subject to its rules for making telephone calls, such as:

  • Each user on the PBX dials the same digit for seizing an outside line
  • All users may be able to reach other extensions on that PBX by dialing short dial strings
  • All users in that environment have access to the same 'tie lines'.

The rules that govern how to interpret the series of digits do not differ from user to user within that PBX.

Note that this does not take user-based entitlements into consideration. For example, users within the same context all dial the same videoconferencing terminal in the corporate boardroom using the same series of digits, even though all of the users are not authorized to use that equipment.

Determination of a SIP message's "source context" is critically important. This is covered in more detail in "Ingress Processing". Phone numbers within a SIP message may have vastly different interpretations when, for example, a user dials "0" from two different branch offices within the same enterprise. The context of the dialing user differentiates the dialed pattern for the Oracle Enterprise Communications Broker (OECB).

The following list describes the terminology used to define contexts applicable to the OECB.
  • Geographic context—A collection of rules that define the dialing patterns applicable to a geography, usually a country. These rules are outside of an enterprise's control and are pre-configured for you on the OECB by Oracle. You can extend or modify these rules.
  • Corporate context—Rules defined by the enterprise that specify routing, policy, access code, and extension range dialing patterns. Rules may vary based on applicable PBX or branch office. Context hierarchy manages such variations.
  • Source Context—The context used when an Agent provides context detail for a given call. This is also the context within which a given user resides by way of configuration, to be understood as a user's default location.
  • Source Context Param—"sc", meaning source context, is the syntax for a parameter on the FROM header presented by equipment external to the OECB that specifies the context from which the call originated. When presented, the rules of this contexts are always applied.

Refer to "Dial Plan Configuration" for more information about the related fields.

Context Hierarchy

Contexts within the Oracle Enterprise Communications Broker may be defined hierarchically, to offer a parent/child inheritance relationship. This is done to avoid data duplication and redundant configuration.

For example, a large enterprise may have a corporate dial plan (common phone numbers for the IT help desk, employee benefits group, travel desk, etc.) that is consistent among all branch offices, and unique extension ranges per branch location. By defining common data in a "parent" context, each child context will inherit these common dial plan values and avoid the need for configuring each of them over and over for each branch office turn-up.

Each dialing context may have one corporate parent (for inheriting dialing rules that are unique for that enterprise) and one geographic parent (for inheriting common dialing rules pertaining to that branch office's physical location). Geographic and corporate contexts are described in the following sections.

Geographic Contexts

A geographic context is the set of rules for dialing within a given geography. It does not matter if you live in New York City or in Los Angeles, you'll still dial 011 for an international long distance call and 911 for emergency services because those are both part of the dial plan for the United States called the North American Numbering Plan (NANP). The Oracle Enterprise Communications Broker (OECB) ships with geographic dial plans for the fifty most populous countries. You can override the default data or refresh it with future data, for example, to account for changes in the ITU dial plans.

Each context that you define on the OECB may have a geographic parent, configured as a geographic location. By configuring a geographic location, the child context inherits the dialing patterns for that geography. You do not need to configure the child contexts with rules for 011+, 911, 411, and so forth. They inherit these rules because they participate in that geography's parentage relationship.

This dialgarm shows the relationship hierarchy of geographic contexts, corporate contexts, and child contexts. Child contexts, shown at the bottom of the hierarchy, inherit the contexts from the corporate and geographic contexts above them.

Note:

The digit ranges within the child contexts do not overlap, presenting a simple means of identifying context. This represents a Small Enterprise OECB Configuration Model. The corporate dialing patterns are configured on the corporate context once. In the preceding diagram, when a caller dials 3xxx from any child context, the system always sends the call to Madrid.

Corporate Contexts

In contrast to geographic contexts, which are common for all telephone calls throughout the world and may be supplied with the Oracle Enterprise Communications Broker (OECB) software, corporate contexts are company-specific and define the dialing rules for the enterprise. A corporate context may include all branch offices, remote offices, PBXs, and so forth.

This diagram shows the releationship of corportate contexts and child contexts. The digits in the child contexts overlap, and each child inherits the dial patterns of the corporate context.

Note:

In contrast to the example shown in "Geographic Contexts," the digit ranges in the child contexts overlap. The preceding diagram represents a Large Enterprise OECB Configuration Model. In this deployment, the system uses the dialed prefix to identify the child context. Each child context inherits the dial patterns of the parent to direct a call. Each child sends calls with the prefix 123 to a Bedford tie line, 456 to Madrid, and 789 to Berlin. You need to configure each pattern only once, on the parent (Acme Packet) context.