In the previous post we covered the Dialing Behaviors of our outbound call to 952–555–1111. In this post we will continue that investigation and focus on the Routing & Authorization of the call. Make sure to read part one of this post for full details.
- Investigating Dialing – Dialing Behaviors
- Investigating Dialing – Routing & Authorization – This Post
- Investigating Dialing – Dialing Behaviors of an Inbound Call
- Investigating Dialing – Inter Trunk Dialing
Vacant Number Range
Many people are surprised to learn that all inbound and outbound calls check the vacant number range. So when our call goes out to +19525551111 we see that we don’t match any numbers in the vacant number range and take no action.
However, since all outbound calls are flowing through this number range you can use the vacant number range for all sorts of interesting routing decisions. For example, maybe you have historically used a route like this to prevent unauthorized dialing of 900 and 967 numbers:
However, this process has one draw back, it blocks route matching and makes tracking those who are trying to make this call difficult. So instead, you could use the Vacant Number Range of +19000000000 to +19009999999 to capture all calls to this service and route them to an announcement service which then routes to the Human Resource department for example. Basically, you can have all sorts of fun for blocking internal users from dialing unwanted numbers.
Since we don’t match the vacant number range we move onto the next step.
Call Park Range
This check is interesting as you could potentially do this check twice depending on the call flow although in this trace the first check was skipped due to the global check. Like the vacant number range we could look in the same log and see if our number matches any Call Park information.
Here we can see there were no matches.
Have you wondered how the new Group Pickup Feature (introduced in February 2013: CU1 Patch for Lync Server 2013) works. They accomplish the group pickup by simultaneously ringing your end point and the call park service at the same time. So if your group pickup range was #100 to #149, you may have assigned #100 to User A and when that call arrives you can see the call sim ring into the call park service. It’s an interesting approach Microsoft decided to use here without having to build a new service for this one feature.
There are some very interesting implications of Call Park on incoming calls as well but we will save that for our next post.
Voice Policy, PSTN Usages and Routes
We have finally arrived at the actual routing and authorization of the call. It may feel like this process has taken a long time to get here but rest assured this is all done so fast the end user is unaware. Its first important to remember what a Voice Policy is, it’s a collection of PSTN Usages that have been assigned to the user. These PSTN usages are then connected to routes and that determines what the user is allowed to route to.
Although the Voice Policy and Routes are separate boxes on this slide it is important to remember that one does not work without the other. So it’s important to investigate these together. What happens is all routes are gathered in order based on the order of the PSTN Usages in the Voice Policy and then looped through to determine if a match exists. So when our outbound call for 952–555–1111 has reached this far, we can see in the OutboundRouting log a match to a PSTN Usage:
Which matches to this route:
It’s a small detail but it’s important to remember from a call flow perspective it’s a failure to match a PSTN usage that create the 403: No Route Found message. But our call found a matching usage and route so now it’s time move to the next step.
Other than the reference to Group Call Pickup (part of CU1 for Lync Server 2013) everything up to this point would be true for both Lync Server 2010 and Lync Server 2013. In Lync Server 2013 we have the option to modify both the called and calling number (in 2010 it was only the called number). This makes it very easy for use to move much of the transformation rules that once existed on the IP Gateway to Lync creating a single place for all normalization rules. This is my preferred approach so I can make my gateway deployments a set-it and forget-it deployment.
So here we have a simple set of trunk rules. Here we move the +1 from our calling number (our caller ID) and two simple trunk rules in this example:
In this trace you can see that I’m matching the remove rule to strip my E164 number down to only seven digits and my calling number is stripped down to only 10 digits.
And now the call reaches the end for Lync and is routed out to the IP Gateway/SIP Provider/Legacy PBX (who uses those anymore?). All of this tracing was done via OCSLogger or CLSLogging and all you need is Outbound Routing and TranslationApplication and use Snooper to view. Thur far we have discussed only an Outbound Call but in our next section we will discuss Inbound Call routing from the PSTN.