Routing

This section describes authentication and routing principles.

General routing algorithm is represented on the picture below:

On the first step of general routing algorithm authentication will be made. As a result of this step Customer Auth record will be selected for incoming call or call will be dropped with Disconnect Code 110 (Can’t find Customer or Customer locked).

On the second step of algorithm Yeti will check Customer’s balance if Check account balance flag of selected Customer Auth record is enabled. If current balance is less than Min balance call will dropped with Disconnect code 8000 (No enough customer balance).

On the third step of general routing algorithm Yeti makes pre-Routing numbers translations. Yeti rewrites (if necessary) Name field in the Source-number, Source-number and Destination-number for incoming call (by using POSIX Regular Expressions) with using Number translation settings of Customer Auth record that was selected. On this step Yeti also rewrites (if necessary) Source and Destination numbers which will be send to Radius-server if it’s required (by using POSIX Regular Expressions) with using Radius options of Customer Auth record that was selected.

On the fourth step of general routing algorithm Yeti makes processing of destination Numberlist if this Numberlist was setted up in the Customer Auth record. Depending on chosen mode Yeti is going via all related Numberlist items and makes some actions. As a result of this step Yeti could drop the call with Disconnect code 8001 (Destination blacklisted) or just rewrite (if necessary) Source and Destination numbers (by using POSIX Regular Expressions) with using rewrite rules of Numberlist items record or rewrite rules relevant Numberlist record.

On the fifth step of general routing algorithm Yeti makes processing of source Numberlist if this Numberlist was setted up in the Customer Auth record. Depending on chosen mode Yeti is going via all related Numberlist items and makes some actions. As a result of this step Yeti could drop the call with Disconnect code 8002 (Source blacklisted) or just rewrite (if necessary) Source and Destination numbers (by using POSIX Regular Expressions) with using rewrite rules of Numberlist items record or rewrite rules relevant Numberlist record.

On the sixth step of general routing algorithm Yeti will be looking for Areas (by using Area prefixes) that are related to the Source number (From name) and Destination number (URI name) after them processing and translation on the previous steps. Area records that were found (if any), are used for detecting Routing Tags for the call on the basis Routing Tag detection Rules.

On the seventh step of general routing algorithm Yeti will be selecting Routing Plan that was chosen for Customer Auth record.

On the eighth step of general routing algorithm Yeti (if Use Lnp flag of Routing Plan that was chosen for Customer Auth record is enabled) selects most preferred Routing Plan LNP rule (by longest match prefix of destination number (number B)) and uses this Routing Plan LNP rule for processing ported numbers of call. If required record wasn’t found in the LNP Cache - LNP Database will be requested. In case of failing query Yeti will drop the call with Disconnect code 8003 (No response from LNP DB).

On the ninth step of general routing algorithm Yeti will be searching Destination for the call that is matching ALL following conditions:

• Prefix of Destination record is in the prefix range of Destination number (URI name);

  Note

  Examples:

  • Prefix of Destination record = ** ; URI name = 0662296132 => TRUE

  • Prefix of Destination record = 066 ; URI name = 0662296132 => TRUE

  • Prefix of Destination record = 066[1-3] ; URI name = 0662296132 => TRUE

  • Prefix of Destination record = 066[1-3] ; URI name = 0665296132 => FALSE

  • Prefix of Destination record = 066[1-3], 0665 ; URI name = 0665296132 => TRUE

  • Prefix of Destination record = 066[1-3], 0665 ; URI name = 0666296132 => FALSE

• Length of Destination number (URI name) is between Dst number min and max length values of Destination record;

  Note

  Examples:

  • Dst number min length of Destination record = 3 ; Dst number max length of Destination record = 15 ; URI name = 380662296132 => TRUE

  • Dst number min length of Destination record = 7 ; Dst number max length of Destination record = 7 ; URI name = 7050460 => TRUE

  • Dst number min length of Destination record = 0 ; Dst number max length of Destination record = 7 ; URI name = 0487050460 => FALSE

• Rateplan that is chosen for Destination record is same with Rateplan that is chosen for Customer Auth record;

• Destination record is enabled;

• current date&time is more than Valid From value of Destination record;

• current date&time is less than Valid To value of Destination record;

• at least one Routing Tag (from the list of Routing Tags that were chosen for the call during the sixth step of general routing algorithm) is included in the set of Routing Tags that are chosen for:ref:Destination <destinations> record.

If more than one record was found during searching of Destination Yeti sorts records with following rules: records with the longest Prefix of Destination on the top; records with biggest amount of Routing Tags that were chosen for the call (during the sixth step of general routing algorithm) and are included in the set of Routing Tags that are chosen for:ref:Destination <destinations> record on the top. Only first record from sorted list will be chosen.

