November 2013 Lync Dialing Rule Optimizer Updates

Since the move to use authentication in the Lync Dialing Rule Optimizer, I've been busy working behind the scenes to prepare the back-end for some cool new updates.

Back-End Changes

Firstly, I've been steadily moving away from XML for my data sources to a full-fledged SQL back-end. XML was great for the first while, but its been getting difficult to manage.  SQL offers much more robust querying, searching and sorting than XML, and opens up all kinds of possibilities for future features.  Now, changes and updates only have to be done in the database, and I don't have to touch the web pages.

Area Code Improvements

With the change to SQL for back-end databases, I've been able to drastically increase the number of area codes stored for countries like Germany.  Germany has thousands of area codes, which would overwhelm the drop-down style of listing area codes I've always done.  So for countries like Germany, you now enter the area code, and the Optimizer will show you the available cities from that area code.

Extension Extensions

You may notice additional options for extension entry than before.  Firstly, I've upped the extension limit from 10 to 20.  Secondly, I've added options to create your own rule suffixes for extension ranges.  So, if you're creating an extension range for your London, UK head office, you can assign a suffix like "HeadOffice", which will make the resulting normalization/routing rules use UK-London-20-HeadOffice, instead of the default UK-London-20-Internal-1.

You may also notice an additional checkbox column for "Single".  Sometimes, you may have users with their own DID, but maps to an internal extension that doesn't hold any relation to the DID.

For example, the company president may have a DID of +14165551234, and an internal extension of x200.  Your vice president may have a DID of +14165559876 and an extension of x201. Since there is no relationship between the DID and extension, you can't create a blanket normalization rule that will work with both of these.

With the new iteration of the Optimizer, you can easily tell the Optimizer to create individual normalization rule for each of these, simply by entering their DID and extension, and checking the box for Single.

Future updates may include a more Excel-like interface for extension entry that would allow cutting-and-pasting from Excel spreadsheets.  If you have the information already in a spreadsheet, it will make data entry MUCH simpler. 

Until then, enjoy, and if you have questions or problems, let me know.

Location Based Routing Bug with External Users

Location-based routing is a relatively new addition to Lync 2013.  It wasn't part of the initial release, but the first cumulative update added this much asked for feature.

In a nutshell, location-based routing routes calls based on the network subnet the user is calling from, rather than their defined home server pool. So, if a user is in the Rome office today, all their calls can route via the Rome PSTN gateway.  If that same user goes to the London office tomorrow, their calls will route out the London PSTN gateway.

Since then, I've done a number of deployments where location-based routing was used extensively.  During one remote deployment at a large company, I noticed that my calls were not routing via my assigned voice policy.  They were routing via a PSTN gateway that was not defined in the policy I should have been using. In fact, my calls were routing out from South America (I'm in Canada)!

After much troubleshooting, I realized that Lync was routing my calls based on the subnet of my home network.  Turns out that my home network subnet of 192.168.2.x matched up with a corporate subnet assigned to that South American location. Location-based routing was configured to route calls for that subnet out through the South American PSTN gateway.  To verify this, I changed my home subnet to another one used by location-based routing. Lo and behold, my calls started routing out that PSTN gateway.  Finally, I changed my subnet to one not defined for location-based routing, and my calls began routing as per my assigned voice policy.

I wasn't using a VPN, and as such, I was connecting through the Lync edge server. Lync was incorrectly using my home's private subnet for call routing decisions. Since administrators have no control over the subnets used by external users, this could obviously lead to many issues, not to mention increased telephony charges for calls routing out through the wrong location.

I filed a bug report with Microsoft, who confirmed this bug and promised a fix in a soon-to-be-released cumulative update.  I don't know the details of the fix, but I imagine it will be one of two things:

1. Lync's behaviour will change to ignore private subnet information for external connections for the purposes of location-based routing. This is probably an easy fix, and my money's on this one. 
2. Lync's behaviour will change to use the detected public IP address assigned by the ISP for routing decisions.  I like this one, because it gives administrators the option to include public networks for location-based call routing decisions. Its unlikely that many administrators would go through the trouble to do this, but it would be nice to have the option.  

I doubt this bug will affect may deployments, but its always good to be aware.

UPDATE (08-Jan-2014): The issue has been fixed in the January 2014 Cumulative Update.  Read the KB article here.