The two-vendor voice quality control system is successfully tested during several months and offered us a significant stability without any call for a manual intervention. In this section we suggest the upgrade of the two-vendor architecture. We present the formulas for generalizing the two-vendor design into a multi-vendor version. The three vendor system is currently of a special urgent interest, as one of the main vendors of our highly demanded destination (Armenia) seems has long term problems and a new reliable vendor (Reliance) offers a possibly high quality termination to the destination in question. The next subsections present the algorithm and the formulas for implementation.

Conventions on ACD values

As usual, we need the ACD values of each of the vendor. Values are periodically collected from the remote billing database. For each vendor the aggregate ACD over all circuits must be computed (without limiting to the circuit representing the ACD transit router only). The choice of the window (restriction of the number of attempts or the time) must be based on the same technique used in the two-vendor system.

We need also the ACD minimal and maximal values. If there are no stats for computing even the max or min, both, the max and min, must be set to a ACD default value. Use 9 minutes as a default for Yerevan, Armenia.

If there are no connected calls to certain route and therefore no stat for computing the ACD of a route, the route’s ACD must be set to the current minimum. Obviously if there are no stats for any of the routes, the ACD values of all vendors, the minimal ACD, and maximal ACD will be all equal to the default ACD value.

The desired target load per vendor

The weighted rank of a route is computed as follows:

The route’s rank cannot be more than 1:

The best rank of 1 is possible only if there is only one working route and the ranks of all other routes are equal to zero. The sum of all ranks is always equal to 1:

To avoid divisions by zero assign a non-zero positive value to this (ACD zero) parameter (e.g. 1 second = 1/60). In general, the higher is the value of this parameter, the more vaguely, i.e. the less accented is be the prioritization of the best route.

The desired final load of a route is computed so as to guarantee a minimal traffic via the worst routes. The minimal traffic is needed for continuous quality tracking.

The expanded formula for computing the desired load values is the following:

The load represents a value from the n-th fraction of the load min to 1 (corresponding to a percentage up to 100%)

Similarly to the sum of ranks, the sum of loads is always equal to 1 (i.e. to 100%).

Below is an example of target loads (pink curve), as function of the set of 4 measured ACD values (the blue histograms). The minimal monitoring load is set to 40% which is shared across the 4 routes, constantly ensuring even to the worst route a 10% (the ¼ of the 40%) of the total traffic. The value of ACD zero was set to quasi 0.

The next two subsections are not required for the implementation of the algorithm. Skip these subsections if you are focused on the implementation.

The redundancy of ACD zero

This section is not required for the implementation.

In fact the ACD zero parameter is redundant and the formulas can be always replaced by simplified versions without this parameter. We can prove that for any combination of the following two parameters, the formulas can result the same with an appropriately chosen different value of load min:

There always exists a different load min returning the same results when used in simplified formulas without ACD zero:

The statement looks as follows, when expanded:

Proof

This section is not required for the implementation.

The formula for computing the load of a route can be rewritten as follows:

The new load min value, working without ACD zero, must be expressed as follows:

It remains to prove that the right sides of the above two formulas are identical:

Further simplifications show that the two equations are the same, therefore the suggestion is proved:

Though any combination of load min and, ACD min and ACD zero can be replaced by a single (new different) load min, that new load min is not necessary positive and is therefore hard to interpret logically. The joined Excel file shows a computation of the new virtual load min value and validates what was discussed above [xls].

Computation of the rejection rate

The rejection rate of the current route depends on the target loads of all routes with the lower or equal preferences in the billing:

The expanded formula of the rejection rate:

The following embedded Excel table shows a computation of reject rates for 4 routes (here the routes are sorted in the order of preference). The 4 target loads are computed randomly. The reject rate is computed according to above formulas. The last column is for validation. It computes back the load, based on the reject rate. We see that the loads computed based on reject rate match the initial target load values.

The formula in cell C3 for computation of the reject rate:

=SUMIF($A$2:$A$5,"<"&$A3,$B$2:$B$5)/SUMIF($A$2:$A$5,"<="&$A3,$B$2:$B$5)

Below is the formula in cell D3 for computation of the load, based on reject rates. The percentage of attempts seized (kept) on the next high priority route (preference 4) is equal to D4. The attempts received by that route (preference 4) are equal to D4/(1-C4). The attempts passed from that route (preference 4) to the current route (preference 3) are equal to D4/(1-C4)*C4. The attempts kept by current route (preference 3), i.e. the load of the route is equal to D4/(1-C4)*C4*(1-C3).

=D4/(1-C4)*C4*(1-C3)

A rejection rate on-line calculator (contains an example with 4 vendors) is available below:

Rejection Calculator [xls]

2009-10-20 through 2010-03-31: a two-vendor ACD routing system

A two vendor ACD quality routing system was designed and successfully tested on real voice traffic of about 200’000 minutes per month [1] [3]. The details of the architecture and tests are published [1]. The next step (presented above) is the multi-vendor solution. The subsections of this section present the basics of the two vendor system.

Background

