Skip to main content

Call Routing Details

How to set a call routing?​

With some basic configurations, you can generate a report via Routing Analysis tool. The Routing Analysis section allows user to examine call forwarding, manage dynamic routes and simulate different routing models.

Here’s a set of the minimum required configurations for a proper work of routing:

  • Rate Table assigned to the Client/Account/Template.
  • Routing Plan assigned to the Client/Account/Template.
  • Routing Plan should have rules that match respective DST Number.
  • Terminator should have a Rate Table to receive a call and Routing Rules should conform with the Terminator.

Simple rules to configure routing​

  1. All calls from a Client must be sent to specific Terminator:

    • Create a Routing Plan and specify the "*" wildcard (all codes) in the Code field.
    • Choose the Static Client type and specify the target Routing Policies (for instance, Simple LCR – a price based routing option).
    • Assign a created Routing Plan to the Client.

  2. Calls with certain code must be routed to a respective vendor:

    • Create a Routing Plan and specify "380" in the Code field.
    • Choose Static Client type and specify the required vendor.
    • Assign this Routing Plan to a respective customer.
warning

Please note, the Traffic Processing takes part in the routing process.

  • Orig Rules - for calls originated from a Client. It's applied during the call authorization and affects all next steps. If the VCS doesn't take part in the authorization process and only receives an accounting data from the softswitch, orig type will be only applied for orig call leg (orig CDR record).
  • Term Rules - for calls terminated to a Client. It's applied to a term leg (term CDR record of a call) after receiving an accounting data and before the billing process.
  • Orig-Term Rules - for orig and term calls. It combines both types.
  • DR Rules - it's applied during routing of the call (if the VCS takes part in the routing), after routes determination and before sending reply to the softswitch. It affects a further call processing.

Be advised that in VCS version 3.16.0 the Traffic Processing section has been entirely reworked. More about its features can be found in this article.

How to test a route?​

In order to test a route (it only works for the DR Routes Testing routing plan), you need to do the following:

  • Assign a Routing Plan DR Routes Testing to an origination Client (it could be a SIP dialer phone of test-engineer);
  • Dial in the following format: xxx*yyyyy, where "xxx" is an ID of termination vendor's Account and "yyyyy" – an actual number in an international format.

Example: test-engineer dials 100*4955667788, this means that number "4955667788" will be sent to a vendor, whose Account ID is 100. This way a test person can quickly and conveniently test a lot of vendors, without the need to build new Routing Plans/Rules for each particular case.

tip

Please be advised that the above-mentioned example will work only if origination Client has assgined Rate Table that covers a 100 destination. That's why we recommend to assign a Rate Table that covers all possible codes (separate Rates for destinations from 1 to 9).

Brief Cases Analysis​

Case 1: Routing Analysis doesn't show changes, however, several modification were made in the Routing Plan.​

Cause: Dynamic Routing Manager was not run.

Resolution: Run Dynamic Routing Manager every time the Routing Plan has been changed. To do so, open Task Scheduler / System Services section.

Case 2: The call doesn't process, however, everything is configured properly and Routing Analysis shows routes.​

Cause 1: There are not enough available funds on Client's/Reseller's balance.

Resolution: Check Balances in the Settings. The route for the call will be acceptable, if the balance is enough for one call with a duration of 2 seconds.

Cause 2: Orig Account and Term Account belong to different Gateways.

Resolution: Check the matching of Gateways, orig and term Account must belong to the same Gateway.

Case 3: Routing Analysis shows an unprofitable route.​

Cause 1: Customer's Rate is lower than a vendor's price.

Resolution: Check Rates of respective customer and vendor.

Cause 2: Set margin is higher than a real profit.

Resolution: You need to check the Margin in order to avoid this issue.

Case 4: Routing Analysis shows several routes, when the call is sent only to the first one.​

Cause: This happens because of switch configurations. Some switches (for example, MVTS) have a setting not to continue the search of the routes at a certain code response of terminator.

Resolution: Configure the switch to route calls to several vendors.