Configurations Using Policy
Application examples using policy as a primary construct are presented below. These application examples are valid for both the Small and Large Enterprise models as base configurations.
Configuration examples include:
- Priority Call Handling, Using Constraint Policy Action
- Transcoding, Using Redirect Policy Action
- Call Recording, Using Redirect Policy Action
- Domestic vs. International Call, Using Translation Action
- Deny Routes, Using Routing Action
- Stop Recurse Routes, Using Routing Action
- Skip Routes, Using Routing Action
Priority Call Handling
The Oracle Enterprise Communications Broker provides support for ensuring that high priority calls, such as 911 calls, are not constrained by system utilization thresholds. Non-priority calls are still subject to system constraint configuration. The user configures priority call behavior by creating a policy with the constraint-action, then applying that policy to the applicable routes. The Oracle Enterprise Communications Broker applies this policy to the configured route, as well as every subsequent backup route, even if the backup routes are not configured with the policy.
The system ignores constraints, such as session and rate/burst limits, for calls that match the priority route. The constraints-action provides a built-in action called IgnoreConstraints. This action causes the policy to mark a call to ignore constraints. All conditions configured on the policy must be satisfied for the action to be applied. The constraints-action is special in that, when enabled, it sets the call to ignore constraints for ALL routes. This is necessary because backup routes may be utilized that are not specific to priority/emergency calls.
For example, an emergency call might first be routed to a 911 service, but on failure it would be sent to the PSTN. The call cannot be limited by constraints on the PSTN route.
The built-in Emergency policy is provided for user convenience, and uses the IgnoreConstraints constraints-action. This built-in policy can be edited, if desired.
Note that this setting does not affect the "Deny" and "StopRecurse" policies on routes. It is simply not known whether these policies are for constraining purposes or because the network infrastructure cannot support calls over those routes.
Priority Call Configurations
This example shows a policy configuration that excludes 911 calls from system constraints, ensuring that the system does not encumber the call delivery. The following configuration documents the built-in policy titled "Emergency" applied to a route for 911 calls.
| Name | Emergency |
| Description | Built-in policy to ignore constraints for emergency or priority calls. |
| Condition | The default condition, which requires no configuration, is to always apply the policy. |
| Action |
|
Example Route
| Source Agent | Calling # | Destination Agent | Called # | Route | Cost | Policy |
|---|---|---|---|---|---|---|
| * | * | * | 911 | EmrSvc | 0 | Emergency |
Transcoding and the Oracle Enterprise Communications Broker
Transcoding is the conversion of media streams' encoding between endpoints that use different codecs. The Oracle Enterprise Communications Broker allows the user to configure routing policies that identify session agents deployed for transcoding media sessions and redirect applicable signaling and media streams to those agents.
Transcoding Configurations
This example shows a policy configuration that identifies an offer that does not include PCMU or PCMA and routes the call to a Transcoding device, in this scenario an SBC, to ensure that the media uses either PCMU or PCMA.
| Name | XcodePcmuPcma |
| Description | Send calls that need transcoding to PCMU or PCMA to a transcoding SBC |
| Condition |
|
| Action |
|
Example Route
| Source Agent | Calling # | Destination Agent | Called # | Route | Cost | Policy |
|---|---|---|---|---|---|---|
| * | * | PBX | * | PBX | 0 | XcodePcmu |
This configuration results in the system sending traffic that contains the PCMU codec to the PBX, and traffic without the PCMU codec to the XcodeSBC, back to the Oracle Enterprise Communications Broker and then to the PBX.
Multiple Outbound Translations
The Oracle Enterprise Communications Broker provides a means for refining outbound translation configurations using routing policy. Fixed outbound translation configuration is available at the agent level. Routing policy, however, includes an outbound translation action that takes precedence over agent and sip interface configuration and applies translation based on individual route matches.
Outbound Translation Configurations
This example shows an outbound translation configuration that configures E164 numbers for domestic calls, and E164-no-plus with 011 prepended for international calls. The example calls for two policies and two routes.
| Name | Policy 1—InternationalDialNA
Policy 2—DomesticDialNA |
| Description | Policy 1—North American
international dialing
Policy 2—North American domestic dialing |
| Condition | The default condition, which requires no configuration, is to always apply the policy. |
| Actions | Outbound Translation Action
(InternationalDial)
Outbound Translation Action (DomesticDial)
|
Routes
In addition to the dial patterns in this example, the system needs the following two new routes.
| Route # | Source Agent | Calling # | Destination Agent | Called # | Route | Cost | Policy |
|---|---|---|---|---|---|---|---|
| 1 | * | * | PSTN-NA | 11* | PSTN-NA | 0 | InternationalDialNA |
| 2 | * | * | PSTN-NA | 1* | PSTN-NA | 10 | DomesticDialNA |
Results
The configuration in this example provides the results shown in the following table.
| From | Dial String | Transformation | Result |
|---|---|---|---|
| * | 15551234 | 1555123415551234 | Call is routed without dial string change |
| * | 34555555 | 11345555550 | Call is routed with dial string change |
The system routes any call that includes a country code and does not begin with the digit "1" internationally, and with the applicable transformation.
Routing Action Configurations
The Oracle Enterprise Communications Broker includes three pre-configured Policies (based on the pre-configured DenyAction, StopRecurseAction and IgnoreConstraints routing actions) that the user can apply to routes. In addition, the pre-configured Skip routing action mode is available for easy Policy configuration, which the user can then apply to routes.
Modes for routing actions include:
- Deny—The Oracle Enterprise Communications Broker should not forward the call at all.
- StopRecurse—Stop trying backup routes if the current route fails.
- Skip—Do not try this route, based on condition; proceed to any backup options.
Deny Route Policy Configurations
This example shows a policy configuration that prevents the system from allowing the request's source to reach the destination. The configuration shown here documents the built-in policy titled "Deny" applied to an example route.
The Deny policy in any resultant SIP routes to a destination prevents the Oracle Enterprise Communications Broker (Communications Broker) from forwarding a SIP request to the destination point in question. You can use the Deny policy to prevent sessions between two endpoints for policy or cost reasons.
The Communications Broker includes a pre-configured deny route policy that you can use without modification.
| Name | Deny |
| Description | Built-in policy to deny the incoming session |
| Condition | The default condition, which requires no configuration, is to always apply the policy. |
| Action | Name—DenyAction
Routing Mode—deny |
Example Route
In addition to the configurations in this example, consider the following policy applied against this route.
| Source Agent | Calling Number | Destination Agent | Called Number | Route | Cost | Policy |
|---|---|---|---|---|---|---|
| Class_B | * | Protect_Agnt | * | Transit_Agnt | 0 | Deny |
This route entry is designed to prevent calls passing through the This route entry may be installed as part of one or multiple routes that could potentially reach Protect_Agnt. The routing engine recognizes the presence of this route entry and rejects the call.
In addition, the system applies this Deny regardless of the backup route on which it is specified.
Stop Recurse Route Policy Configurations
This example shows a policy configuration that prevents the system from recursing through ensuing backup routes if the route configured with this policy stops responding. The configuration shown here documents the built-in policy titled "StopRecurse" applied to an example route.
A Stop-Recurse hop stops further attempts to forward a SIP request to a destination after the system tries the route with the Stop-Recurse hop. You can use the Stop-Recurse hop to prevent calls from being forwarded on certain routes that are cost-prohibitive or might cause loops in SIP call flows.
The Oracle Enterprise Communications Broker (Communications Broker) includes a pre-configured stop recurse policy, with Routing Action applied.
| Name | StopRecurse |
| Description | Built-in policy to prevent further backup route attempts. |
| Condition | The default condition, which requires no configuration, is to always apply the policy. |
| Action | Name—StopRecurse
Routing Mode—stop-recurse |
Example Route
To expand upon the example, consider the following route.
| Source Agent | Calling Number | Destination Agent | Called Number | Route | Cost | Policy |
|---|---|---|---|---|---|---|
| Class_A | * | Protect_Agnt | * | Transit_Agnt | 0 | StopRecurse |
This route allows traffic to reach Protect_Agnt as long as it originates by way of the agent named Class_A.
For example, consider the scenario where an endpoint can be reached using two routes.
- Route 1: Agent_1 to Agent_2 (StopRecurse) to PBX
- Route 2: Agent_1 to PSTN
Route 1 uses a StopRecurse policy defined on the hop between Agent_2 and PBX. The Communications Broker stops processing the call if Route 1 does not receive a successful response. This configuration can prevent calls initially targeted for Route 1 from using the PSTN.
Stop Recursion by SIP Response Code
The Stop Recurse parameter provides you with control over how the system allows or stops recursion on routing by allowing you to set the specific response codes that you want the system to act upon. You can control recursion by response code globally through the SIP Interface configuration or locally through an agent or agent group configuration. Valid response code values range from 300-599. You can enter individual response codes separated by a comma, such as 301,305 or a range such as 300-380. The system uses response codes 401 and 407 for the defaults.
Skip Route Policy Configurations
This example shows a policy configuration that prevents the system from using this route based on condition. This policy contrasts with the StopRecurse policy because the routing engine is free to recurse through other routing options after skipping.
The Oracle Enterprise Communications Broker includes a pre-configured Skip Action, which you can select to define a policy.
| Name | MySkip |
| Description | Do not use this route, depending on condition. |
| Condition | The following Time Condition
Fields activate the skip policy on weekdays from 9am to 5pm.
Name—When to enforce MySkip Days—Monday, Tuesday, Wednesday, Thursday, Friday Start time—09:00:00 End time—16:59:59 |
| Action | Name—SkipRoute
Routing mode—skip |
Example Route
In addition to the preceding configurations, this example applies the following policy against the target routes.
| Source Agent | Calling Number | Destination Agent | Called Number | Route | Cost | Policy |
|---|---|---|---|---|---|---|
| Class_B | * | Protect_Agnt | * | Transit_Agnt | 0 | MySkip |
The resulting configuration prevents the system from using this route to Transit_Agnt as a means of reaching Protect_Agnt on weekdays from 9 to 5.