Whenever there is a high demand for a certain phone destination, fake vendors appear in the market offering voice termination with false answer signal supervisions. The worst case scenario is often encountered, the answered signal is returned immediately and calls are being charged without being connected. Different techniques are used to keep the calling party on the line. One of these techniques is to play a record of a ring back tone (while the call is already being charged). Another, more sophisticated technique is to play a human voice randomly picked up from a set of records containing contents similar to: “hello, hello, I cannot hear you…” Apart the fact that these fallacious calls are charged at rates of real calls, such malicious routes seriously handicap the switching process. The system does not detect any failure on the signaling level and is unable to send new attempts via backup routes, the call technically considered as being already connected. Once the call flow falls into such a trap, the calls will continue being routed via the fraudulent route until a manual intervention.

Proposed solution

We suggest measuring ACD on different vendor connections and routing based on ACD. Fake calls are terminated by the customer earlier. The ACD of the vendor will ultimately drop if a fraction or all of its calls end up in fraudulent answering systems with wrong answer supervision.

In the proposed model, we consider a system with two vendors (Vendor A and Vendor B) terminating to a destination requiring the automatic quality control. We assume a billing system capable of LCR routing, handovers (assuming proper signaling), and of hard priorities. Both vendors have the same priority and an LCR is enabled.

We setup a (kamalio) SIP server which listens on two ports or IP addresses, and is configured such that the first port represents simply a transit to Vendor A, and the second port represents a transit to Vendor B.

The SIP transit server is equipped with two scripts recurrently connecting to the database of the billing system. The first script accesses the CDR tables and computes the current ACD values of vendor A and B (all calls to a given vendor must be considered irrespectively whether calls are landed directly or via the transit SIP server). The choice of the CDR chunk can be based for example on last 1’000 calls or on all calls of past 10 minutes. The second script monitors the rate and their validity date changes on the direct connections. Whenever a change occurs on direct connections (indicating on new tariffs from vendors A or B), an email is sent to the rate uploading personnel for updating also the rates of the clone connections (the email contains the new rate and validity date to apply).

Depending on the current ACD values the SIP transit shall prioritize one or the other vendor. The transit server does not have a right to handover or reroute the calls on its own. It will result in wrong billing, because the billing server will charge the account of the vendor it believes the calls are routed to. The only action the transit SIP server is allowed to; is the rejection of calls.

In our scheme, the rejection of calls alone is sufficient to determine any desired routing balance. In this example we assume the following priorities on the (true and clone) vendor connections. Both direct connections to the vendors share a low priority level equal to 5 so as to permit LCR. The two transit connections have higher priorities, so the calls are routed first via these connections and they will be handed over the principal direct connections only if both transit connections fail.

The transit SIP server shall reject or accept the calls on its two incoming ports at variable rates which are dynamically computed as functions of current ACD values of two vendors A and B. The rejection rate must be chosen so as to prioritize the route with higher ACD. However, for the sake of continuous measurements on all routes, call flow must be maintained also on the route with lower ACD but at a minimal level. A small fraction of healthy calls (i.e. not rejected by a true vendor) shall be constantly rejected on the best ACD link and accepted on the worst one.

The algorithm

We first translate the ACD values to rank values of the routes ranging from 0 to 1. The route with the higher ACD has the rank 1 (denoted also as 100%). The route with a shorter ACD has a rank equal to its ACD divided by the ACD of the best route.

Then assuming the minimal obligatory load for measurements, the loads of routes are linear functions of their ranks such that the low rank route has the minimal load when the rank is 0 and to 50% load when the rank is 1 (i.e. as good as the high rank route).

Finally the rejection rate (ranging from 0 to 1) on a route is a function of its load (ranging from 0 to 1) and of the priority of that route in the original billing system. The priority of the route in the billing system should not be hard-coded in the transit server but must be (periodically) retrieved (and cached) with a remote database query.

For demonstration of rejection intensities as functions of ACD values, an online rejection rate calculator is provided. The joined Excel file shows also implementations of the above equations with Excel formulas.

Rejection Calculator [xls]

Conclusions and further work

Examine the efficiency of a non linear load as a function of the route rank.

Generalize the presented schema and formulas for any number of routes (not only two).

This project is presently in progress, and the two-route architecture hopefully will be soon up and running.

Updates

2010-03-31

A quality routing system with two vendors is up and running on a test traffic of about 200'000 minutes per month:

http://switzernet.com/public/091029-ACDstat/

http://unappel.ch/public/091029-ACDstat/

Documentation of the current version as well as the details of the project are publicly available:

http://switzernet.com/public/100331-acd-quality-routing/

http://unappel.ch/public/100331-acd-quality-routing/

References

The software presently running on the transit SIP server

http://www.kamailio.org/

The billing server applying LCR, preferences, and charging the vendor accounts in this system

http://www.portaone.com/

History of a troubleshooting of a case with fake answer supervision

http://switzernet.com/company/090910-search-number-and-duration-calls/

http://switzernet.com/public/090910-quality-voice-armenia/

http://switzernet.com/company/090916-asr-armenia-verizon/

http://switzernet.com/company/090918-asr-armenia-colt/

ACD routing for fighting malicious routes with wrong signal supervision (this page)

http://switzernet.com/public/091020-acd-routing/

http://www.unappel.ch/2/public/091020-acd-routing/

http://unappel.ch/public/091020-acd-routing/

http://intarnet.com/2/public/091020-acd-routing/

http://parinternet.ch/2/public/091020-acd-routing/

Introduction to LCR and Quality Routing:

http://en.wikipedia.org/wiki/Least-cost_routing

Glossary

ACD Average Call Duration

ASR Answer Seizure Ratio

CDR Call Detail Record

LCR Least Cost Routing

* * *