If no records were found during searching of Destination Yeti will drop the call with Disconnect Code 111 (Can’t find destination prefix).

If Reject Calls flag is enabled for the Destination record that was chosen Yeti will drop the call with Disconnect Code 112 (Rejected by destination).

On the tenth step of general routing algorithm Yeti will search routes (Dialpeers) for a call on the basis routing (sorting) algorithm that was chosen for Routing Plan record. If no records were found during searching of Dialpeers Yeti will drop the call with Disconnect Code 113 (No routes).

On the eleventh step of general routing algorithm Yeti will pass through list of selected Dialpeers) that is sorted by chosen routing (sorting) algorithm. For each Dialpeer following actions will be applied:

• Search termination Gateways for selected Dialpeer (Step 11.1). If Gateway was chosen for Dialpeer record (and this Gateway is Enabled) Yeti will check Vendor property of Dialpeer and compares it with Contractor property of Gateway. In case if Is shared flag of Gateway record wasn’t chosen and Vendor property of Dialpeer record and Contractor property of Gateway record aren’t same - Yeti will stop process this Dialpeer and will go to next record in the sorted list of Dialpeers. Otherwise Gateway that was chosen for Dialpeer record will be used for attempt of the call termination. If Gateway wasn’t chosen for Dialpeer record Yeti will select all enabled Gateways from Gateway group that was chosen for Dialpeer where Point of Presence of the termination and origination Gateways are same AND Vendor property of Dialpeer record and Contractor property of Gateway record are same. If Gateways from the same Point of Presence weren’t found - Yeti will select all enabled Gateways from Gateway group that was chosen for Dialpeer regardless Point of Presence, but where Vendor property of Dialpeer record and Contractor property of Gateway record are same. All selected by this way Gateways will be used for attempts of the call termination. The quantity of attempts of the call termination for each Dialpeer record from the sorted list of Dialpeers is determined by quantity of selected Gateways that are sorted by following rules: Gateways from the same (related to origination) Point of Presence are first, Gateways with higher Priority are first, random Gateway will be chosen first in case of equal Priorities for two or more Gateways in the list;

• Yeti will pass through list of selected Gateways that is sorted by priority (Step 11.2). For each Gateway from the list following actions will be applied:

  • Checking if Customer’s min balance will be reached during the call (Step 11.3). On this stage Yeti will check if Connect Fee of Destination record that was selected for this call is bigger than the result of subtracting Balance of the Customer’s Account and Min balance of the Customer’s Account. If no enough money on Customer’s Account for make connection and for calling during Initial Interval of Destination record that was selected for this call - call will dropped with Disconnect code 8000 (No enough customer balance);

  • Calculating of allowed time for the call (Step 11.4). Yeti could limit maximum time of the calls to avoid exceeding limits of money (minimum or maximum) that are available on accounts of Customer and Vendor. For this purpose Yeti has two values of allowed time: limited by Customer’s Account and limited by Vendor’s account:

    • Allowed time that is limited by Customer’s Account. If Next Rate AND Next Interval of the Destination record that was selected for this call are not zero: allowed time for the call will be calculated as sum of Initial Interval of this Destination record and length of call that can be made within amount of money available on Customer’s Account. Otherwise value Max Call Duration from Global configuration will be used for setting allowed time for the call;

    • Allowed time that is limited by Vendor’s Account. If Next Rate AND Next Interval of the Dialpeer record that was selected for this call are not zero: allowed time for the call will be calculated as sum of Initial Interval of this Dialpeer record and length of call that can be made before reaching Max balance the Vendor’s Account. Otherwise value Max Call Duration from Global configuration will be used for setting allowed time for the call;

  • Checking if Vendor’s max balance will be reached during the call (Step 11.5); On this stage Yeti will check if Connect Fee of Dialpeer record that was selected for this call is bigger than the result of subtracting Max balance and Balance of the Vendor’s Account. If Vendor’s max balance will be reached during Initial Interval of Dialpeer record that was selected for this call - this Gateway will be ignored and next Gateway will be chosen from the list on Step 11.2;

  • Post-routing numbers translations (Step 11.6). On this step of general routing algorithm Yeti makes post-Routing numbers translations. Yeti rewrites (if necessary) Name field in the Source-number, Source-number and Destination-number for incoming call (by using POSIX Regular Expressions) with using Number translation settings of Dialpeer record that was selected for this call;

  • Adding Call Profile to the Array (Step 11.7). On this step Yeti will add Call Profile to the list (array) of Call Profiles. Call Profile will be used by Yeti/SEMS node for making call on Step 12 of general routing algorithm.

On the twelfth step of general routing algorithm Yeti/SEMS node will pass through list of Call Profiles that was received on previous step (Step 12). For each Call Profile following actions will be applied:

