Long time no blog. A lot of Lync projects recently, thought I might just share an experience from one of them.
The other day I was working on a migration project from OCS 2007R2 to Lync Server 2010. Everything went smooth, customer was moved to new pool and the modalities were working out, as well as the customer’s long sought-after Lync Mobile client.
Even Enterprise Voice, routed through the OCS Mediation at the time, was working as intended. Then we published a new topology with a PSTN gateway going from Lync to their existing PBX – still success on outgoing calls. And then, at last, dialin conferencing was moved (Application Endpoint) from OCS to Lync – nothing…
Since the trunk was to a legacy PBX, normalization was needed. My suspicions immediately fell on those. But I couldn’t find anything wrong with changing the Lync E164 format to PBX “external call prefix”, stripping PLUS and country code. Also, internal PBX series were being normalized leaving only the last four digits.
Luckily, the customer was ALSO running a separate Lync environment, hosting Lync for some customers of them (and they did not want to have their internal system on the same pool). So, comparing the settings with the trunk running from THAT Mediation service to the same PBX, I tried to import the same rules to the newly setup trunk, and…no. Nothing. Zip. The call was being rejected.
Enter log file deep dive. Sifting through Snooper files, as well as running WireShark, I realised that the incoming number was presented in the PBX four-digit internal style. Still, I already had normalization rules on the trunk to take care of PBX -> E164 formatting, and for some reason this was working on the “old” Lync server. Comparing the 200OK and the 404 NO MATCHING RULE, I notice that the successfully routed call has a different “tag”, and this was a clear reference to the Site Dial Plan:
The Lync server with inbound call failing, on the other hand, had a more “generic” description on that matter, but clearly pointing out that this “profile” did not lead to a successfully normalized number:
Further comparison showed me that both servers had empty Global number plans, whereas the “functional” one had a site dial plan while the “non-functional” only had user dial plans – migrated from OCS.
AS IT TURNS OUT Lync is looking for a way to normalize inbound calls, utilizing global or site (or potentially pool, haven’t tested that) dial plans. User dial plans will fail in such matter.
My solution was to add two normalization rules in the global dial plan, taking care of both PBX four-digit as well as non-E164 formatted numbers.
EDIT: It is definitively possible to apply a dial plan on the pool level, as a matter of preferrable to do so, as stated about service level PSTN gateway dial plan in this technet article.
Rune's blog about things I see and UC 