Monday, January 26, 2015

Out of the Gutter: The Ken Lasko Story, Part 1

I've really gotten a kick out of reading people's IT backstories on their blogs, so I thought I'd add mine in.  This will be much like the Twilight and Hunger Games film series.  There will be 3 parts, but the third part will be broken up into Part I and Part II to drag things out and to maximize profits.

April 1941, London, UK. The Germans had been bombing London for more than 6 months, in what had been called "the Blitz".  I was a teenager then.....no wait. That wasn't me.

Part I - Boyhood, but not as good as the movie

I grew up in a farmhouse in the middle of nowhere in central Ontario, Canada during the 1970's and
You can almost see the sweat in this true-to-life simulation.
80's. Our nearest neighbour was nearly a kilometer away, and we had lots of land to entertain me and my younger brother. We rode our bikes, explored the forest, played in barns; very wholesome stuff. My very first exposure to anything computer-related would have been the seminal Atari Pong video game, which we had in our Grade 1 classroom when I was 6 years old. Even with the simple graphics of the time, it was something that we loved to play when allowed. A few years later, I started to waste as much time as my parents would let me playing the growing number of arcade games located at our local mall. I can still remember playing Space Invaders, Asteroids and all those early classics with the precious few quarters I got for an allowance. I was never the video game master that I imagined I was in my mind.

The possibilities were endless!
My first experience with a real computer was the Commodore PET computer that resided in our classroom. I think it was Grade 5, which would have been 1982. I remember inserting a cassette tape and waiting for sometimes up to 30 minutes for the program to load. The longer it took, the better we thought the game would be. The only game I remember was some variation of Lunar Lander, which I thought was awesome. This was also my very first exposure to programming, which usually consisted of the following extremely complex BASIC program:
10  PRINT "<InsertSwearWordHere>";
20  GOTO 10

This would endlessly scroll the chosen swear word, but with the added feature of filling the entire screen, instead of just a single column, thanks to the addition of the semi-colon. This alone differentiated me from the other students, and pegged me as a "computer genius" (or maybe nerd). From that moment forward, I knew computers were going to be an important part of my life....actually no. It was just a way to waste time with games and to irritate teachers.

Look familiar?
My parents brought home the Magnavox Odyssey2 gaming system sometime during the same period. This thing was a true piece of crap, with bad graphics even by the very low standards of the day. My parents thought the built-in touch keyboard would encourage us to take up programming, but we had very little interest in this. We only played the various terrible knock-off games that were available, like KC Munchkin (think Pac-Man). Despite the general awfulness of the Odyssey2 games, we played the hell out of that thing.

A few years later (probably 1984), my parents brought home an odd-looking beige box with a small, heavy 16-colour CGA monitor attached.  This was yet another attempt to get my brother and I to "learn about these new-fangled computer things".  This was the very first PC, an IBM clone.  It had no hard drive. It had 640K of memory. Its only storage media was a pair of 5 1/4" floppy disk drives. I remember inserting the DOS disk, listening to the floppy drive buzz and churn away until finally a single A:\ prompt flashed at me. Without any manual to read, I thrashed my way around until I figured out how to get things done. And by "get things done", I meant "play video games".

It's Sexytime! Imagine that "CENSORED" box moving up and down,
and you get the idea. Mass parental hysteria ensued.
I have no idea how I did it, but I managed to get illicit copies of all sorts of games. This was long before the Internet, and BBS's were still years away. My favourites were the adventure games of the era, starting with King's Quest, then Police Quest, Space Quest, and the infamous Leisure Suit Larry series, which was the first to have "are you an adult?" verification, which was extremely simple for a young, determined kid to get around.

I didn't realize this at the time of course, but this was my very first interaction with Microsoft via an early version of MS-DOS. Little did I know just how much of an effect this would have on my life, just not in exactly the way my parents intended.  I became familiar with computers, even though I didn't use them much more than a medium for playing games.

Later on, as I became older, I used the PC for more than just games. I used it in high school to write
My high school picture
papers with WordPerfect when others were still either writing them by hand or typing them on a typewriter (yes, a typewriter). I printed out my assignments on a dot-matrix printer, and my teachers were impressed by the neatness and lack of liquid paper normally required on most typical type-written papers to hide the mistakes.

