Major Upgrade to Dialing Rule Optimizer

If you've used the Dialing Rule Optimizer, you probably know how easy it makes it to create your North America least-cost routing rules for Lync.  After much work, I'm proud to unveil new functionality that will automate the process even more.

Originally, the Optimizer created a simple text file that you would copy and paste into Lync Powershell.  It would create the phone usage, route and trunk translation rules necessary for least cost routing for a given site.  If you input the name or IP address of your PSTN gateway, it would set it in the route, but if not, then the route would not be associated with a gateway.  The process was not very tolerant of errors either.  If you mistyped the name of the PSTN gateway, much of the script would fail.  The original output got you started, but you were still left to your own devices for pretty much everything else.

With this latest release, the Optimizer will provide you with a ready-made Powershell .PS1 script that will do the following:

1. Prompts you for a site to apply the script to
2. Checks for a PSTN gateway assigned to the site.  If one isn't found, the program will quit.
3. Creates a site-level Voice Policy (unless one already exists).
4. Creates standardized site-level normalization rules for local/long distance/international as per my Normalization Best Practices post.  If your site is in Canada, creates normalization rule for 310 toll free calls.
5. Creates separate PSTN Usages for Local, National and International and adds them to the Voice Policy as per my Usages and Routes Best Practices post.
6. Determines the PSTN gateway associated with the site. If no PSTN gateway is defined in the topology, you'll have to assign the routes and trunk translation rules manually after you set one up.
7. Creates routes for local, national, international, toll-free, and service numbers (411, 911 etc).  If your site is in Canada, creates an additional route for 310 calls.
8. Assigns those routes to the default PSTN gateway in the site.
9. Creates trunk translation rules for local calls, national and international calls.  If you entered an external dialing prefix on the web page, it will take this into account as well.  If you select the SIP Trunking option, then the trunk translation rules are not applied.

Preparation for the script is also much simpler.  All you need to do beforehand to get the most out of the script is to ensure that your sites all have a PSTN gateway assigned.  The script looks at the site and will try to apply the routes and translation rules to the default PSTN gateway assigned to that site.  If one isn't available, the script will still work, but you will have some manual labour to do afterwards.

Detailed Instructions

1. Ensure all your Lync sites have a default PSTN gateway assigned to it
2. Go to http://www.LyncOptimizer.com
3. Pick your country from the drop-down list.  Only a few are available now, but more will be added over time.
4. Enter the area code information for the site you want to apply the script to
5. If you have to enter 9 (or some other digit) to get an outside line, enter it in the appropriate box.
6. If you are using a SIP trunk that accepts E.164 phone numbers, select the Using SIP Trunk option.  If selected, the program will not create trunk translation rules.  All numbers will be sent to the next hop formated as E.164. Note: Don't select both an external access number AND SIP trunk options.  The two options are mutually exclusive. 
7. If you want Lync to block premium rate phone numbers (like 900 in North America) for all users, select the Block Premium Numbers checkbox.
8. If your North American local dialing area supports 7-digit dialing, select the 7-Digit Normalization checkbox.  If you're unsure if your local dialing area supports 7-digit dialing, leave this blank. Doesn't apply to other countries.
9. To receive updates should the ruleset change, enter your email address.  Only applies to North American users.
10. After pressing Generate Rules, wait a minute for the rules to be generated.
11. The program will provide 2 files.  The .PS1 file will do almost everything to get you up and running.  The .TXT file provides only the least-cost routing rules for North American users, and assumes you will be doing most of the other work.
12. Save the .PS1 file to your Lync server, start up the Lync Management Shell and run the script.
13. You will be prompted for the site to apply the rules to (as below).  Select the appropriate site and in a few seconds you'll have all you need to get started.

Here's what the Optimizer looks like for North American users:

Here's what it looks like for international users:

The International Optmizer doesn't have to do the same level of processing that it needs to do for North American numbers.  There is a clear deliniation between local and long distance calls, which makes creating rulesets much simpler.  Since the dialing rules aren't expected to change over time, you can't enter an email address for non-North American rule updates. Also, since this is designed as a Lync-only feature, you cannot (nor should you need to) create rulesets for the Dialogic or Audiocodes gateways.

