Evolve IMSWorkX Intelligent Call Routing Service¶
As the ultimate routing application, Evolve ® Intelligent Call Routing (ICR) takes any called number and routes it to any destination whether it is using SIP or AIN protocol. That destination can be as simple as another phone number, or perhaps a SIP URI, trunk group, or another rule set – you define the destination based on your network requirements.
The route to the destination is determined by evaluating rules with established criteria that are specified in a call plan. Calls can be routed based on a simple call forward, or the Time of Day, Day of Week, Specific Dates, Call Number Match, NPA List Match, or a Percent Allocation. ICR provides a wide range of routing possibilities.
ICR not only lets you define the destination and the rules applied to determine the route, but you also select the call treatment (connection type). In ICR, calls can be handled through SIP Redirect (302 message), Back-2-Back User Agent, or Attended Transfer. With this selection, you define the amount of control that ICR has over the call.
ICR includes a web-based user interface (web UI) for easy access to all its functionality. Each role (Subscribers and Service Providers) uses a different layout in the web UI to easily edit and prioritize the features of ICR.
ICR has an API that allows developers to programmatically integrate ICR with your network elements and systems. This gives you additional flexibility with how you offer the feature to your customers.
Using ICR to Deliver Services¶
The unique flexibility offered with ICR supports your efforts to offer enhanced user features. These features can be provisioned by multiple users through three main processes:
Web UI
ICR API
CSV file
Once provisioned, ICR will route both AIN and SIP protocol calls. Some common features include Call Forwarding, Toll Free Services, and Number Portability.
Call Forwarding¶
As a service, Call Forwarding simply redirects a phone call to another destination number, ideally where the called party is available to answer. When the call is answered, the call has been forwarded. To begin, ICR starts with a list of Subscribers who have enabled the feature, and the entire feature set is implemented simply by adding routing rules to each forwarded number. There can be one or more rules that apply to a single number.
A common practice is to apply conditions to routing rules. For example, when conditions are applied to a Time of Day routing rule, Subscribers can forward calls made to their home phone to an office phone between 8:00 am and 5:00 pm, but only if the calls come from their children’s numbers.
The flexibility provided by this method of building routing rules is a compelling reason for using ICR to deliver a Call Forwarding feature. This same flexibility also allows you to solve Subscriber usability problems. Because the routing rules are flexible, and the Application Server completes the rule match based on your definitions, the definition interface can be offered directly to Subscribers to make it a service that they can manage directly using remote access tools.
Toll Free Service¶
As a service, Toll Free is an allocated number that carries no cost to the calling party. Today, these toll-free numbers often act as the business’s point of contact. The customer places a call using the toll-free number. When the call is answered, the customer is presented with a menu of options for handling the call.
The demand today is real-time flexibility. The Subscriber must balance the unlimited availability of their toll-free number against the human resources and equipment availability of the business. Calls may be handled by different call centers at different times of day. The Subscriber needs to be able to change the call destination for any reason and at any time.
Using ICR, the basic structure of a toll-free service is to route a dialed toll-free number to one of many defined destination endpoints based on a sequence of routing rules that can include criteria such as the current date and time, holidays, NPA list, or any other requirements. Like other features based on ICR, the definition interface can be offered directly to Subscribers as a service they can manage using remote access tools.
Number Portability¶
Number Portability determines how to route calls based on the Service Provider that the called number is associated with. This function includes Local Number Portability (LNP) for fixed lines and full Mobile Number Portability (MNP) for mobile phone lines.
In the case of Number Portability, route determination begins with a database lookup to determine the Service Provider of record for the called number. If that number belongs to one of your network Subscribers, the route determined is simply to connect to the call as dialed. However, when the Service Provider of record is a different carrier, the route determination is more complex.
The first action of the routing engine is to add the appropriate carrier prefix to the called number. Routing rules are used to analyze the set of criteria you define to be applied to the prefixed number. Using that criteria, the destination is determined and ICR redirects the call back to the switch with the ultimate route to the destination.
Building Additional Services¶
One of the main benefits of ICR is the flexibility in provisioning many services and implementing them quickly. ICR includes the ability to build menus, label criteria, destinations, and parameters, limit concurrent calls, and more.
Menus incorporate collected digits with custom or preinstalled audio for a completely customizable, multi-layer Interactive Voice Response (IVR) call flow. End responses can include a prerecorded message, calls directed to specific numbers or trunk groups, and even sub-menus for further navigation.
Labels are a simple way to create a set of criteria, destinations, or parameters that are used multiple times by different call plans. For example, a Service Provider can create a label with criteria of Monday, Wednesday and Friday. For any call plan that would route based on those days, simply select that label as the criteria instead of building out the criteria for each call plan. Call plans can be made with multiple labels for even more control of the granularity of the call process.
In addition to this easy setup, any change to the label would then cascade to any active call plans. In this example, if the Service Provider changed the previous label to Monday, Tuesday, Wednesday and Friday, all call plans would automatically update to the new schedule.
Separation of Roles¶
ICR is designed to work in a three-tiered hierarchy, with Platform Owners, Service Providers, and Subscribers. Each of these roles have their own responsibilities and functions.
Platform Owners
The Platform Owner is the entity that deploys the network which runs ICR. The Platform Owner is responsible for defining physical egress routes and other network specifics. Additionally, Platform Owners create and define Service Providers.
Service Providers
A Service Provider is the entity that offers ICR features as a service to Subscribers. The Service Provider allocates users to their numbers and establishes routing plans for these numbers. The Service Provider is also responsible for defining Subscriber accounts.
Subscribers
Subscribers are the individuals or business entities that subscribe to the ICR service. Subscribers may be given access to their own numbers and can edit call plans and routing rules as well.
Call Processing¶
When ICR receives an incoming call, the database is checked to verify that the called number is associated with ICR. If the called number is not in the ICR database or ICR is not associated with it, the application responds with the configured No-Route Behavior.
If the called number is in the database, the application then steps through the routing engine. The called number will have one or more call plans associated with it. When a match is found, that rule is evaluated and the appropriate destination is provided in the response message. If no rule match applies to the current call, ICR attempts to use the next highest priority call plan, and if no matches are found there, ICR responds with the configured Default No-Route Behavior.
For each call plan, starting with the highest priority routing rule, ICR analyzes the match type and the criteria. If the rule match does not apply to the current call, the next rule is analyzed.
Rules are matched on the following types:
Forward Call
Time of Day
Day of Week
Holiday (event-based)
Percent Allocation Routing
Calling Number Match
NPA List
Concurrent Calls
Signaling Point Code
Calling LATA
Geographic Location
Signaling¶
The rest of this chapter details the specific call flow of various call treatments.
Note
Wireshark traces of a call flow can be viewed by clicking the link provided below the diagram.
SIP Call Treatments¶
SIP REDIRECT Method
The following diagram shows the message exchange when the SIP REDIRECT connection type is selected.
SIP Attended Transfer (REFER Method)
The following diagram shows the message exchange when the Attended Transfer connection type is selected.
SIP Back to Back User Agent (B2BUA)
The following diagram shows the message exchange when the SIP B2BUA connection type is selected.
AIN Queries and Responses¶
AIN Info_Collected
The following diagram shows the message exchange when an Info_Collected trigger is received and routed with ICR.
AIN Info_Analyzed
The following diagram shows the message exchange when an Info_Analyzed trigger is received and routed with ICR.