• Checking Disconnect Code (Step 12.1). On this step Yeti will check if Disconnect Code for Call Profile was initialized (not NULL). If yes - Yeti will initiate disconnecting (Step 12.6) from Originator (with using received Disconnect Code) after writing CDR & statistic for route/gateway (Step 12.3a);

• Trying to connect a call (Step 12.2). On this step Yeti will try to make a connection with LegB via Gateway that was selected for current Call Profile. Regardless from call result (successful or not, length of call etc.) Yeti will write CDR & statistic for route/gateway (Step 12.3b) and will change customer’s and vendor’s balance at billing subsystem (in case of successful call with non-zero length) on Step 12.4. After the checking of call result (Step 12.5) Yeti will disconnect from Originator (Step 12.6) in case of successful call or will go the next Call Profile in the list (Step 12). Yeti will exit from the loop only when call had been made successfully or when all Call Profiles had been used;

• Writing CDR + writing statistic for route/gateway (Step 12.3 (a & b)). Information about call will be stored to the CDR Table and current statistical parameters (count of answered telephone calls, general length of telephone calls) will be updated for Dialpeer record that was selected for this call and for Gateway that was used for this call;

• Change Customer’s and Vendor’s balance at billing subsystem (if necessary) (Step 12.4). On this step Yeti will change Customer’s and Vendor’s balance in case of successful call with non-zero length. For calculating prices of the call for Customer and Vendor following rules are used:

• Customer’s price calculation rules. For calculate Customer’s price for the call Yeti will summarize Connect Fee (in currency units) of Destination record that was selected for this call, price of initial interval of call that is calculated as multiplication of Initial Interval (in seconds) of Destination record to the Initial Rate (in currency units per minute) that was divided on length of a minute in seconds (60 seconds), and (in case of calls that are longer than Initial Interval) price of next interval of call that is calculated as multiplication amount of Next Intervals of Destination record that was selected for this call that were placed in the duration of the call after Initial Interval to the Next Rate (in currency units per minute) that was divided on length of a minute in seconds (60 seconds). At the last step Customer’s price that was calculated will be increased on the value of value-added tax (VAT) that was specified for the Customer’s Account.

• Vendor’s price calculation rules. For calculate Vendor’s price for the call Yeti will summarize Connect Fee (in currency units) of Dialpeer record that was selected for this call, price of initial interval of call that is calculated as multiplication of Initial Interval (in seconds) of Dialpeer record to the Initial Rate (in currency units per minute) that was divided on length of a minute in seconds (60 seconds), and (in case of calls that are longer than Initial Interval) price of next interval of call that is calculated as multiplication amount of Next Intervals of Dialpeer record that was selected for this call that were placed in the duration of the call after Initial Interval to the Next Rate (in currency units per minute) that was divided on length of a minute in seconds (60 seconds);

Note

Important notice:

In normal mode changing Customer’s and Vendor’s balance at billing subsystem will be made by subtraction of the Customer’s price that was calculated on this step from the Customer’s balance and by addition Vendor’s price to the Vendor’s balance. But in case of enabling Reverse billing flag of Destination record that was selected for this call - Yeti will add Customer’s price that was calculated on this step to the Customer’s balance, and in case of enabling Reverse billing flag of Dialpeer record that was selected for this call - Yeti will subtract Vendor’s price from the Vendor’s balance. Following formula is used for calculation both Customer’s and Vendor’s prices:

\[\begin{equation} Price = (CF + II(\frac{IR}{60}) + [\frac{(CD-II)}{NI}]NI(\frac{NR}{60}))(1 + \frac{VAT}{100}) \end{equation}\]

where:

• Price - Customer’s or Vendor’s price;

• CF - Connect Fee of Destination (for Customer’s price) or Dialpeer (for Vendor’s price), currency units;

• II - Initial Interval of Destination (for Customer’s price) or Dialpeer (for Vendor’s price), seconds;

• IR - Initial Rate of Destination (for Customer’s price) or Dialpeer (for Vendor’s price), currency units per minute;

• CD - Call duration, seconds;

• NI - Next Interval of Destination (for Customer’s price) or Dialpeer (for Vendor’s price), seconds;

• NR - Next Rate of Destination (for Customer’s price) or Dialpeer (for Vendor’s price), currency units per minute;

• VAT - Value-added tax, percents. VAT = 0 for calculating Vendor’s price.

• Disconnect from Originator (Step 12.6).

YETI WEB interface - Routing menu description.

• Customers Auths
• Rateplans
• Destinations
• Routing Groups
• Dialpeers
• Routing Plans
• Routing plan static routes
• Routing Plan LNP rules
• LNP Caches
• Numberlists
• Numberlist items
• Routing Tags
• Areas
• Area prefixes
• Routing Tag detection Rules
• Routing Simulation
• Truth table for tags
• Truth table for prefixes