As you may have guessed by some of my recent posts, I have a client that is in the middle of a large cross-forest migration of their Skype4B environment.
The issue
As part of their requirements to cut users over, users will be getting new SIP addresses and are being cutover “step by step” instead of Big Bang style.
(I highly suggest watching those videos if you haven’t before)
Normally the solution to cut extensions over one by one is to place an SBC in front of the legacy PABX and use AD-based routing like so.
The issue with that solution in this scenario is these users don’t all have DID’s (Direct Inward Dials) like in standard deployment in Australia.
(For my North American readers, DID’s are given out like candy here. It’s quite normal to get a 100 DID range with a simple 10 channel PRI service. Partly because Mobile/Cell phones have their own area code countrywide. 04xx)
Extension based dialling is pretty common in North America as they don’t exactly have enough numbers for every person. Instead, companies use a receptionist or an AutoAttendant (typically Exchange UM in the case of Skype) to send the incoming PSTN calls to an IVR to ask the caller what extension they were attempting to reach.
Exchange then forwards the call back to Skype with the extension number which the user entered as the “To” address. We then use a normalization rule to add with an “;ext=xxx” suffix where xxx is the extension number the user dialled.
(If you need a brush up on Exchange UM, Jeff Schertz has a great article over here on it)
In this example, an inbound call from the sip carrier is addressed to “tel:+15551000”
The SBC only sees “555-1000” and thus routes the call to the legacy environment
Lync sends this to Exchange for processing and gets “tel:+15551000;ext=100” in return.
In summary; when a call comes in from the PSTN, the SBC only sees the AutoAttendant DID. Thus cant route the call to the appropriate environment.
Get the SBC to do it after Exchange?
So the solution is simple right?
Get Exchange to send the call to the SBC instead of the legacy Lync environment?
Not quite.
Most AD lookup configurations have the SBC’s strip off all the extra information when caching the AD data, removing the “;ext=xxx” suffix we need to locate the user. So even if Exchange or even the legacy Lync environment sends the call back to the SBC. It won’t find a match in its AD cache.
To fix this on a Sonus/Ribbon SBC we could turn Normalize Cache in the AD Config to False, but then we have a whole other kettle of fish to deal with.
(Note: This can have a major impact to your call routing as most existing lookups may no longer work. Make sure you understand the extra lookup data needed to correctly locate users in AD before enabling this!)
Here’s an example of when Normalize Cache set to True.
Notice I can use a number as “+2312312434” and get a result?
Here it is again with Normalize Cache set to False
Notice that the tel: must be present in the value for the lookup to succeed.
Not exactly what we are trying to achieve, and it relies on us getting the extension number in e164 format somehow, but we already have something that can make the routing decision for us with a little bit of fiddling.
The Lync/Skype reverse number lookup service.
Getting Skype4B to work for its money
So as I suggested before, the Skype reverse number lookup service can make the routing decisions for us! As we can see from this diagram from TechEd waaay back when… Lync / Skype will do a reverse number lookup on any inbound calls with a “user=phone” suffix. This helps prevent routing loops and getting charged for calls to numbers we own somewhere in our topology.
If there is no match to the reverse number lookup (because the user doesn’t exist) it will happily (and blindly) forward the call into the standard outbound calling process starting with normalisation.
How do we set it up then?
First, we need to make sure that the Exchange AA doesn’t go looking for the users attributes but instead blindly accepts whatever the caller types in.
So build your Exchange AA as you normally would but, as per the Exchange UM Doco (yeah it’s old) we need to adjust the Dialing authorization to Allow calls to any extension by navigating to the Exchange ECP > Unified Messaging > UM Dial Plans > Edit the Dial Plan > Edit the Dial Plan Policy > Dialling Authorization > Enable Calls to Any Extension
This is enabled by default when you set up UM, but it’s common to turn it off to reduce the risk of Toll Fraud
(Make sure you create an action to disable it once the migration is done!)
Now that we have that enabled, we can see the Skype server forwards the call to the AutoAttendant. Exchange plays the IVR menu and then blindly sends whatever I dial back to Skype with the “user=phone” attribute (this is important)
Now, we could update UM to point to the SBC, but then we have to deal with that whole AD lookup mess. So let’s get Skype’s default to routing handle it. That way we don’t need to do any weird translations that the next guy will never understand.
In Skype/Lync, make sure your Global Dial Plan has a translation pattern to match the extension number as dialled. (You should have this any way to update to E164 routing internally)
Update: I used to point out here that at this point the call will hit Skype’s Global Dial Plan and use whatever number translations are there. However, similar to Response Groups. Exchange Auto Attendant contact objects can be associated with a Skype Dial Plan of your choice, even if they don’t show in the object properties!
To update the dial plan, simply run
and wait a few minutes. I assume the same applies for voice policies too!
Make sure that a valid path exists through your Voice Policy > PSTN Usage > Route
Double-check you don’t have an announcement service running on that number range either. (Voice Features > Unassigned Number)
SBC configuration
Watch as Lync/Skype now forwards any unknown extension numbers back to the SBC, which you can then send to the other environment.
Over on the SBC we just create a translation table on the From Skype Signalling group to route the dialled number in e164 format.
Depending on your translation rules, you might need an unnormalized variant too.
And we need to get the Sonus to forward the extension info as well, so we setup a rule for that Simply create a new rule matching (.*) for Called Extension and outputting it to Called Extension. Not Number. This should be placed after your called number match.
And route it to the new Skype environment.
That’s it, you now have a fully automatic extension based routing system allowing users to be migrated from one AD forest to another one. One extension at a time.
You just need to remember to strip the TelURI from users SIP accounts in the old platform when you migrate them to the new environment. I do this as part of deactivating their old accounts regardless.
Hope this helps someone!
Version History
14th May – Initial Release
25th June – Updated to include details on Dial Plans for Exchange Contact Object