Run the Optimizer once for each site, and apply the resulting .PS1 file.  The finished output should take care of all your basic external dialing scenarios using my best practices as laid out in my Enterprise Voice Best Practices posts.  You will just have to add normalization/routing rules for internal use as you see fit.

Below are some screenshots of what a virgin, never-touched Lync Enterprise Voice implementation will look like after applying the script (this example uses Toronto as the location).

Dial Plan

Voice Policy

Routes

Usages

Trunk Configuration (If SIP Trunk Option NOT Selected)

Blocked Premium Numbers (if selected)

The blocked premium number list is customized for each country.  The actual announcement can be customized either by using text-to-speech or audio files.  See this blog post for more information.
To provide failover and least cost routes for multiple sites, simply add the appropriate PSTN usages to your Voice Policies as desired.  Use this post as a guide for how to provide least-cost and failover routing between multiple sites.

If you still prefer to do things manually, or you already have a voice deployment you're happy with, the original script format is still included as a .txt file.  It will create the bare minimum PSTN usages and routes for least-cost routing.

I hope you find this useful.  Please let me know if you have any problems or questions.  If you find a bug in the script, PLEASE let me know so I can fix it.

Lync Enterprise Voice Best Practices - Extensions

In earlier posts, I've tried to outline what I consider to be best practices when it comes to Enterprise Voice in Lync.  There hasn't been a lot of detailed guidance on the subject, and while "my" way is certainly not the only way to do things, it has worked well for me and the other Lync consultants in my company.  If you haven't read my other posts on the subject, here they are in order:

E.164 Formatting

Normalization

Usages and Routes

In E.164 Formatting, I briefly touched on how to manage extensions for companies that don't use Direct Inward Dialing (DID) numbers for their users.  DIDs are usually known as "direct numbers", where you don't have to dial a central number to speak to a receptionist (or auto-attendant) to reach your target user. For cost, business or technical reasons, a company may not use DIDs for their internal users.  Instead, they assign everyone an extension off a main office number.

So, how to best handle this sort of situation in Lync? As mentioned in the E.164 formatting post, you should always use E.164 format for all your phone numbers.  For extensions, this should be:

+<country code><area or city code><local number>;ext=<internal extension>
Example:  +15197772222;ext=2345

For consistency more than anything, every number in a given office should have the same main number, followed by a unique extension.  Don't give in to the urge to just assign extensions to your users.  You will make your life difficult down the road when you have to deal with multiple locations and special routing scenarios.  Ideally, each office should use unique extension range, even if it is technically allowed to use the same extension (assuming the main number is different for each site).  For example, while the below example is allowed because the entire phone number is unique, even though the extensions are the same:

Bob at Waterloo Office: +15197778888;ext=2345
Lara at Toronto Office: +14163334444;ext=2345

it's better to have something like this:

Bob at Waterloo Office: +15197778888;ext=2345
Lara at Toronto Office: +14163334444;ext=3456

This way, you can easily create normalization rules so users can dial by extension across the company (even though they will likely dial by name most often).  Examples:

^(2\d{3})$ --> normalize to +15197778888;ext=$1
^(3\d{3})$ --> normalize to +14163334444;ext=$1

For outbound calling, the PSTN likely won't recognize the ;ext= format in the user's Caller ID and may default to show the main office number, but if it doesn't work, you can always use the Alternate caller ID in a route to make sure the main office number is sent as the Caller ID.

One thing to stress is that you cannot use the office number alone for any purpose in Lync if you've used that number for your extensions.  If you're using +14163334444;ext=3xxx for your users, you cannot use +14163334444 by itself for your Exchange auto-attendant or Response Group.  If you try this, all inbound calls will fail with an error along the lines of "485 Ambiguous".  If you find yourself in a situation where you are getting "485 Ambiguous", try using Tom Arbuthnot's Get-LyncNumberAssignment script that will help locate any rouge numbers that may be assigned to UM, common area phones etc.

If you've set up extension dialing and are getting the dreaded "485 Ambiguous" when trying to reach someone, its likely because you have defined your office number somewhere without an extension. 

