Quality-based PSTN Routing in OpenSIPS 3.1 LTS [part 2]

Overview

This post is a sequel to the initial write-up on the recently introduced qrouting (Quality-based Routing) module. During the last month, the module has received several key additions, aimed at both improving the data format (gateway statistics, thresholds and scores) as well as the runtime behavior, with a new traffic balancing algorithm having been built into the module.

In the following, we will take a closer look at what the enhancements are and how you can use them to their full potential.

Rating a Gateway

With the current (new) approach, each gateway starts with a rating (or weight) of 1, regardless if any statistics have been gathered for it or not. As qrouting samples enough statistics on a gateway (this amount can be tuned with the min_samples_xxx set of modparams), it can begin assessing whether the warning or critical thresholds of a monitored statistic (e.g. ASR, PDD, AST, ACD) have been exceeded for it.

By default, exceeding the warning threshold will penalize the gateway with a 0.5 factor, while exceeding the critical threshold will cause the gateway’s score to be multiplied by 0.05. All penalties are multipled together. For example:

• GW-1 has exceeded “warning ASR”. Its score will be: 1 * 0.5 = 0.5
• GW-2 has exceeded “critical PDD”. Its score will be: 1 * 0.05= 0.05
• GW-3 has exceeded “warning PDD” and “warning ACD”. Its score will be: 1 * 0.5 * 0.5 = 0.25
• GW-4 has clean statistics all-around. Its score is 1.
• GW-5 has no sampled statistics. Its score is 1.

The penalties for each statistic can be tuned within the qr_profiles table. The above values are simply the table defaults we chose. Finally, it’s worth noting that the rating of a carrier is equal to the average rating of its gateways.

Custom Gateway Statistics

But what if an OpenSIPS script developer wants to provide additional, custom statistics that they have on a gateway and factor them into the rating computation? A classical example here are the the MoS (Mean Opinion Score) and R-Factor (Rating Factor, per ITU-T Rec. G.107) scores of a gateway, which measure the quality of the media sent by that gateway.

To get this working, you must first define all of your custom statistics using the extra_stats module parameter:

modparam("qrouting", "extra_stats", "+mos/60; +r_factor; -503_replies/100")

Two important things to note here:

• the “+” or “-“ in front of a statistic denotes its direction: a “+” means “higher is better”, while a “-” means “lower is better”. The direction instructs qrouting on how to interpret your thresholds
• the “/60” suffix denotes the “minimally required samples”. Default: 30

Next, you must extend the qr_profiles table with 4 columns for each new statistic, denoting its thresholds and penalties. Use the same column naming convention as for the other ones. For example, for the custom “r_factor” stat, the columns must be named:

• warn_threshold_r_factor
• crit_threshold_r_factor
• warn_penalty_r_factor
• crit_penalty_r_factor

Example set of SQL commands:

ALTER TABLE qr_profiles ADD warn_threshold_r_factor DOUBLE DEFAULT -1 NOT NULL;
ALTER TABLE qr_profiles ADD crit_threshold_r_factor DOUBLE DEFAULT -1 NOT NULL;
ALTER TABLE qr_profiles ADD warn_penalty_r_factor DOUBLE DEFAULT 0.5 NOT NULL;
ALTER TABLE qr_profiles ADD crit_penalty_r_factor DOUBLE DEFAULT 0.05 NOT NULL;

Finally, whenever you have the required data samples (e.g. after a call is over and you get them from RTPEngine), you must call qr_set_xstat(). Notice that the “rule_id” and “gateway_id” are required. If you are using drouting partitions, then make sure to first fill in the rule_id_avp and gw_id_avp columns within your dr_partitions table. By doing so, you will have the required data written to these variables, within your opensips.cfg script, after calling do_routing().

Quality Routing Algorithms

So now we have custom stats and we have proper scoring for gateways. But how to best use them in order to perform the routing? Here, we saw two options which you can set via the new algorithm module parameter:

• Dynamic Weights (default) – when using this algorithm, the gateway ratings become weights in a weighted random balancing heuristic. For example, if you have two gateways, with ratings 1 and 0.5, respectively, the former will receive ~67% of the overall traffic, while the latter one will receive ~33%. We consider this algorithm to be the superior choice, since the module will also keep on constantly gathering signaling statistics even for poor-performing gateways, albeit at a much lower rate than for well-performing ones.
• Best Destination First – this algorithm simply sorts a routing rule’s list of destinations in descending order of their rating. Note that the starting order of the destinations is very important here (e.g. think about OpenSIPS restarts or drouting reloads, when qrouting has no samples), so you must take this into account when provisioning the data: make sure to place higher quality gateways near the start of the list for optimal results!

Conclusions

The qrouting module is now in the beta testing phase. With a mature feature set and polished documentation, it is eagerly awaiting to be put to good use. As always, feedback on the module, its settings or functions is very much appreciated!