Tmedia Routing

Revision as of 10:12, 1 December 2011

Static routing table

The static routing table uses the parameters from the incoming call to find a route and make the routing decision. These parameters are called incoming call attributes. Three parameters are verified:

• Called number
• Calling number
• Incoming Network Access Point (NAP)

Once the route(s) have been chosen, the outgoing call parameters can be modified using the outgoing call attributes to make outgoing calls:

• Remapped Called Number: New called number used on the outgoing calls
• Remapped Calling Number: New calling number used on the outgoing calls
• Remapped NAP: determines on which network the outgoing calls are sent.
• Remapped Profile: This is used to modify the default profile of the Remapped NAP used on this route.

These paramters will replace the incoming attributes and are independent on each route.
If there is more than one route, the first route will be randomly chosen from the list of possible routes.
If that route fails, route retry will be used and the new outgoing call attributes will be used.

Up to 2000 routes can be entered in the static routing table.
You can import or export static routing table using the web portal. Go to

Gateway -> Configurations -> Routes -> Route table actions -> Export Static Routes

This is the default configuration of the Media Gateway

Called/Calling number details for incoming call attributes:
Field can be empty: this means any number will match
Field can be a specific number: this means the exact number must match
Field can be a regular expression
For example,
Number Routing filter example
Ex. /^1?450[0-9]{7}$/
Optional 1, followed by 450, then 7 digits

For complete example, checkout
http://docs.telcobridges.com/mediawiki/index.php/Toolpack:_How_to_Use_RegEx_in_Remapped_Called_and_Calling_Number_Mask

Remapped Called/Calling number details for outgoing call attributes:
Field can be empty: this means the incoming called/calling is used for the outgoing call.
Field can be a specific number: this means this number will be used in the called/calling fields.
Field can be a regular expression. It requires a replace function to be used to replace the incoming number.
For example, post routing translation (remap)
Ex. /^(1?)450([0-9]*)$/\1514\2
Replace the 450 by 514

Route match depends on outgoing NAP availability

Gateway -> Configurations -> Routes

Standard Scripts

Gateway -> Routing scripts

Standard scripts
Can be enabled easily
Adds functionnalities to Static routing
Three standard scripts are proposed:

How to setup standard scripts -> Point to page "How to setup Standard scripts"
simple routing (simple_routing.rb): Script used for the static routing table

NAP priority routing (nap_priority_routing.rb): This script routes calls according to a priority setting of outgoing NAPs. Each NAP has its own priority setting. The [:prio] field column need to be added in the NAPs page. A smaller [:prio] value has more priority. If more than 1 route matches, the route with the highest NAP priority will be selected first. There is an improvement to this script using the nap_group_weight_load_balancer.rb filter.

Percentage routing (percentage_routing.rb): This script allows to do load sharing amongst multiple NAPs. Each NAP has its own load sharing setting. The [:percent_target] field column need to be added in the NAPs page. This is useful to envenly route call to different providers. The calculation of percentage for each nap is done by using the cumulative number of outgoing calls made to each nap.
There is an improvement to this script using the nap_group_weight_load_balancer.rb filter.

ASR routing (asr_routing.rb): This script routes calls according to the ASR values of the destination naps. This kind of routing will try to improve overall system ASR by always using the best naps. It will also help client perception by cleanly dropping calls that would almost certainly fail anyway.

Nature of Address and Numbering plan indicator remapping (noa_npi_remap.rb): Allows to modify the NOA and NPI values on outgoing calls.

Least Cost Routing (least_cost_routing.rb). This script routes calls according to the cost values (which may depend on the time) of the routes. This is useful for cases when a route's popularity (cost) depends on the time of the day. This is done by adding different columns to the static routing tables (for example [:cost_0_6]) and filling them up with values for each routes.

Other standard routing scripts implement filters and are covered in [link:filters]

Routing engine: filters
Gateway -> Routing scripts

Adds functionnalities to standard scripts. Filters can be added to any standard script in a few steps. For example, you may want to remove the '1' prefix for uniformed routing, select the SIP Request URI to route the call instead of the called number, etc.

Two types of filter exist:
Before filter: Adds pre-processing on incoming parameters
After filter: Adds post-processing on outgoing parameters

How to Add Filter to normal scripts -> Point to page "How to setup Filters"
There is one standard script available for each Routing filter. That standard script implements the standard routing, plus the filter.
Standard script Filter used
schedule_remapping.rb schedule_remapper.rb
...

Nap group and weight load balancer
group = priority + regrouping
Weight by call attempt (not load)
=> No historical data

Label routing

Gateway -> Routing scripts
Gateway -> FileDb
Gateway -> Routesets

Label routing was created because in some cases, there can be no regular expressions on the called number to define a route.

Problem: Having thousands of destination numbers (N), and possibly one route per number per Network Provider (M), resulting in N*M routes
Solution: Create labels for each groups of numbers (L) and let the system deduce the route, resulting in L*M routes, where L < N

A Label is a virtual group of destination numbers. This virtual group has a list of numbers assigned to it in a CSV file.
This process does the routing in 2 stages:
1st stage - Find a Label: Find longest prefix match entry for the called number. This leads to only one destination Label. This is the Digitmap file.
2nd stage - Find the NAPs serving a Label: All routes tied to this Label are eligible for routing the call. This is the routeset definition file.

What are the advantages compared to static routing?
- Can have thousands of numbers
- It has a non linear search algorithms so there is no overhead of having large amount of numbers. Label routing was tested with more than 100,000 numbers
- Variables can be added to the routeset definition file to use other filter scripts and have even more flexibility.

Example usage:
- NPA-NXX routing
- Blacklisting
- Tandem switch

See here for complete details: [Link: Routeset routing]

Custom Routing Scripts

Gateway -> Routing scripts

Customers can create their own routing functions using a Scriptable Routing Engine based on ruby. These functions can be imported and exported from the Web portal.
These scripts can do complex routing algorithms and post routing translation, as well as other advanced functions. It is also possible to modify standard Scripts, or filters, to achieve more complex scenarios
The functions have control over many call parameters such as:
Calling
Called
Nature of Address
Calling Presentation
Calling Screening
Redirecting Number
Original Called Number, etc.
The complete list is here [link:list of parameters]

Custom routing script are kept on Software upgrades. Versionning of routing scripts needs to be handled by the operator of the unit. The new scripts (with the same names, but a new version) can be manually replaced directly in the routing script page.
It is possible to test routing scripts directly from the web portal before activating them in a live system.
For complete details check this [Link:Scriptable routing]

Route retry

The routing engine returns all matching routes to the system. The TMG-CONTROL then generates an outgoing call using the first route of the list. If the call fails, the TMG-CONTROL may or may not generate another call according to the error code received.

The route retry will proceed with another route if the return code is:

Service unavailable
Circuit not available
Etc.

The route retry will not proceed with another route if the return code is:

User busy
Unallocated number
Etc.

It is possible to modify the route retry sequence (continue or discontinue) to handle unsuccessful routes, please refer to the nap profile. For more details see the route retry page.
These parameters can be modified here:
Profiles -> default [Edit] -> Edit Reason Cause mapping

Route retry is enabled by default. Timers and conditions on route retry can be adjusted from the configuration:
Gateway -> Configurations -> Advanced

NOTE:The route retry feature is available for other types of routing as well.