The Misconceptions of Least Cost Routing (LCR)
Articles

The Misconceptions of Least Cost Routing (LCR)

A common problem for a telephony carrier who works with many different vendors is: How do I route my calls in a method that reduces my cost while preserving my quality of service? Least cost routing is a tempting way to address this concern. Least Cost Routing (LCR) is a method of directing inbound or outbound telephony traffic to a destination via a specific path based on price. An LCR can be accomplished via a device or a custom-written program that will sort vendors (or providers) by price. However, the often untold truth about least cost routing is that it can severely diminish the quality of service of a telephony product. The following blog post will describe a couple of situations to hopefully clarify any misconceptions that you might have of LCR.

Least Cost Routing Situation 1

Consider the telecommunications company, TeleWonderful. TeleWonderful works with five different vendors who each provide routes to a different subset of destinations, or NPANXX’s. TeleWonderful has just received a call that is originating in California with a CLI (Caller Line Identification) that has an NPANXX, or prefix, of 1-415-495-XXXX and terminating in North Carolina with a CLD (Caller Line Destination) that has a prefix of 1-910-436-XXXX. Of the five providers that TeleWonderful works with, only two of them provide routes to 1-910-436.
The least cost routing table for the above situation will be:
VendorDestination (Prefix)Price ($)
Vendor 119104360.005
Vendor 419104360.015
Vendor 21910436-
Vendor 31910436-
Vendor 51910436-
Based on the above least cost routing table, TeleWonderful would elect to route the call to North Carolina using Vendor 1.
That was a pretty easy example. Let’s get into more complicated situations now. What happens if the cheapest vendor cannot complete the call? Then what? Consider the second situation:

Least Cost Routing Situation 2

TeleWonderful has received a call originating from Texas with an NPANXX of 1-512-868-XXXX and a destination of Illinois with NPANXX of 1-630-782-XXXX. All five of TeleWonderful’s providers have routes available for this particular destination! See the least cost routing table below.
VendorDestination (Prefix)Price ($)
Vendor 216307820.001
Vendor 316307820.002
Vendor 116307820.0045
Vendor 516307820.008
Vendor 416307820.02
Based on the least call routing table and the diagram of the situation, it would seem that TeleWonderful should route the call using Vendor 2. However, in reality, things are never that simple. TeleWonderful is only allowed to send 10 calls per second (CPS) to Vendor 2 , and there are already 10 calls in route. Thus, Vendor 2 rejects the call with a SIP code of 503 (Service Unavailable). At this point, TeleWonderful will try to route the call using the next cheapest vendor, which in this case will be Vendor 3. Vendor 3, however, is quite unreliable and is experiencing their daily outage. They are unable to complete the call and respond with a SIP code of 503. Thankfully, the next cheapest vendor, Vendor 1, is available and ready to complete the call.
While TeleWonderful was able to successfully route the call, in the end, their post-dial-delay (PDD) would have increased three times. This metric might seem trivial to the casual reader - what’s the harm of waiting an extra second for my call to connect? In reality, the PDD in this situation would be much higher than one extra second. The total PDD here would be:

The time it took to get from TeleWonderful’s server to Vendor 2’s server
+
The time it took to return from Vendor 2’s server to TeleWonderful’s server
+
The time it took to re-route the call in TeleWonderful’s routing table
+
The time it took to get from TeleWonderful’s server to Vendor 3’s server
+
The time it took to return from Vendor 3’s server to TeleWonderful’s server
+
The time it took to re-route the call in TeleWonderful’s routing table
+
The time it took to get from TeleWonderful’s server to Vendor 1’s server
+
The time it took for Vendor 1 to route the call to the destination in Illinois

All of these steps take additional time. Imagine having to wait for more than eight stops every time you wanted to call a friend! Furthermore, every additional stop that the packet takes along its journey introduces an additional risk of packet loss, which directly correlates to poor Quality of Service (QoS). So now, you are not only waiting for more than eight stops to talk to your friend but when you finally get connected, you can’t even hear them!
Now, one might say: Even if I don’t least cost route, couldn’t the above situations still happen? For instance, if I don’t least cost route, I could still reach Vendor 2’s capacity. And Vendor 3 would still have an outage? Both of these points are true. With that being said, there are alternative ways of routing calls to avoid such issues.
For instance, you could introduce a load balancer to alleviate the capacity issues with Vendor 2. Routing based on past performance would prevent the failed call attempt to Vendor 3. Since TeleWonderful knows that Vendor 3 has performance issues, this would be reflected in their call statistics. While it's impossible to predict potential outages or issues with a vendor, routing can be done in a smart way to eliminate some of the unnecessary pain points of telephone calls such as PDD and packet loss.
Least cost routing is an extremely effective strategy to help telecommunications providers save money by lowering their cost. The strategy is inherent in the name - routing calls via the least costly method. Unfortunately, it's also an extremely effective strategy to increase PDD and lower call quality. It's important to keep in mind though that simply routing calls to the cheapest vendor isn't always the best option. In order to improve the call quality and thus the customer experience, it's important to route calls in a smart way to utilize the best vendors available.
Share on Social

Worth checking out

By using the site, you agree to our use of cookies. Accept and close Find out more here.