To properly handle your auto-attendant or Response Group, it should be assigned an extension just as you would for any other user.  To make sure it will answer all inbound calls, create a pool-level dial plan that converts the main office number to the proper extension for your auto-attendant/response group.  For example:

Main office number: +12127778888
Main office response group: +12127778888;ext=2000

The pool-level normalization rule would be something like this:

^(12127778888)$ --> +12127778888;ext=2000

All calls coming into the main office number should be automatically routed to the appropriate auto-attendant/response group.

In conclusion, I hope this post answers a lot of the questions that come up with how to best handle extensions in Lync.  While there is nothing stopping you from assigning just the extension to the user, I truly believe that starting off with a consistent deployment around E.164 will make your life easier and will help prevent issues down the road.

UPDATE 22-Jul-2011:

There appears to be an issue with using my method of using the main office number as a base for all internal extensions in certain circumstances.  The issue seems to arise when the incoming phone number coming from the PSTN is prepended with a plus sign (a properly formatted E.164 phone number).  When Lync sees an incoming call that starts with a +, it assumes the number is properly formatted and does not apply any translation rules.  Since my method relies on a translation rule to add a ;ext=<ext> to ensure the incoming call is going to a unique number, Lync will return a 485 Ambiguous (because there are many numbers with the main number as a base) and drop the call.

This only occurs in situations where incoming calls are prepended with a plus sign. This will typically occur when using SIP providers or PSTN gateways (AudioCodes, Dialogic etc) that prefix incoming calls with a +.

There are several workarounds:

1. If you are using a SIP provider, they may be able to not send the + to your Lync server.  Call your provider and ask if this is an option.
2. If you are using a PSTN gateway or IP-PBX that is sending a +, you should be able to easily modify the incoming rule to drop the + sign (as your rule is most likely explicitly adding a +)
3. Create an MSPL script to forward the incoming number to the autoattendant directly.

I've confirmed this is the expected behaviour for Lync.  I've made my case to the right people, so maybe we'll see a change in the future.

Lync and Dialogic Troubleshooting Tips

If you've setup Enterprise Voice with Lync, you will often have to use some sort of media gateway to connect your Lync infrastructure to the PSTN (unless you're using a direct SIP provider, of course).  One of my favourite media gateways is the Dialogic DMG 2000.  It's extremely flexible and easy to setup.  I've been on more than a few deployments that used Dialogic gateways, and I'm constantly amazed at how quickly you can be up and running.  I usually tell the customer it may take an entire day to get it working right, but its always taken less than an hour from plugging it in to full inbound/outbound Lync PSTN calling.

This post isn't about how to setup a Dialogic to work with Lync.  Dialogic already has all the documentation (even a sample configuration file) to get you going in that respect.  I'm assuming you've already gotten Lync working with a Dialogic and you've got the latest firmware revision.

UPDATE (21-Sept-2011) - It appears that the www.dialogic.com/microsoftuc site is not working.  The documentation and sample config.ini used to be located at http://www.dialogic.com/microsoftuc/DMG2000_Lync_Config.zip.  The documentation can be viewed at Scribd via http://www.scribd.com/doc/58959088/Lync-DMG2000-Setup-1.
Once things are running, you may encounter some rather odd issues that could leave you scratching your head.  Here are a few of my experiences and how I resolved them.  Keep in mind that while the solutions worked for my client, it may not work for yours.  Also, make sure you backup your current configuration, so you can revert back to it should any of the changes you made break things.

Lync Attendant Console and RGS Formal Participation Policy

It's been quite a while since I've blogged about Lync. I've been a very busy boy trying to finish renovating my basement before the weather turns too nice to be stuck indoors. Thankfully, the crappiest spring I can remember has allowed me to get a lot done. Between that and my day job, it hasn't left me with much free time or energy to blog.

Last night, I was helping a client complete their migration from a legacy PBX to Lync Enterprise Voice. Their receptionist was going to use the Lync Attendant Console to manage incoming calls via a simple Response Group.  Since there were a few people who rotated into the receptionist role throughout the day, we needed a simple way to ensure that calls would only go to the person currently on reception duties.