Friday, September 9, 2011

Verifying Lync Trunk Translation Rules with your Phone

Greetings all.  It's been a while since the last real blog update.  This past summer was quite busy both work-wise and life-wise, so the blog posts fell by the wayside.  Consider it a summer hiatus, like TV.  As fall brings a new TV season, it also brings new blog posts, so read on....

If you've used trunk translation rules in Lync (and if you've followed my Enterprise Voice Best Practices series, you should be), you may have discovered a very annoying omission in the Voice Route Test Case window. 

Once you've created all your normalization rules, its a good idea to validate your dial plan and voice policies by running some numbers through the Voice Routing Test Case window.  The voice routing test case dialog box can be accessed from any of the tabs in the Voice Routing section of the Lync Control Panel.  Just click the little downwards facing chevron to expand the window.  The window will stay active no matter which tab you click on, which can be handy for testing changes as you go.

I usually find it best to select the checkbox beside Populate from user and selecting a valid Enterprise Voice-enabled user, so you can be sure you're testing the right dial plan and voice policy.

You'll notice that when I plug in a test 10-digit local phone number for a Vancouver based Lync deployment, it shows that it applies the correct normalization rule, picks the correct usage and the route.  If you've used the Dialing Rule Optimizer or followed my best practices for creating routes and trunk translation rules, a trunk translation rule should strip the +1 from the number before sending it to the PSTN.  However, the test case results do not show the trunk translation rule that would be applied to the number. 

The omission of the trunk translation rule from the results window can lead to the mistaken belief that the number isn't being sent out correctly.  It can also lead to general confusion, heart palpitations, sweaty palms and mild to severe incontinence.  I believe this is a serious omission that limits the usefulness of this otherwise great tool. 

Normally, the only way to verify the number is being formatted correctly once it leaves Lync is to use the Lync Logging Tool or IP gateway logs (if you've got one) to sift through until you find the information.  Either that or if the call completes successfully, that's a pretty good indication things are working as expected.  However, if you happen to have a Polycom CX500/600/700/3000 series Lync phone or Aastra Lync phone, you can easily validate what number is sent to the PSTN. 

When you dial a local number, the normalized number will be shown first (which will always start with +1), but the actual number sent to the PSTN will be shown in a smaller size below.  The first screengrab shows what it looks like when you dial a local number that should have the +1 stripped out.  The second shows a long distance number that should only strip the +.

Local Call

Long Distance Call

If you happen to have a Polycom or Aastra Lync deskphone, this is a great way to validate your trunk translation rules.  Hopefully, Microsoft will update the Voice Test Case app to include trunk translation rules in the future.

Many thanks to Tim from Rolling Thunder, who pointed this out to me during a discussion about trunk translation rules this morning.


  1. Hi,

    very good catch! Did you send a bugreport to MS?

  2. Interesting, but I don't see that on my Polycom CX600 phone, and I do have Trunk Translation Rules.

  3. Hey John,
    Do you have the latest patch on your CX600? I tested with .296 on a CX3000, as well as a CX700 (Tanjay).

    And for the anonymous poster above, no I haven't submitted a bugreport. Probably should bring this to someone's attention, but I'm pretty sure they've seen my blog.


  4. Hi Ken

    I was looking at your blog posts on LYNC and was wondering if you could help us ..we are a public sector company trying to implement Lync with in house expertise but are have few issues with dial plans etc.

    I'm perhaps looking at 1/2 days work to begin with..ifyou can help us please get in touch at - Thanks Vamsi

  5. Thx for the tip - I have been (and still am) really annoyed by the fact that this wasn't possible to test / be shown in the test cases

  6. I'm wondering how you handle the fact that for the Vancouver area things are such a mess with regard to Long Distance vs. Local calling subdivision? Not only do some NPAs in that region contain a mix of local and LD numbers, I've even found that there are many cases where numbers within an NXX a split between local and LD.

    Using online phone number registries I've managed to construct a functioning set of rules to distinguish local from LD (on another type of system within my environment), but given that those rules include over 300 number inspections, I've been reluctant to attempt to construct a normalization regex on my OCS servers to do the same thing.

    So, just wondering how someone else has dealt with that situation?

    1. Hey there,
      What people do in this situation is use my Lync Dialing Rule Optimizer ( It is designed to deal with exactly the situation you describe. Try it out and let me know how you like it.