Tmedia Routing

Static routing table

Gateway -> Routes

Basic route matching

The static routing table uses parameters from the incoming call to locate a route and then make a routing decision. These parameters are called incoming call attributes. Three parameters are verified:
A route will match an incoming call if all the route matching parameters are met.

Multiple routes may be a match for a call.

The following criteria are available for basic route matching:

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

Calling / called number matching

Calling / called number matching works as follows:

• 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 match:
• Field can be a sip user and sip host: such as user@sip_host:sip_port

    Number Routing filter example:
     Ex. /^1?450[0-9]{7}$/
     This number must match an optional 1, followed by 450, then 7 digits

    SIP user/host routing example:
     Ex. 5551212@abc.com
     This number must match exactly 5551212 for sip host abc.com only

NAP matching

The Network Access Point can be SS7, ISDN, CAS or SIP.

Basic (per-route) call attributes remapping

Once the route(s) have been chosen, some call parameters can be modified using the parameters of the route:

Outgoing call parameters remapping

• 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 Access Point (NAP) the outgoing calls are sent.
• Outgoing call remapped Profile: Select the profile to use with the outgoing call when this route is used, otherwise NAP's default profile is used.

Source call leg parameters remapping

Some parameters of the source call leg can also be modified:

• Source call remapped Profile: Select the profile to use with the source call leg when this route is used, otherwise the NAP's default profile is used.

Calling / called number remapping options

Calling / called number remapping works as follows:

• Field can be empty: In this case, the called/calling numbers from the incoming call are used for the outgoing call.
• Field can be a specific number: This number will be used as called (or calling) number for the outgoing call.
• Field can be a regular expression: Allows building the outgoing call's calling/called number through matching/replacement of incoming calling/called number.
  

    For example, post routing translation (remap)

     Ex. /^450([0-9]*)$/\514\2

     This regular expression replaces 450 with 514

For a complete example, refer to: How To Use Regular Expressions

Multiple routes matching

The remapping parameters above (both for incoming and outgoing calls) are independent for each route.
This allows different routes to use different NAPs, and remap the calling/called numbers differently.

Ordering the routes

When multiple routes match the incoming call, the order of these matching routes is undefined, by default.
Fortunately, it is possible to prioritize the routes using various algorithms, using routing scripts. A few examples:

• Ordering by route priority
• Load sharing (Priority and Load Sharing to Routing Script)
• Round robin
• Least cost
• Per period of the day

Route retry

If multiple routes match for a call, call retry may be done on subsequent routes upon failure making outgoing call on a route. For more information about route retry, refer to the following page: Route Retry.

Routes limitation

Up to 2000 routes can be entered in the static routing table.

Note: When the number of routes becomes large, this may be a sign that more advanced routing should be used.

For information about label route handling, refer to Label Routing or contact TelcoBridges Support

Exporting / importing routes

You can import or export the static routing table using the web portal. Go to:

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

or

Gateway -> Routes -> Route table actions -> Import Static Routes 

This is the default configuration of the Media Gateway

Standard Scripts

Gateway -> Routing scripts 

Standard scripts are used to modify the behavior of the static routing.  It allows for the prioritization of routes, load sharing amongst multiple endpoints, or the modification of some call parameters. It can be enabled on any system in just a few steps. The following is a list of Scripts supported today:

• 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 needs to be added in the NAPs page. A smaller [:prio] value has more priority. If more than 1 route matches, the route with the lowest NAP priority will be selected first. There is an improvement to this script using the nap_group_weight_load_balancer.rb filter.
• Route priority routing (route_priority_routing.rb): This script routes calls according to a priority setting of Routes. Each Route has its own priority setting. The [:prio] field column needs to be added in each route. A smaller [:prio] value has more priority. If more than 1 route matches, the one with the lowest priority value will be selected first.
  
• Percentage routing (percentage_routing.rb): This script enables load sharing among multiple NAPs. Each NAP has its own load sharing setting. The [:percent_target] field column must be added in the NAPs page. This is useful to evenly 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 improve client perception by cleanly dropping calls that would almost certainly fail anyway.
• Nature of Address and Numbering plan indicator remapping (noa_npi_remap.rb): Enables the modification of 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 route.

Learn how to setup Standard Scripts in your gateway by following these steps: How to Setup Standard Scripts

Other standard routing scripts implement Filters and are covered in the next section.

Filters

Gateway -> Routing scripts 

Adds functionality 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, and more.

Two types of filter exist:

• Before filter: Adds pre-processing on incoming parameters
• After filter: Adds post-processing on outgoing parameters

Filter Scripts examples:

• Request-URI routing (ruri.rb): Will route the call on SIP RURI instead of the to: field
• Modify the Nature of Address (noa_npi_remap.rb): We can use this to change the NOA to national or international
• Remove Loop (FilterRemoveLoop.rb): Will prevent calls from being routed back to the sender
• Load sharing on NAP groups or on route groups (nap_group_weight_retry_with_overload.rb): This is a powerful script that allows for a regrouping of NAPs of the same kind, distributes loads among them, and prioritizes one group versus another.  Alternatively, you can do the same on routes. You need to add two columns to the NAPs (or the routes), one called "group" and one called "weight". Groups of lower value will have a higher priority (group=0 has more priority than group=10). The calls will be distributed according to the weight value. To have an equal number of calls on each destination, use the same weight value (weight=10). See Adding Load Sharing to Routing Script
  
• Black and White listing (black_white_listing.rb): With this script, any called or calling number prefix can be blacklisted or whitelisted. This script can be assigned globally, or per NAP. It reads a .csv file which has the called and calling number list. See Adding White or Black listing to Routing Script

Learn how to add a Filter to normal scripts: How to setup Filters

Label routing

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

Label routing was created because in some cases, regular expressions cannot be used 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 determine 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 uses a non linear search algorithms; therefore, there is no overhead to having a large amount of numbers. Label routing was tested with 5 million entries.
• 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: Label routing and Adding Label Routing to any Routing Script

Custom Routing Scripts

Gateway -> Routing scripts 

Customers can create their own routing scripts using a Scriptable Routing Engine based on Ruby. These scripts can be imported and exported from the Web portal.
These scripts can run complex routing algorithms and post routing translation, as well as other advanced functions. It is also possible to modify standard Scripts, or filters, to satisfy 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 in the Routing Script Tutorial

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, refer to Scriptable Routing Engine

Playing prompts

You can use routing scripts to request for prompts playback at various states of the call. See Playing prompts announcements or tones.

Recording calls

You can use routing scripts to request the recording of incoming and/or outgoing call legs to audio files. See Recording Calls.

Route retry

The routing engine returns all matching routes to the system. The TMG-CONTROL then generates an outgoing call using the first route in 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
• and more...

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

• User busy
• Unallocated number
• and more...

You can modify the route-retry sequence (continue or discontinue) to handle unsuccessful routes. For more information, 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.

For more details, see the Route Retry page

Related actions

Refer to the appropriate Toolpack release:

• Call Routes Settings v3.0
• Call Routes Settings v2.10
• Call Routes Settings v2.9
• Call Routes Settings v2.8

• Web Portal v2.7: Routes Configuration
• Web Portal v2.6: Routes Configuration