VoIP Routing Part 2: Priority based Routing
Continuing discussion on inner workings of routing mechanisms in VoIP, let's discuss Priority based routing
Least Cost Routing or LCR discussed in previous post is not the only method of routing in telecom and VoIP in particular. There are cases when other routing methods can be more appropriate. Let's discuss another popular routing method: Priority Routing.
In the priority routing specific destination or breakout is explicitly routed to one or more carriers, regardless of the cost considerations. That might be due to many reasons, including contractual, legal, regulatory etc. In this case the routes are defined in fixed order, like in example below:
| Destination | Provider | Priority number |
| UK Mobile | Provider 2 | 1 |
| Provider 3 | 2 | |
| Provider 1 | 3 | |
| UK | Provider 3 | 1 |
| Provider 4 | 2 |
In the table above we assume smaller number of priority means highest choice, i. e. “first priority” is higher than “second priority” etc. So in case the call is being made to “UK mobile” numbers, the routing will return the providers in the following order:
Provider 2, Provider 3, Provider 1
What happens if for some reason call is unable to be established via any of the three choices? We know, that UK Mobile codes (447) are a subset of entire UK number range (44). Should we also include routes to UK itself? There is a chance that Provider 4 might deliver a call, but since it is not listed in UK Mobile destinations, we are not looking anywhere outside this destination.
Hunt-stop.
The setting which controls whether routing engine should look further, to the less specific code or not, is sometimes called hunt-stop (in some systems it is named “No Jump”). Setting it to “YES” will prevent routing engine from returning choices with less specific codes. Lets see table below:
| Destination | Hunt-stop | Provider | Priority number |
| UK Mobile | No | Provider 2 | 1 |
| Provider 3 | 2 | ||
| Provider 1 | 3 | ||
| UK | Yes | Provider 3 | 1 |
| Provider 4 | 2 |
The example above shows the scenario where hunt-stop is disabled for UK Mobile. Therefore the routing engine will also return choices for UK, i. e. less specific code. Note, that Provider 3 appears twice: in UK Mobile and UK. To avoid redundancy, the routing engine should not return that choice twice. The expected result for UK Mobile would be:
Provider 2, Provider 3, Provider 1, Provider 4
Equal Priority and Weights.
In some cases in priority routing we have two or more providers which we want to put on say priority. That is perfectly possible, and the routing engine would ideally return choices in the round robin fashion. In real life, however, routing engines are mostly stateless and weighted random is acceptable choice, given that number of calls usually is high enough for random choice to be accurate enough.
That also helps with the case where some of the same priority choices can accept more calls than other. In this cases we assign relative weights to the choices, like in table below:
| Destination | Hunt-stop | Provider | Priority number | Weight |
| UK Mobile | No | Provider 2 | 1 | 1 |
| Provider 3 | 1 | 3 | ||
| Provider 1 | 2 | N/A | ||
| UK | Yes | Provider 3 | 1 | N/A |
| Provider 4 | 2 | N/A |
So in case of call to UK Mobile, we would want to see approx 75% of calls going to Provider 3 as the first choice and 25% to the Provider 2 as the first choice.
To sum up, the choices would be:
- In 75% of all requests: Provider 3, Provider 2, Provider 1, Provider 4
- In 25% of all requests: Provider 2, Provider 3, Provider 1, Provider 4
Next we will discuss quality based routing.