We eventually got a 1200 or 2400 baud modem (can't recall which), which allowed us to dial-up to local Bulletin Board Systems (BBS), and download games at blistering speeds. (a 1 MB game would take about an hour at 2400 bps). If my mother picked up the phone while we were downloading (and that happened a lot), she would hear a nice screech, and our download would get interrupted, forcing us to start over. More screeching would happen from both me for the wasted DL time, and my mother who couldn't use the phone any more.

Other than dabbling with computer games and word processing, I lived life like a normal teenager. Rode bicycles all over the place (got into racing and did pretty well), chased girls (not so well), watched TV (yes, Knight Rider was on my 'Must-See' list), and got into typical teenage mischief (all too well).

This continued until one fateful day in 1988, when I encountered something that would change my life....forever. (Best read like a movie trailer voiceover).

Coming soon, the mid-point of this thrilling saga: Part 2 - Higher Learning

Thursday, January 22, 2015

Service Number Formatting in Lync


I recently had the distinct pleasure of engaging the Lync community via Twitter to ask how many people normalized their service and emergency numbers to include a plus sign (+). I asked this question because I had come across a couple of SIP providers in both the US and internationally that expected E.164 (global numbers starting with a plus sign) phone numbers for all except for emergency and service numbers. To put it another way, they wanted a plus in front of all phone numbers except for emergency/service numbers.

My very informal poll results were as follows:
Use + for everything: 6 votes
No + for emergency/service numbers: 4 votes
It depends: 1 vote
A "lively" discussion ensued between @ucomsgeek and @CAnthonyCaragol (the C stands for "Corky", in case you were wondering) on the validity of using a + sign in front of numbers that are not dialable from outside the originating country. The discussion got a little crazy and we very nearly came to blows on several occasions. @ucomsgeek had to be admitted to the hospital with what can only be described as an "RFC induced heart palpitation".

I had traditionally used a + in front of everything, adhering to my mantra of "E.164, E.164, E.164".  This included service numbers like 911 in North America, or 112 in Europe, so they would get normalized to +911 and +112.  My experiences with SIP providers not wanting a + in front of those numbers made me think, which is a rare occurrence, and is usually followed by being distracted by shiny things. If SIP providers don't want a + in front of those types of numbers, there must be a good reason for it.

So, whenever I'm faced with the great unknown, I turned to the trusty Interweb to find answers. I didn't have to look far. Phone number formatting is governed by the E.164 standard published by the Telecommunication Standardization Sector of the International Telecommunication Union or ITU-T for short (which is a good thing, because having to say "the Telecommunication Standardization Sector of the International Telecommunication Union" gets tiresome).  E.164 number representation within the Tel URI format used in SIP is governed by RFC3966 published by the Internet Engineering Task Force (IETF).

Reading these documents is an enlightening and mind-expanding experience. The E.164 standard takes a lot of pages to say that an E.164 number consists of the country code, followed by area code (national destination code or NDC) and the subscriber number.

Other than that, it doesn't say anything about plus signs or anything else other than just boring numbers, so we turn our attention to the much more interesting and relevant RFC3966.

RFC3966 has a lot to say about how to format numbers for use in computer/telecom equipment. The first thing that struck me was that the plus sign is reserved ONLY for global numbers, meaning numbers that are globally unique and adhere to the E.164 standard described above.

Section 5.1 says:
   The 'telephone-subscriber' part of the URI indicates the number.  The
   phone number can be represented in either global (E.164) or local
   notation.  All phone numbers MUST use the global form unless they
   cannot be represented as such.  Numbers from private numbering plans,
   emergency ("911", "112"), and some directory-assistance numbers
   (e.g., "411") and other "service codes" (numbers of the form N11 in
   the United States) cannot be represented in global (E.164) form and
   need to be represented as a local number with a context.  Local
   numbers MUST be tagged with a 'phone-context'

Section 5.1.4 describes how to format a global number:
   Globally unique numbers are identified by the leading "+" character.
   Global numbers MUST be composed with the country (CC) and national
   (NSN) numbers as specified in E.123 [E.123] and E.164 [E.164].
   Globally unique numbers are unambiguous everywhere in the world and
   SHOULD be used.

So, since numbers like 911 are not global numbers, they can't be referenced with a plus sign, but have to be formatted with a context, which is described a little bit later.

Section 5.1.5 describes how to format a local number (which includes service/emergency numbers by definition of not being global numbers):
   Local numbers are unique only within a certain geographical area or a
   certain part of the telephone network, e.g., a private branch
   exchange (PBX), a state or province, a particular local exchange
   carrier, or a particular country.  URIs with local phone numbers
   should only appear in environments where all local entities can
   successfully set up the call by passing the number to the dialling
   software.  Digits needed for accessing an outside line, for example,
   are not included in local numbers.  Local numbers SHOULD NOT be used
   unless there is no way to represent the number as a global number.

Section 5.1.5 goes on to say more about how to format local numbers:
   Local numbers MUST have a 'phone-context' parameter that identifies
   the scope of their validity.  The parameter MUST be chosen to
   identify the local context within which the number is unique
   unambiguously.  Thus, the combination of the descriptor in the
   'phone-context' parameter and local number is again globally unique.
   The parameter value is defined by the assignee of the local number.
   It does NOT indicate a prefix that turns the local number into a
   global (E.164) number.

What the above says is that local numbers must use a specific parameter called "phone-context" to ensure there is no ambiguity with global numbers. A little further reading brings up 911 number formatting as an example:
   A context consisting of the initial digits of a global number does
   not imply that adding these to the local number will generate a valid
   E.164 number.  It might do so by coincidence, but this cannot be
   relied upon.  (For example, "911" should be labeled with the context
   "+1", but "+1-911" is not a valid E.164 number.)

So, for example, 911 should be formatted as tel:911;phone-context=+1 for North America, but clearly says that +1911 is not acceptable.  However, Lync doesn't support phone-context in normalization rules or routing logic (trust me, I tried), so we're kinda stuck if we want to be fully RFC3966 compliant with regards to emergency and service numbers.

We're left with two options for service/emergency numbers really, either use the plus sign or don't. Since the plus sign is supposed to be reserved for global numbers, we probably shouldn't use it for emergency/service numbers. But on the other hand, people are generally used to seeing all their dialed numbers in Lync magically get formatted with a plus sign when it matches up with a normalization rule, which gets taken as a sign that you're good to go (at least that's the way I take it).

But consider this weird little thought experiment. If you normalize 911 to +911, you could think that this represents a really short number within India (country code 91). Yes, I know that a country of more than a billion people is likely going to have more than 9 phones, but you get the idea. What if India decided you could dial the Prime Minister of India by dialing "1"? Then anybody in North America trying to have an engaging conversation with Narendra Modi would end up talking to North American emergency services instead, which would be baffling for both sides.

Another possibility is that you could inadvertently route emergency calls to a global destination. Imagine you have a Lync server in India, and you decide to use least-cost routing to save on toll costs by routing any India-bound call to that Lync server. You configure a route and PSTN usage that sends any call starting with +91 to the India Lync gateway. You inadvertently put that PSTN usage above a PSTN usage meant for local service numbers. Now any call to 911 gets routed to India, and will most likely fail.

You could say the solution to the above scenario is just to make sure that service PSTN usages are above any international PSTN usage, but I'm a fan of engineering solutions that don't rely on someone setting things in exactly the proper order to get the desired results. I'm thinking of administrator/human fault tolerance here.

Rather than say the odds of any given service number conflicting with a real global number is vanishingly small (probably true, but you can't know for certain.....at least until the Lync Optimizer has dial rules for every country in the world), I'd rather ensure with 100% certainty it won't happen, by not putting a plus in front of emergency/service numbers.

Lync will happily route numbers with or without a plus, as long as your routing logic allows for it. You could build your entire Lync Enterprise Voice deployment around not using plus signs at all if you wanted to, but I wouldn't advise it, mostly because of Lync federation. Published phone numbers from federated contacts with a plus sign would not route in a deployment built around not using the plus sign.

So, there you have it. This blog post has convinced me that not using a plus sign for non-global numbers is the way to go.  I've updated the Lync Optimizer code to follow this tweak in best practices. What are your thoughts?  Does this change your view?  Does this very long blog post on the topic of a plus sign make you fear for my sanity? Let me know in the comments.

Wednesday, January 21, 2015

Adventures in Normalization

One of the things that differentiate Lync from its competitors is its reliance on 3rd party peripherals like deskphones. This is often touted as a Good Thing, since you're not locked into a single vendor for phones. Phones from single-vendor solutions are often more expensive than an equivalent Lync phone simply because you can't get them from anywhere else, so competition is low and prices are higher.

Since Lync phones are provided by different vendors, there is naturally a lot of variation in the specific details on how things work. Microsoft has alleviated this somewhat by instituting a Lync-qualified devices program.  This is a fairly thorough program that puts devices through their paces to ensure they function properly within Lync. 

However rigorous the program, little details slip through the cracks. One of the details that I've noticed is how different phones (and even the Lync client) handle regular expressions in different ways. For anyone familiar with the minutiae (thanks Word of the Day Calendar) of Lync Enterprise Voice, regular expressions are used for phone number normalization and routing. 

All Lync-qualified devices handle basic regex in the same manner. For most people, this is not an issue, but sometimes you need to use lesser-known regex patterns to accomplish certain goals. When you try to get fancy with regex, things sometimes break down with disparate results between clients and phones. 

Over the years, I've heard about and personally experienced situations where Lync Optimizer-generated regex doesn't work on specific phones. The affected vendors have eventually fixed these issues, but I figured that I should do some hardcore 60 Minutes style investigation into just how well different devices handle some of the more esoteric regex patterns out there. 

To do this, I used my wide variety of Lync deskphones I have available for testing in my home lab.  (You should hear what it sounds like when someone phones me.  Everything is ringing and flashing, and I usually go "AAAAhhhhh" and run out of the room.)  I used a Polycom VVX 600, a Polycom CX600, a Snom 760, and an old LG-Nortel "Tanjay" series phone.  My AudioCodes 440HD wasn't connecting to our Lync server at the time, so it was left out of testing. Every phone was updated with the latest firmware available at testing time. 

For the first round of the Lync Normalization Olympics, I decided to keep it simple, using some of the rule formats commonly used by the Lync Optimizer.  I input the normalization rules into Lync via the Control Panel, and I used the "Create voice routing test case information" to see how Lync Control Panel would interpret the regex, and included that in the results too. For all the rulesets, I used a unique "identifier" for each rule to allow me to setup a series that I could test all at once.  

Commas

First off, I used a regex rule that included a comma, which I had heard caused normalization issues with one particular vendor. In the below example, I'm looking for a pattern of numbers that starts with 999 followed by 10 or 11 digits. The 999 gets stripped and puts a + in its place.

Pattern: ^999(\d{10,11})$
Translation: +$1
Input number: 99915552223333 then 9995552223333
Expected output: +15552223333 then +5552223333

Control Panel
Lync Client
Tanjay Phone
Polycom CX
Polycom VVX
Snom
+15552223333
+15552223333
+15552223333
+15552223333
+15552223333
+15552223333
+5552223333
+5552223333
+5552223333
+5552223333
+5552223333
+5552223333
Everything passed that one with flying colours, so rumours of a phone type not handling commas seem to no longer apply.

Dealing with Extensions, Part I

Another common rule used in the Optimizer is a rule to accept any dialed number, but strip out any extensions and leave it as an externally routable E.164 number. This rule was meant mostly for click-to-dial from the Lync client, but I did hear about a particular vendor's phone not being able to parse that particular rule. In the next example, I'm looking for a pattern of numbers that starts with 998 followed by 11 digits, followed by some regex that would strip anything else beyond the 11 digits. The 998 gets stripped and puts a + in its place.

Pattern: ^998(\d{11})\d*(\D+\d+)?$
Translation: +$1
Input number: 99815552223333
Expected output: +15552223333

Control Panel
Lync Client
Tanjay Phone
Polycom CX
Polycom VVX
Snom
+15552223333
+15552223333
+15552223333
+15552223333
+15552223333
+15552223333
Everything passed that one with flying colours, so rumours of a phone type not parsing those rules seem to no longer apply.

Dealing with Extensions, Part II

The next rule test is a variation on the first example above, using a slightly different regex pattern to strip any extension. This format was used a long time ago in the Lync Optimizer, but was replaced with the "cleaner" looking version above.  One person told me he used this format to get around an issue with a particular phone vendor's issue parsing the previous example's format.

Pattern: ^997(\d{11})(\s*\S*)*?$
Translation: +$1
Input number: 99715552223333
Expected output: +15552223333

Control Panel
Lync Client
Tanjay Phone
Polycom CX
Polycom VVX
Snom
+15552223333
+15552223333
+15552223333
+15552223333
+15552223333
+15552223333
Again, no issues on any platform.

Extensions with Optional Site Code

In companies with multiple sites that provide its users with extension dialing, its often necessary to use site codes to properly differentiate one site from another. This is especially true if there are overlapping extension ranges originating from legacy PBXs. So, for a company using 4-digit extensions, they may prepend a site code to ensure uniqueness. So, Site #101 could use 1015xxx for their extension range, and Site #102 could use 1025xxx for their extension range.

One particular company wanted to ensure that users within any given site could dial their own users by extension without the prepended site code, but still allow them to enter the site code if they wanted to. I did this in one rule by using a bit of fancy regex. In the below example, a user should be able to enter the extension with or without the 996 "site code".

Pattern: ^(?:996)?(5\d{3})$$
Translation: +1555222$1
Input number: 9965000 then 5000
Expected output: +15552225000

Control Panel
Lync Client
Tanjay Phone
Polycom CX
Polycom VVX
Snom
+15552225000
+15552225000
+15552225000
+15552225000
+15552225000
+15552225000
+15552225000
+15552225000
+15552225000
+15552225000
+15552225000
+15552225000
Sigh, once again, no issues on any platform.

OK, boooooring. All the phones passed the basic regex tests without issue. Not at all "exciting". I use "exciting" in quotes, because how exciting can the topic of normalization be?

Multiple Replacement Strings

Sometimes you need to use multiple replacement strings in a rule (ie $1, $2 etc). Rumour has it some phones have issues with this.

Pattern: ^996(\d{3})000(\d{7})$
Translation: +1$1$2
Input number: 9965550002223333
Expected output: +15552223333

Control Panel
Lync Client
Tanjay Phone
Polycom CX
Polycom VVX
Snom
+15552223333
+15552223333
+15552223333
+15552223333
+15552223333
+15552223333
Running out of ways to say "No issues".


Advanced Normalization Tests 

To really gauge how well a phones' regex engine functions, we have to throw at it some regex that would only be used in very specific circumstances. 

For example, let's say I have a need to translate a set of digits into a pattern where those digits are buried within other numbers.  For example, I want to take 92xx and translate it to +155592xx999.  So, 9201 translates to +15559201999.  If you try to create a pattern like ^(92\d{2})$ and translate it to +1555$1999, there is ambiguity on whether you mean +1555 $1 999 or +1555 $19 99. 

Normally, I would follow the .NET regex reference which has different ways of dealing with this, but none of them work in the Lync client.  I did stumble upon one that did work, even though it isn’t a valid .NET expression.  Not only that, but testing with other phones gave different results most of the time.

I tried various patterns, and plugged in 9100, 9200, 9300 etc to see the results in both Control Panel and Lync softclient and desk phones. The results proved interesting.

Pattern: ^(91\d{2})$
Translation: +1555$1999
Input number: 9100
Expected output: Expect failure, but want to see how various devices handle this situation.

Control Panel
Lync Client
Tanjay Phone
Polycom CX
Polycom VVX
Snom
+1555$1999
+155599
+15559100999
+15559100999
No match
+1555
Seems as though the old Tanjay and CX-series phone work in this situation, but nothing else. No big deal, because I wouldn't expect any consistent behaviour here.


Pattern: ^(92\d{2})$
Translation: +1555${1}999
Input number: 9200
Expected output: +15559200999

Control Panel
Lync Client
Tanjay Phone
Polycom CX
Polycom VVX
Snom
+15559200999
No match
+15559200999
+15559200999
+15559200999
No match
Using ${1} is a valid way to prevent any ambiguity between $1 or $19 in this example. Sadly only the Lync client and the Snom don't respect this valid regex.


Pattern: ^(93\d{2})$
Translation: +1555$_999
Input number: 9300
Expected output: +15559300999

Control Panel
Lync Client
Tanjay Phone
Polycom CX
Polycom VVX
Snom
+15559300999
No match
No match
No match
+15559300999
No match
Using $_ is a way to substitute the entire string. Not ideal code-wise, but wanted to see if it would work.  Only the Control Panel and Polycom VVX phones properly parsed it.


Pattern: ^(?<1>94\d{2})$
Translation: +1555${1}999
Input number: 9400
Expected output: +15559400999

Control Panel
Lync Client
Tanjay Phone
Polycom CX
Polycom VVX
Snom
+15559400999
No match
No match
No match
+15559400999
No match
This is a valid .NET regex method to use named replacement strings instead of numeric. So, I could have easily used ^(?<DigItDude>94\d{2})$ -->  +1555${DigItDude}999.  Again, only the Control Panel and Polycom VVX phones properly parsed it.


Pattern: ^(95\d{2})$
Translation: +1555($1)999
Input number: 9500
Expected output: +15559500999

Control Panel
Lync Client
Tanjay Phone
Polycom CX
Polycom VVX
Snom
+1555(9500)999
+15559500999
+15559500999
+15559500999
+15559400999
+1555(9500)999
This is actually not a valid .NET regex method. Surprisingly, all the devices except for the Snom managed to parse it correctly.

Conclusions

As long as your phone number normalization requirements don't require any digit replacement buried within other digits, you can safely use just about any Lync-qualified device.  However, if you know in advance that you have such a requirement (and its very unlikely that you would), I would avoid Snom phones at this time, simply because they couldn't handle any of the advanced regex I threw at them in my attempts to solve that specific issue.

The way I see it, if I build a regex pattern in Lync Control Panel, I should be able to trust that every single device will parse that regex pattern the same way.  I find it rather annoying that there isn't any rigorous checking to see if vendors adhere to .NET regex standards. On that front, I feel Microsoft needs to be more diligent with their phone qualification process.  Its these little details that can lead to frustration for anybody deploying Lync Enterprise Voice.

If you got to the end of this post and are still not asleep.....congratulations!  This post has been entered in the "Most Boring Tech Post of the Year" for 2015. Yes, I know its early, but I think this is an early front-runner for the win.

Wednesday, November 19, 2014

The Importance of Lync Location Policies

Lync Location Policies are used to specify how to deal with emergency calls originating from Lync clients.  Quite a bit has been written about location policies and how they are used in E911 emergency dialing scenarios (for a few examples, see Technet or Mark King's UnplugthePBX blog).


Unfortunately, E911 only exists in the US, so anybody reading the documentation outside the US might conclude that location policies aren't required, and that emergency calls can be routed as other normal calls. While this is technically true, location policies still provide some critically important functions in specific scenarios that may not be apparent until you have to deal with them firsthand.

The Problem

Imagine the following two common scenarios:
  1. Your company has a single site spread across several floors of a building and everyone is assigned an extension, instead of a full directly-dialable phone number (DID). Your company has a single main office external phone number which rings to reception.
  2. Your company uses a centralized SIP trunk for normal calls, but all remote sites are configured with small PSTN gateways used to provide Lync-based local emergency dialing via a few analog lines.  Each user have their own dedicated directly-dialable phone number.  Users are assigned to a voice policy that ensures that emergency calls will route out the local PSTN gateway. 
For scenario #1, if someone within the office calls the emergency service applicable for their country (lets use 112, a common emergency number in Europe and many parts of the world), the number that will be presented to emergency services will be your main office number. 

For scenario #2, if someone from a remote office calls 112, the phone number that will be presented to emergency services will be that of the analog line assigned to the PSTN gateway. 

For both scenarios, you might be thinking "OK, so emergency calls go out the proper gateway, and emergency services will know where the office is. What's your point?"  You're correct in that emergency services will know the office location and will be able to dispatch personnel as required, but now think about these two factors:
  1. The user who called 112 accidentally hangs up because that zombie finally caught up to him.  What happens next (other than you now have two zombies)?  We'll call it the "Hang-up of Death".
  2. What happens when someone travels from their usual office to another and has to call emergency services because of....yeah, zombies?  It's the "Travelling Salesman of Doom".

The Hang-Up of Death

For #1, the typical response from emergency services is to re-dial the number that will show up on their console. In the single office/extension scenario, they will reach reception who may have no idea about who called 112, which can waste valuable time, depending on how fast the zombie horde grows.

In the remote site scenario with a dedicated analog phone line, emergency services would redial the analog number, and the call would ring endlessly, since its not likely that anybody considered someone calling inbound to an emergency number.  Or if someone was bright enough to forward incoming calls to reception, they still might not have any idea on who called 112 in the first place, again wasting valuable zombie killing time.

Travelling Salesman of Doom

For the unfortunate travelling user in #2, remember that unless you've implemented location-based routing, the user's calling behaviour won't change based on their current location.  If they call 112, then the call will route out the user's normal PSTN gateway which means emergency services will show up in their normal office, while our poor guy gets chased down by zombies.  If location-based routing has been implemented, then we still have to deal with the fact that reception at the local site still has no idea where the zombie attack is taking place.

The Solution

As you hopefully have discerned, location policies can help with both of these situations very well.

Firstly, location polices can be configured to notify one or more users by IM that someone's called emergency services. This way, when emergency services shows up, or if they have to call back, reception or security or whoever will have a bit more information about the situation than they would otherwise.

Secondly, location policies can be assigned to Lync network sites, which means that emergency calls will go out the proper gateway no matter where the user is typically situated.  This works very similarly to location-based routing, except that it's only for emergency calls.

Takeaways

If you are outside the US, you should still configure location policies for every site that has a PSTN gateway.  Consider doing the following:
  • Configure Lync network sites and subnets for everywhere that Lync users could go.
  • Configure location policies and assign them to each Lync network site, and set it to use the local PSTN gateway for emergency calls. Check the box marked "Enable Enhanced 9-1-1 (E9-1-1)" even if you don't use E911. This seems to be a prerequisite for emergency dialing via Location Policies to work at all, despite what Technet says.

  • Assign the appropriate default location policy to every user, to act as a fallback in case they are outside a Lync-defined subnet. 
  • Configure the notification URI field* in the location policy so that the appropriate people are aware whenever the configured emergency number is dialed.
  • If using analog gateways for emergency dialing only, make sure that inbound calls route to the appropriate person, should emergency services need to call back (ideally the same person who's been assigned to the notification URI field).
  • Consider populating the location information services (LIS) database even if outside the US, because this can help reception figure out where the person who called emergency services is located.
* A special note about the the Conferencing URI fields: You probably noticed these fields, which implies you can conference someone in when they dial the emergency number. Unfortunately, this doesn't work unless you're actually using an E911 provider in the US. If you're outside the US, you can enter values here to your heart's content, but it won't do anything. Boo-urns! Thanks to C. Anthony Caragol (check out his LyncFix blog) for bringing this annoying little tidbit to my attention.

For detailed instructions on how to configure Lync network sites and location policies for non-US locations, I strongly recommend Elan Shudnow's blog post on the subject.

Tuesday, October 7, 2014

Lync Enterprise Voice Misconceptions #3 - Inter-trunk Routing

During my travels across the Lync Enterprise Voice landscape, I come across numerous Lync deployments that make some fundamental mistakes in how to manage phone numbers, call routing and other details.  I've covered a lot of these details in parts of my OTHER Enterprise Voice Best Practices, but its obviously a lot to take in, and I've seen enough of the same sort of errors in the wild that prompted me to do this series.

Last week's episode talked about how to properly use the external access prefix in Lync. This week, we're talking about...

#3 - Inter-Trunk Routing

If you've ever manually created trunk translation rules for a PSTN gateway in Lync, you've probably noticed the "Associated PSTN Usages" section.


The wording is vague, and even Technet's description of the setting doesn't tell you much.


From what I've seen in multiple deployments, people tend to add the PSTN Usages that were created specifically for the particular trunk, which sort of makes sense if you use Technet's description as your only guide.

Some other places on the Internet take this idea even further, and imply that this section is used to define the PSTN usages that are allowed to use the specified trunk. If you think about it, you already accomplish this by defining the PSTN Usage/route combination without having to do anything else, so that can't be right either.

Now, you might be aware that Microsoft mentions in their Technet planning documentation that Lync can do "inter-trunk routing".  From their own documentation:
This new capability enables Lync Server to provide call control functionalities to downstream telephony systems. Intertrunk routing can interconnect an IP-PBX to a public switched telephone network (PSTN) gateway so that calls from a private branch exchange (PBX) phone can be routed to the PSTN, and incoming PSTN calls can be routed to a PBX phone. Similarly, Lync Server can interconnect two or more IP-PBX systems so that calls can be placed and received between PBX phones from the different IP-PBX systems.

In more general terms, Lync can pass inbound phone calls on to a different destination, which could be another PBX system or even back out to the PSTN.  So, now you're thinking "That's a great feature, but what does this have to do with Associated PSTN Usages?"  Since the title of this article says "Inter-Trunk Routing", it should dawn on you that "Associated PSTN Usages" has something to do with inter-trunk routing.  If it doesn't, then lie down a while and come back after a good nap.

As you hopefully have surmised by now, inter-trunk routing is done using "Associated PSTN Usages" from within a trunk.  The details behind how to do this are helpfully discussed in some of my own blog posts, Technet and also those by fellow Lync MVP Richard Brynteson:
http://ucken.blogspot.com/2013/06/inter-trunk-routing-in-lync-2013.html
http://masteringlync.com/2013/06/07/inter-trunk-routing-deep-dive/
http://technet.microsoft.com/en-us/library/gg425831.aspx

To summarize those blog posts, if an incoming call from a trunk can't be routed to an internal user, it will attempt to route the call to an alternate trunk, if there is a matching PSTN Usage/route combination assigned to the incoming trunk.

When people add the PSTN usages to a trunk that are already assigned to that very same trunk, incoming calls could potentially be sent back out the same way they came in, if there isn't a matching user in Lync. This could result in odd behaviour, including calls bouncing back and forth between a PBX and Lync, in what I call the "Telecom Routing Donut of Doom".  Fortunately, in most cases, adding PSTN usages to the trunk has no effect, since there is almost always a Lync user assigned to the incoming phone numbers.

I've seen numerous deployments where they've added PSTN usages willy-nilly (my Word-of-the-Day calendar entry for today).  If I see those, my next question is "Oh, so you're using inter-trunk routing."  If the reply I get back is some variation of  "What's inter-trunk routing?", then I remove those PSTN usages from the trunk configuration.

There you have it.  Tune in next time (not necessarily next week, since I'm bad at reading calendars) where we talk about something else that I haven't quite figured out yet.

Thursday, September 25, 2014

Lync Enterprise Voice Misconceptions #2 - External Access Prefixes

During my travels across the Lync Enterprise Voice landscape, I come across numerous Lync deployments that make some fundamental mistakes in how to manage phone numbers, call routing and other details.  I've covered a lot of these details in parts of my OTHER Enterprise Voice Best Practices, but its obviously a lot to take in, and I've seen enough of the same sort of errors in the wild that prompted me to do this series.

Last week's episode talked about common errors when setting up resiliency/failover routing. This week, we're talking about...

#2 - External Access Prefixes

A lasting legacy of the PBX era is the concept of dialing an external access prefix to make a call to the outside world.  In many deployments, you have to dial a 9 or 8 or something to open a channel to the PSTN.  In some systems, when you press 9 (or whatever the prefix is, I'm going to assume the external access prefix is 9 throughout this article), you can hear the change in dial tone as you actually open a connection to the PSTN.

There are many reasons for using an external access prefix, one of the biggest is to provide a clear demarcation between internal and external calls. When dialing "off-hook" - meaning the user picks up the handset, hears a dialtone then starts dialing the number on the keypad - the PBX needs to know where to send the call based on the digits entered on the keypad.  This might sound obvious, but if you've punched in the digits 2-1-2-3, the PBX needs to know if you want to connect to someone at extension 2123, or if you're just in the process of dialing an external New York number that happens to start with 2123.  If you punched in 2123 and meant to reach extension 2123, then the PBX will connect your call to that extension and everybody's happy. But if you meant to dial New York number 2123334444, then you will be understandably frustrated that you were connected to extension 2123 instead.

The external access prefix deals with this issue in a neat and tidy way. When you dial off-hook, if you enter the external access prefix before dialing your number, then the PBX will not attempt to connect you to an internal extension as you punch in digits.  So, when you dial 92123, the PBX won't attempt to route your call to extension 2123, and will instead wait for the user to enter the remaining digits necessary to complete a call on the PSTN.

In many Lync Enterprise Voice deployments, Lync is connected to the PSTN through an existing PBX which gives Lync both access to the PSTN as well as phones on the PBX. Since Lync's PSTN access is via the PBX, then this means that calls that come from Lync usually needs to have the PBX's external access prefix added in front of PSTN-bound calls.

I've seen many deployments where administrators do one of two things:
  1. They normalize dialed numbers in Lync to include the 9
  2. They create a normalization rule where users have to dial 9, but they strip it out, leaving a properly formatted E.164 number, using a rule like ^9(\d{10})$ --> +1$1. They then add the 9 using a trunk translation rule before sending to the PBX.
With #1, this breaks Ken's universal E.164 rule, which states: "NORMALIZE EVERY NUMBER TO E.164!!!"  If you don't know what E.164 is, I recommend you check out this post on the topic.  For example, if your normalized number for our earlier example is +912123334444, that number is technically a phone number in Chinchwad, India (which incidentally is now on my list of funny-sounding place names).  91 is the country code for India, and 212 is the area code for Chinchwad.

The ramifications of choosing this path is that you have to adjust everything else in Lync to accommodate what you started with adding the 9 to all normalized numbers.  This means routes, and even phone numbers in Active Directory.  You may argue that this is OK for you, because you have a single site, and you don't have any need to call India. But AD phone numbers can populate users' contact lists on their mobile phones, and they most certainly don't want to be dialing India when they mean to call New York. You could do some additional work to deal with this situation, but it gets messy very fast and doesn't scale beyond a single site.  For example, what if you have a second site that doesn't use 9 for dialing externally?  If you have to route calls from the first site for redundancy, then you'd have to make all sorts of rules in Site B to deal with how you initially set things up in Site A.  As you add sites, this scheme would quickly become unmanageable. 

Case #2 is closer to the correct way to do things. Dialed numbers are ultimately formatted to E.164 standards which is good. Since the PBX ultimately requires numbers are prepended with a 9, we can do this with trunk translation rules. Its trivial to add a 9 to every call that routes out to the PBX. However, you shouldn't have to manually create normalization rules that force users to enter a 9.  If you recall from the beginning of this article, the external access prefix is meant to help people who do off-hook dialing. When dialing from the Lync softclient, there is no off-hook dialing.  You enter the digits, then you press the call button, or ENTER or whatever. Entering a 9 is superfluous in those cases.  However, you do want to ensure a good experience when people do off-hook dialing from a Lync desk phone. How do you support on-hook and off-hook dialing without forcing EVERYONE to enter an external access prefix in Lync?  Use the External Access Prefix option in the Lync dial plan, as shown below.   

This option does several things, firstly it allows people to dial phone numbers in Lync the same way they're accustomed to on the PBX without having to adjust normalization rules.  It also makes Lync work the same way a PBX phone works when dialing off-hook.  The kicker is that you're not forced to enter a 9 when dialing. You either enter a 9 when dialing from the Lync softclient, or you don't. Either way, the call goes through as expected. Same thing for the Lync deskphone. You're not forced to enter a 9, but if you habitually dial off-hook, then you'll want to, or you'll stand a good chance of reaching an internal extension instead of the PSTN number you dialed. 

Rather than rehash what's been said before, have a read of one of my blog posts from waaay back in Lync 2010 days on this topic (don't worry, things haven't changed since then).  It shows how to set your Lync deployment up for extension dialing and external access prefixes the no-muss, no-fuss way. It also shows some examples on how the Lync softclient behaves when using an external access prefix.

You can use this in pure Lync Enterprise Voice deployments, or when integrated with an existing PBX.  In cases where you connect to a PBX, you still have to create a trunk translation rule to add the 9, if necessary. For more information on trunk translation rules, you can read my blog post on the subject, or refer to Technet

Tune in next week, where we talk about inter-trunk routing, and how people inadvertently set it up without meaning to.