ACD Routing for Fighting Wrong Signal Supervision

 

Emin Gabrielyan

Switzernet Sŕrl

The Scientific Park of

Swiss Federal Institute of Technology

2010-03-312009-10-20

 

ACD Routing for Fighting Wrong Signal Supervision. 1

Background. 1

Proposed solution. 1

The algorithm.. 3

Conclusions and further work. 4

Updates. 4

2010-03-31. 4

References. 5

Glossary. 5

 

Background

 

For several highly demanded destinations, recently fake vendors appeared in the market offering voice termination but providing only false answer supervision. 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 the fallaciously established calls are charged at rates of real calls, such malicious routes seriously handicap the switching process. The system does not detect a failure on signaling level and is unable to attempt the call via backup routes, the call technically being already connected. Once the call flow falls into such 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 needing the discussed automatic quality control. There is a billing system capable of LCR routing, handovers (assuming proper signaling such as ‘no circuit/channel available’), and of hard priorities (but not capable of automatic quality routing). Both vendors have the same priority and an LCR is enabled.

 

 

We setup a (kamalio) SIP server which listens on two ports, 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 so as to result to minimal load when the rank is 0 and to 50% load when the rank is 1.

 

 

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://unappel.ch/public/091020-acd-routing/

 

Glossary

 

ACD    Average Call Duration

ASR     Answer Seizure Ratio

CDR    Call Detail Record

LCR     Least Cost Routing

 

 

*   *   *

Copyright © 2009, Switzernet

www.switzernet.com