Time2Market's Cloud Complete Unified Communications as a Service (UCaaS)

First off... this blog post is going to come across as a sales pitch and that is because it is. I'm not going to insult your intelligence... but there is a lot of confusion out there as to what is offered with various different Unified Communications as a Service (UCaaS) solutions and where they can fit into an organizations plan to further their communications. I'm not going to go into detail about all the other offerings out there, but what I'm going to do is offer you detail about Time2Market's Cloud Complete offering. We also offer a Cloud Custom option, that adds some additional functionality, but this blog post will focus on the Cloud Complete offering.

Anyone who knows me... knows that I'm not a fan of the "cloud". The reason is because I think it is one of those terms that gets thrown around and decisions made without really understanding the implications of turning over control to the cloud. I'm not saying that it doesn't make sense 100 percent of the time... because it actually does in a lot of scenarios.  I just don't like the blind run toward the cloud that I see a lot of people doing just because all the cool kids are doing it.

Having said that, Time2Market's Cloud Complete offering is a hosted UCaaS that is a Multi-tenant... Enterprise Voice... Skype for Business environment.

Yup.. you read that right... Skype for Business.

Time2Market's cloud is not based on the now defunct Lync Hosting Pack that was limited to the same feature set and Lync Online.

The is a Skype for Business hosted environment with feature sets that to my knowledge are currently not offered anywhere else. Those feature sets even include the new Broadcast Meeting offering that depends on a hybrid implementation with Office365. We even leverage Exchange Unified Messaging in Office365.

Now why would an organization want to do this. It is simple... instead of investing in all the equipment, server licenses and professional services to implement an on-premises solution that has costs as a capital expenditure. This allows an organization to move these costs to the operational expenditure column. The Cloud Complete offering scales and shrinks as you do and is a totally managed service from deployment to support. In short, you focus on your business, not running a Unified Communications infrastructure.

So what are some of the things that Time2Market offers in its Cloud Complete that make it unique...

• E-Faxing Services
• Advanced Call Routing Options
• DID Parking
• Common Area Phones
• Standalone Fax Services
• Unlimited Calling Plans
• Auto Attendant
• Dedicated Conference Bridge
• Room Systems and Video Integration
• Conference Room Audio Devices
• 800# Support
• Paging Applications
• Contact Center (Clarity)

But here is the really big key to Time2Market's offering, we have a whole organization that will help you every step along the way with a White Glove Service. Cloud Complete isn't a self service type of offering, instead it is an offering where you have a whole team of people who have been in the business of helping organizations communicate for decades. Here are some of the things we can help you with...

• Office365 Tenant Setup/Mail Migration
• Unified Messaging Setup
• IP Phone Setup
• On-Premises Active Directory Integration
• Auto Attendant Configuration
• Room System Installation
• Device Consultation

But wait.... there's more!! Sorry couldn't resist saying that.

But really there is more... Time2Market has created a Self Service web based portal that gives easy access to the following tasks...

• Password Reset
• Add New Users
• Assign DIDs
• Modify/Update Conferencing and Global Dialing Policies
• Update Federation Policies
• Get Support
• Access to Usage Reports and Billing Info
• Access to training, tips and tricks

What are you waiting for? Interested in Time2Market's Cloud Complete offering or have further questions? You can contact me by SIP or email using jonathan at t2mdev dot com or by calling 303 997 2100.

Change in route selection behavior in Lync Server 2013 from Lync Server 2010

I was recently working on a rather complicated dial plan and ran into a situation where the route I expected to be followed wasn't being followed. What I was trying to do was create a single Voice Usage that would route for specific numbers and then have a catch all route that would be the route as a last resort.

After doing numerous tests and doing an Outbound Routing debug it was clear that the route wasn't being skipped and it wasn't being marked down. The catch all route was being tried first even though the order of the routes in the Voice Usage had it at the bottom.

Interestingly, if I simplified the regular expression of the route that matched a range of specific numbers to just be one of those numbers, it magically started to work correctly. As soon as I modified it back to the larger range, it would fail.

Knowing that I have done this many times before, I was convinced somehow I hit some sort of bug. So a case with Microsoft was opened. After some lengthy testing, the Microsoft support engineer was just as baffled as I was and was coming to the same conclusion I did.

As a work around, until the Microsoft engineer decided how to proceed, we created two different Voice Usages. The first one was for ranges of numbers and the second usage contained the catch all route all by itself. The routing worked as expected, but this was not ideal, because this would increase the number of Voice Usages across the hundreds of sites in this deployment. I was aiming for the simplest dial plan possible since it was already complex.

Anyway, after a few days the Microsoft engineer got back to us and dropped a huge bomb.

Believe it or not, this was working as designed. He informed me that there was a change in Lync Server 2013 in how it processes routes in a Voice Usage. Lync Server 2013 now chooses the least complex regular expression before it processes the other routes. The reason for this change I don't agree with, but apparently there were some customers that had really large dial plans, where processing a large list of routes in a Voice Usage was taking too long and this change was decided to speed up processing the list.

So... if you have similarly complex in the same usage, the order of the routes matters. But if you mix complex and simple rules in the same Voice Usage, then the more simple rules will always be followed first.

I hate this because now everyone else is forced to create more Voice Usages, sometimes with a single route in them, to have the routing work as desired. The other item that bugs me is that there is next to no documentation of this change and this was not communicated to the technical community in any other way that I'm aware of. This is a big change for a product that a lot of people depend on to be consistent.

I think a better alternative would have been to give the engineer an option to process the routes within a Voice Usage using the Lync Server 2010 method or to switch to the new Lync Server 2013 method. I can see merits to both methods, but ideally I would like a choice.

Now... If you are like I am, you want to know what exactly constitutes a simple rule vs complex rule. Unfortunately I can't tell you exactly. All I can share with you is a somewhat vague answer that I got back.

The algorithm has quite a bit of complexity – in simple terms, the route that has simpler “prefix” will be preferred over more complex ones. The “prefix” is a combination of characters, character escapes, alterations and substitutions (as defined in regular expressions).

So if anyone has more detail on this algorithm, I'd like to have it. But in the mean time it doesn't really matter because the permanent fix is to have similarly complex rules in the same Voice Usage and then make sure you test to verify the route order is being followed as desired.

Lync/Skype for Business Loud Ringer

Loud Ringers for Lync/Skype for Business is one of those problems you think can't be solved. But I stumbled upon a technique awhile ago that can be used to solve this problem. This technique though, uses pieces of the product in ways they were not originally intended. But I will say that I have been doing this since Lync Server 2010 and I hope with writing this blog that more people will use this technique and maybe it will get a better method for implementation by the product group.

So enough dancing around the topic.

In order to execute this technique we need the following:

• Analog based Loud Ringer (Algo 1825 for example)
• Gateway with Analog FXS ports
• Create a Lync/Skype for Business Analog Device
• Device that can do Pin Authentication for a Common Area Phone
• Lync/Skype for Business user that has SimRing capability

Step 1

First step is to setup the FXS port and Gateway so that a dedicated number can ring that port. I prefer to use non-DID numbers for this application, but it just has to be a unique number in the Lync Dial Plan. Later we actually use this number when defining the Lync/Skype for Business analog device LineURI. Because there are so many Gateways with FXS out there, I'm not going to get into specifics in this area. But I generally route the extension portion of the number to the port. For example if +13005551000;ext=9572 is the intended LineURI, only the 9572 portion would be configured for routing to the port on the Gateway. 

Not getting the hint? 

I manipulate the number either in the trunk configuration of Lync/Skype for Business (my preference) or the gateway to just be the extension.

Oh you you are one of those people who don't like to use ;ext= ? Then you'll have to figure out the Pin Auth on your own later.

Step 2

Next we add the Gateway with the FXS port to the Lync/Skype for Business Topology. Nothing special here, but make sure it is communicating on the correct port/protocol.
Once the Topology has been published and replication has occurred, you will need to create an analog device in Lync/Skype for Business. 

Here is an example of the command: 

New-CsAnalogDevice -LineURI "tel:+13005551000;ext=9572" -DisplayName "Someone's Loud Ringer" -RegistrarPool <same pool as Loud Ringer user> -AnalogFax $False -Gateway <IP or FQDN of Gateway just added> -OU <your favorite OU>

Here is the technet for reference.

Pssst don't forget to do an Address Book Update... you'll need it soon and might as well have it working while we do this other stuff

Update-CsAddressBook on the pool that has the user with the need for the Loud Ringer.

Step 3

Once AD Replication happens we need to set a client pin for this analog device. Say wha?! Yes... just stick with me here... 

Here is an example of the command:

Set-CsClientPin -Identity "Someone's Loud Ringer" -Pin <any pin you choose>

Here is the technet for reference

Step 4

Login to the Analog Device like a Common Area Phone using Pin Authentication. For example the extension is 9572 and the pin is well... whatever you set it to. It doesn't matter if this device stays logged in or not, we just needed to log it in once as a Common Area Phone.

This would be a great time to call the Analog Device from lync and make sure the Loud Ringer is actually working. That way we aren't troubleshooting the physical install too... later on.

Step 5

Set the SimRing for the user that needs the Loud Ringer. This can be going to their PC or getting their username and password, or using SEFAUTIL. The bottom line is you want to set the SimRing for the Analog Device above which should. 

If you don't see it as a contact you can add, you might have forgot to update the address book on the server, or maybe you need to log out and back in to force an update.

Step 6

Call the user who needed the Loud Ringer and hear their praises and celebrate that you solved that problem for them that has been hanging around for a year or two. Or if it doesn't work... dig out your Lync Debugging Tools and Wireshark. I know you'll figure it out.

AudioCodes Configuration Logic

I've been working with AudioCodes products since the early 2000s. My first encounter was a couple of Mediant 2000s with 16 PRIs each. The configuration of those boxes for the most part was handled by following a document provided by Nortel. The funny thing is that most of the documentation over the years that has really helped has been solution specific guides done by a product manufacturer so that Audiocodes can work with their product.

The problem with Audiocodes is that its capabilities are so diverse and flexible that writing a single document that actually helps you through your specific configuration is nearly impossible. Years ago, you could actually download ready made configurations depending on what your PRI connection it was and you would be 99% there. Fast forward to today and configurations aren't that simple anymore.

The number one complaint I hear about Audiocodes is that it is so hard to configure and other products are ready to go in minutes. While I can't create any fancy wizards for Audiocodes configs, I can try to help people understand key parts of the AudioCodes configuration process so that the product is not as frustrating.

Global vs Profiles

One of the big concepts to get with Audiocodes is that there are many parameters that can be set at a Global Level and then overridden by a profile that applies to that feature. Profiles are useful for changing the behavior of communications to a particular system. For instance, if one system supports Early Media, but another does not, with Profiles you can adjust the signalling for each system. This applies not only to the IP side of the gateway, but  also the TDM side if applicable.

Another key concept with profiles is where you can have them applied. Some profiles, like IP Profile can be chosen in several different areas, which I think adds to the confusion on configuration sometimes. For example if I am using an IP Group, I can specify not only a Proxy Set, but also an associated IP Profile. If I'm not using IP Group but instead specifying a single target IP in the routing area, again I can specify an IP Profile on the route itself.

As a best practice, I always use profiles to control the various different features for each system, even if they need similar settings, they each get their own profiles so I can adjust individual settings in the future.

Before I go any further I need to mention a couple of basics. First of all, when looking at the menu's I always recommend changing to the the Advanced or Full view depending on the system you are looking at.

Also, whenever you hit "Submit" the change takes effect immediately unless the system tells you it needs a reset. However, if the system has a power loss and you have not hit "Burn" then the changes are not saved permanently to the configuration. It is a good habit to burn frequently. It only takes once of having to redo your configuration to learn the lesson.

I also highly recommend doing backups of the configuration. Which can be done manually or you can use my PowerShell script to do the backup



IP Groups

IP Groups are awesome because they pull together several different key pieces to communicating with other SIP systems. I use IP Groups primarily because I can specify a Proxy Set which allows for me to specify multiple IP addresses or DNS names for the system to send SIP signalling to, but I can also specify an IP Profile to be used too. This is key if you have multiple servers you need to communicate with that act as a pool or cluster.

Below you can see where we specify a proxy set (identified by a number) and the IP Profile as well. One thing to keep in mind is that you have to specify a SIP Group Name which ends up being the portion after the "@" in a SIP URI. The AudioCodes gateway/SBC doesn't really care what you put in here, but the far end system might. In the example I used the IP address configured on the AudioCodes network interface that communicates with that system. The network interface used is controlled by the SRD and Media Realm specified. If you have a system that uses a single IP, SRD and Media Realms is not used.

In the example below this is an SBC Enabled Mediant, so the SBC settings are exposed in the IP Group. Below are the defaults, which are fine most of the time, but if you needed to do some message manipulations for this IP Group this is where it would be specified.

IP Profiles

 As mentioned before, IP Profiles control much of the SIP signalling and allow for adjustment per system we are communicating with.

I think many of the parameters are self explanatory, and if not the documentation can help understand what each of these parameters do. Most of the really good stuff in the example I've provided is in the SBC section below. If you have a TDM based gateway there options are different but many are similar.

The SBC area of the IP Profile is really one of the key aspects of SIP Signalling and truly is what makes an SBC a Back to Back User Agent and allows for the adjustment of signalling between disparate systems. As an example, one of the latest items I've had to adjust was the hold format to Intelepeer SIP Trunk that did not like the hold format Lync used. 

Because this was an SBC Application enabled configuration, I could accept the hold format from Lync and send a different hold format to Intelepeer. Another piece that can be useful is controlling the REFER behavior, which sometimes has to be set to Handle Locally to keep disparate systems happy that don't understand REFER.

Coder Group

Coder Groups are pretty basic allowing you to specify a codec list and features (such as silence suppression) to be used when specified in an IP Profile above. If you have ever heard of transcoding between different codecs, this is where that magic happens for AudioCodes. You can specify G.711 for one IP Group and IP Profile and then specify G.729 in a different IP Group and IP Profile combination.

Tel Profile

This is taken from a TDM based system and not the same as the examples above from an SBC. I wanted to talk a bit about Tel Profiles because I've found having a different one for each one of your TDM lines is crucial. Tel Profile for each TDM trunk is specified in the Hunt Group area when you define what your different ports are doing.

Why?

Couple of features... Echo and Analog DID.

Controlling the volume is key for solving echo issues. Other than misconfigured microphones, the number one cause of echo issues is volume being too loud. Being able to control volume from PSTN (Input Gain) and to the PSTN (Voice Volume) for those lines that are too loud is the key feature that helps address the issue. Why is this? Because when the volume is too loud the reflected audio back from the far end isn't detected by the echo canceler and allowed to pass through as normal audio. If you wanted to see this for yourself, increase the volume to the PSTN to the point where it causes echo.

Also, if you have the unfortunate luck to encounter a site with Analog DID then Polarity Reversal and Enable DID Wink are key features in the Tel Profile you will need to enable on a per port basis.

VoIP Routing

One of the more confusing aspects of the AudioCodes configuration is VoIP routing (non SBC Application). The key is to make note of where the communications is coming from. This determines which of two routing tables you will hit. If the call is starting from the TDM/PSTN world, then you will hit the Tel to IP routing table. If you are starting from another SIP system or SIP Trunk then you will hit the IP to Tel routing table.

Sometimes, it is necessary to route from PSTN to an Analog port and in order to accomplish this you have to route the call to the gateway itself. The first line below is an example of that. Once you do this you will now hit the IP to Tel routing table which allows to routing to a Hunt Group (which in turn was assigned an Analog port).

Conversely, if you start in from another SIP system and you need to route to another SIP system through the Audiocodes, the call would hit the IP to Tel routing table first. The key to routing to the Tel to IP routing table going this direction is sending it to Hunt Group "-1". This technique may be necessary if you need to route analogs from MediaPack to MediaPack and want to keep it entirely in the AudioCodes world.

One other thing that almost always comes up is manipulation of numbers either Destination (Called) or Source (Calling). In the screenshots above the setting is to Route before Manipulation. This is my preferred method, but it is important before you start manipulating to understand if the manipulation will occur before or after routing. This will determine which numbers you put in your routing tables.

Now that I've mentioned this, I try very very hard not to do any manipulations in the gateway/SBC. I prefer to do all this in Lync. Sometimes there is no way around it, especially if you need to deal with manipulations when doing Fax or other analog solutions.

Dialing Plan Notations for Prefixes and Suffixes 

AudioCodes is not nearly as flexible as RegEx when it comes to number matching, but it isn't terrible if you know what you are doing. Below is from the AudioCodes documentation.

The dialing plan notation applies to the Number Manipulation tables, 'Tel to IP Routing' table and 'IP to Trunk Group Routing'. The dialing notation applies to digits entered for the destination and source prefixes to represent multiple numbers.

[n-m] Represents a range of numbers. Note: Range of letters is not supported. 
Example [5551200-5551300]#: represents all numbers from 5551200 to 5551300. 􀂃123[100-200]#: represents all numbers from 123100 to 123200.

[n,m,...] Represents multiple numbers. Up to three digits can be used to denote each number.
[2,3,4,5,6]#: represents a one-digit number that starts with 2, 3, 4, 5, or 6. 􀂃 [11,22,33]xxx#: represents a five-digit number that starts 11, 22, or 33.
[111,222]xxx#: represents a six-digit number that starts 111 or 222.

x Represents any single digit. 54324: represents any number that starts with 54324.

Pound sign (#) at the end of a number Represents the end of a number. 54324xx#: represents a 7-digit number that starts with 54324.

A single asterisk (*) Represents any number. *: represents any number (i.e., all numbers).

Conclusion

Give me some feedback on whether this hit the mark or not. I have a lot of information about AudioCodes up in my head and like the people that write the documentation, it is difficult to get it into a usable format for a wide audience.

So... you want to be a Lync Architect

For at least a couple years now my employer has been on a constant search for talent to deploy Microsoft Lync and the components that are part of that ecosystem. But it is getting harder to find guys that will fit in with the company culture and have a good set of fundamental skills (or phenomenal skills if we get lucky).

So I thought I'd write a post, from my perspective, about what some of the skills are that it takes to work as a consultant in this Microsoft Unified Communications world. Engineers and Architects that can do this type of work WELL are a rare find. They posses knowledge from multiple disciplines (data, voice, server apps, security etc) and combine them all to help a customer deploy a solution that fits their needs. My hope is that this will finally convince some people that are on the fence to jump in (and increase the pool of talent).

... and no you don't have to be an Architect to jump in, you can start out being an Engineer or working the support desk. You can learn as you go.


The Hard Skills

Here is the bottom line... the more of these the better.

The more of these you are excellent at... the better consultant or support engineer you'll be for your customer.

Nobody... Nobody will be an expert at all of these. But sometimes the secret is knowing others that are experts in that area... or knowing where/how to find the answers.

If you are weak in most these areas... no problem... go buy a computer, create a lab of your own and pick something and start to learn. With Microsoft based software there is usually no lack of freely available knowledge you can learn from and there are certainly plenty of books out there on all of these topics. Don't expect you will learn all of this in two weeks. I've been gathering knowledge for as far back as 20+ years and that knowledge still applies to what I do today. But everyone has to start somewhere.

Here is the list that I've come up with...

• Active Directory
• SQL Server
• Windows XP/Vista/7/8/8.1 etc
• Server 2008 R1/R2 and 2012 R1/R2
• Office Communications Server 2007 R1/R2
• Lync Server 2010/2013
• Exchange 2007/2010/2013
• System Center 2007/2012/2012 R2 via @fabriziovlp
• Hyper Visors (Microsoft, VMWare etc) via @fabriziovlp
• Virtual Desktop Infrastructure (Microsoft, VMWare, Citrix etc)
• PowerShell
• .Net Regular Expressions (RegEx)
• Private Key Infrastructure/Certificates
• Layer 2 Networking (Switched)
• Layer 3 Networking (Routed)
• IPv4
• IPv6
• TCP/IP
• Quality of Service
• Firewalls
• Network Sniffer (Wireshark, Message Analyzer)
• SIP
• Audio Codecs (G.711 etc)
• HTTP/HTTPS
• ISDN PRI and the associated protocols/capabilities
• T-1 (Telephony based digital circuit)
• DS-1/DS-3 (Data based digital circuit)
• Frame Relay
• Avaya Blue (Nortel)
• Avaya Red (Traditional Avaya)
• Cisco Unified Call Manager
• Mitel
• Inter-tel (owned by Mitel now)
• Shoretel
• PBX Dial Plans
• PBX Features
• Analog device types
• Fax and Fax Server
• T.38 Codec (for Fax over IP)
• Modem (Yes credit card and postage machines still use this)
• Gateway/SBC (Sonus, Audiocodes, etc)

The Soft Skills

• Good listening skills
• Good presentation skills
• Good communications skills (verbal and written)
• Patience
• Attitude toward constant learning
• Self starter
• Working alone
• Working in teams
• Working with other teams
• Juggling lots of tasks/jobs at once
• Prioritizing tasks
• Bing/Google searching for information
• Networking (the people kind)

Getting There...

This one is all on you. My unique path took me from being a network manager/admin at a University, to working 11 years for Nortel and then combining all that experience into what I do now. Some of this is hard to learn in a lab unless you are loaded with money. 

You need to surround yourself with people that know about the skills you need to work on. This is where the networking (the people kind) really comes in handy.

How do you do this?

• Go to local users groups
• Go to local conferences. 
• Go to some industry conferences. 
• Get on twitter and follow people that tweet about the things you want to learn about. 
• Get on LinkedIn and make some connections and join some discussion groups. 
• Read the Technet forums
• Read some books

I'll keep updating this as I think of things... but bottom line is that this stuff isn't easy, but it is something that is able to be learned given enough time and effort.

Lync as a PBX Replacement Series - Analogs

Others in the series...

PBX Network Topology
http://blog.ucomsgeek.com/2014/02/pbx-replacement-series-pbx-network.html

PBX Dial Plan
http://blog.ucomsgeek.com/2014/02/pbx-replacement-series-pbx-dial-plan.html

Toll Fraud
http://blog.ucomsgeek.com/2014/02/pbx-replacement-series-toll-fraud.html

Overview
When you replace a PBX with Lync Server 2013 no doubt you will have to deal with Analogs. There are several types of Analogs you should be on the look out for when you are gathering documentation on the PBX environment.

• Analog extensions
• Fax machines
• Fax servers
• Modems
• Credit Card machines
• Postage machines
• Door phones
• Gate phones
• Cordless phones
• Paging systems

I'll talk about each of these and how to handle each of them effectively.

Analogs
Analog extensions/Cordless phones
These are probably the easiest of all the analogs to handle. Analog Extensions and Cordless phones are just straight voice extensions that use an analog port on a FXS gateway. Although you can handle Analog extensions completely outside of Lync Server 2013, I recommend that you use the Lync Server Analog Device feature.

Using the Analog Device feature serves two purposes. The first, is to a Lync user it appears as any other Lync user/device/common area phone. When created, it has a contact created in Active Directory and is assigned a Tel URI. This also will allow calls from the Analog device to appear in Monitoring Server reports. The second purpose is to be able to control with Voice Policies what numbers the Analog Extension can dial. This is important in situations where an analog phone is required, like an intrinsically safe enclosure for hostile environments, but still needs to have controls as to what numbers can be dialed.

At some point I plan to do a detailed blog on setting up Lync Server Analog Devices and all the pieces that need to be put in place for it to work as designed.

Fax machines
Fax machines are a bit more of a problem. On the surface the Analog Device feature of Lync gives us the impression we can handle faxes in a similar manner to Analog extensions. There is some limitations to handling Faxes through Lync that ultimately, in my opinion, makes it a non starter.

First of all, when you create an Analog device with the Fax attribute enabled to true, all this does is immediately send the call directly back to the Gateway the Fax call originated from. There is no way to send this call to any other Gateway.

When the Gateway receives the call from Lync Server it follows the routing tables that in turn directs it to the appropriate port. If you have a lot of fax machines for a location, you are limited to the number of Fax ports the Gateway connected to the PSTN can support.

Next issue, in order to send the call through Lync, the codec for the originating call to the Lync Server can not use T.38 or any other Fax specific protocol. The Gateway can only be configured to use G.711 only. If any other codec is sent to the Mediation Server the call will fail.

In theory G.711 protocol should be okay for Fax transmission, but in my experience it is flaky and customers tend to complain when things don't work consistently.

My recommendation is to handle Fax machines outside of Lync Server. Allow the Gateway to route the call to the appropriate port whether that is on the originating Gateway or a different Gateway elsewhere. This will allow the use of T.38 or any other Fax specific protocol and give a more consistent experience.

Fax servers
Fax servers can only be handled through Gateway routing outside of Lync Server. These servers typically only support T.38 and there is no way for the Fax implementation in Lync to send these calls to a Fax server using the Analog Device feature.

I would not under any circumstance route these through Lync to Exchange UM and then over to the Fax server. Even if you did get it to work, I doubt it would work consistently because T.38 is cut out of the picture.

Modems/Credit Card machines/Postage machines
There is no way to handle Modems and Modem like devices within Lync Server. Because of this you will need to use the Gateway routing feature the send these calls to the appropriate Analog port on an FXS Gateway. Depending on the Gateway manufacturer there may be specific codecs that are more appropriate for modems. If this is the case the modem negotiation will be detected once the call is answered and the codec will be renegotiated.

Door phones/Gate phones
These can be setup like an Analog Extension within Lync Server, but they will never receive a call. They only make a call, usually to a specific number. This specific number can be a Response Group or to a receptionist. What makes these devices unique is that they listen for certain DTMF tones to activate a relay to remotely open a door or gate. Sometimes a door phone might be PBX specific and will need to be replaced with an analog equivalent (that might require a professional installation).

Paging Systems
Lync Server does not provide any native ability to do paging. There have been third party developed solutions for this, but as far as the theme of this blog post goes I'm going to stick to talking about overhead paging systems. The first thing to determine is what type of paging interface the PBX has. If it is an analog interface then your job will be easy. If it is some sort of relay (dry loop for instance) then you will need to acquire a paging adapter such as a Valcom V-200X series. An adapter like a Valcom will accept an analog connection and interface to the paging equipment.

Once you have a Valcom like adapter, or a paging system that accepts an analog connection, you can again setup a Lync Analog device to direct calls to the appropriate Gateway and then using the Gateway routing tables deliver the call to the appropriate port.

One of the techniques I use with Paging systems in Lync is to normalize a dialing shortcut to reach the paging system. If the PBX accessed the paging system by dialing a feature code like 200 then I might do a normalization rule of *200 and normalize to the TEL URI of the Analog Device I created. Unfortunately not all PBXs work like this and sometimes you just have to ask the customer what they want to dial to reach the paging system.

Lync as a PBX Replacement Series - Toll Fraud

Others in the series...

PBX Network Topology
http://blog.ucomsgeek.com/2014/02/pbx-replacement-series-pbx-network.html

PBX Dial Plan
http://blog.ucomsgeek.com/2014/02/pbx-replacement-series-pbx-dial-plan.html

Analogs
http://blog.ucomsgeek.com/2014/02/pbx-replacement-series-analogs.html

Overview
Since I have started working on Microsoft based Unified Communications, I hardly ever hear any talk about Toll Fraud. Granted, things have changed as far as telecommunications costs, but there are still other problems that can crop up with regard to Toll Fraud.

When we are considering replacing a PBX, the Toll Fraud prevention the PBX has in place will be gone. Lync should be configured to prevent users from using the system inappropriately. It is important to note that some of the ways I'll point out that Toll Fraud can be committed are not necessarily considered Toll Fraud by every business so it is best to really have a heart to heart with your customer about the subject.

Toll Fraud
900, 976, and 809
Most people in the United States are aware of 900 and 976 Premium numbers that can rack up costs for the caller (mostly sex talk lines). But not a lot of people are aware of 809 scams. The numbers look like Canadian or US telephone numbers, but turn out to be costly, overpriced international calls which bypass consumer protection laws. Some advertise phone sex or other typically premium content. Other ways these scams work, is by leaving an unsolicited messages on voice mail or making bogus claims of being a relative in a family emergency to trick users into calling the international numbers, then attempting to keep the victim on the line as long as possible in order to incur the cost of an expensive international call. Ask yourself this... if you were to get an 809 number on your phone would you call it back? Most people do... and this is how they scam people.

Call Forwarding
This is when a phone within a business is set to call forward to a Long Distance or International number. These days Long Distance is so cheap that you don't hear about this much anymore, but call forwarding to an International number can still be costly. Once a phone is forwarded a person can call that phone and voila they have made a call on someone else's dime. It doesn't even need to be a phone with a DID if you have an Auto Attendant they can use to transfer to that Non-DID phone.

Personal Calls
Most businesses don't care if you make a personal call while at work. However, I'm willing to bet they might care if you made a personal International call on their dime. I really don't have anyone Internationally I want to call on a regular basis, but I have friends that have family and friends overseas. In general, a business will restrict the types of calls a user can make based on their job function and then do periodic audits of phone bills to see if anything sticks out.

411 Calls
Calls to 411 are used for directory assistance. This is one of those grey areas, that some businesses allow their users to dial. The reason why some businesses restrict this is because there is a per call charge of $1.25 for this service. Sometimes this slips through because phone systems need to allow for 911 and other municipal services on 311. Good to investigate what the current phone system allows and then have a conversation with your customer.


Why do we care about Toll Fraud?
As installers of communications systems, we should take great care in making sure the system is functioning properly. That means also making sure the system prevents users from using it ways that are not appropriate.

.Net Regular Expressions
With regard to Lync Server we have a lot of tools to prevent and monitor Toll Fraud.

To start with across the board blocking of numbers can be done at the routing level within Lync Server. For instance the following .Net Regular Expression blocks 900, 976, and 809 numbers, but allows all other area codes to pass whether they are valid or not. If you need to add other numbers it should be self explanatory on how to do that. If you need help with Regular Expressions you can read my blog post.

^\+1(?!(900|976|809))

Call Forwarding and Simultaneous Ring Restrictions
As far as Call Forwarding goes Lync Server 2013 provides a separate ability to restrict Call Forwarding and Simultaneous Ring vs the users ability to dial the PSTN directly. By default it is set to use the users assigned PSTN Usages, but you have the option to restrict to Lync users/endpoints only or Route using custom PSTN Usages. This would be an excellent opportunity to have a conversation with your customer on how they want this setup because this may add more Voice Policies to your deployment if they want users to be able to dial Long Distance but have separate policies restricting the call forwarding and simultaneous ring for different groups of users. Here is what the area in Voice Policies looks like...

Authorization Codes
Some companies use authorization codes to prevent fraud of someone walking up to a phone and dialing a Long Distance or International number. You might run in to a PBX that has Authorization codes, and even though there are third party developed solutions on Lync to handle this, there is nothing built in to the Lync product with this functionality. Many businesses choose to have a carrier handle Authorization codes for them and then in turn creates a report every month of who made what calls and for how long.

I'd also like to point out that some PBX Authorization codes implemented require the user to dial an authorization code before the phone number. You might have caught this while you were collecting data for the PBX Dial Plan, and have been scratching your head how to get Lync to handle this. I haven't seen a way to handle this across SIP. Your customer will need to remove these restrictions from calls coming from Lync and allow the Lync system to control what a user dials with Voice Policies, PSTN Usages, and Routes.

Voice Policies, PSTN Usages, Routes, and Trunk Configurations...
Now you might be asking what are PSTN Usages at this point. If so that probably means that calls are flowing to the PBX wide open with no restrictions (which is fairly common). I plan to do a whole PBX Replacement Series write up on Class of Service or Call Restrictions, but I'll try to boil down the basics in this post.

Going to Masters was the single hardest thing I've ever done. I wouldn't have missed a single moment of it. Everyone there was top notch and I made some great friends. Everyone came with their specialties and mine happened to be voice. Some of the class struggled in this area, which isn't good because there is one week of information on just the Enterprise Voice part of Lync Server. Doug Lawty was the instructor for most of this week and if you ever get a chance to sit in one of his sessions at Lync Conference you should.

Anyway... my point is that doing Enterprise Voice right, in Lync Server, is not trivial. Understanding Voice Policies, PSTN Usages, Routes, Trunk Configurations and how they all interact with each other can be daunting, especially if you haven't seen an example before. So... with that... the best way I can show you how this stuff works together is by showing you visually.

Got it memorized? The way to read this is to start on the far left and work your way right. The far left is User Voice Policies. That is right... USER. I never use Voice Policies assigned at the Lync Site level. Why you ask? Because you will always run in to that situation where you need to be more granular per office, per floor or even per department and you might as well start out that way.

Anyway pick a green box like DEN-LongDistance, notice the pretty yellow/orange lines that move to the right. Those are leading you to PSTN Usages. PSTN Usages are how you control which routes that Voice Policy has access to. Each PSTN Usage can have Multiple routes assigned to it. Multiple routes can be assigned to Multiple PSTN Usages. Oh, and PSTN Usages can be assigned to multiple routes (evidence of all the pretty colors). So this is why people get really confused and why the picture is important. Don't think the above example is the only way to do this... it is just how I prefer to do it.

If a User Voice Policies doesn't have a usage assigned that allows access to a route assigned, there is no way for the user to get to that route. Are you starting to see how we can restrict what a user is able to dial?

When I build all this out I actually start with my routes. Then I create a User Voice Policy and Create the PSTN Usages within that Voice Policy as I go. Start with the most restrictive Voice Policy because once you build a PSTN Usage you can use it later for other Voice Policies (i.e. DEN-911-Usage).

Like I said I'm going to do a whole blog post dedicated to this area, so don't want to give away all the fun just yet. Hopefully the above visual will help you until then.

I didn't intend to have this post the end all for all types of Toll Fraud. What my real goal was in this blog post was to get you thinking about Toll Fraud in a Lync Server environment. If you have any questions feel free to add a comment I'll do my best to answer.

Lync as a PBX Replacement Series - PBX Dial Plan

Others in the series...

PBX Network Topology
http://blog.ucomsgeek.com/2014/02/pbx-replacement-series-pbx-network.html

Analogs
http://blog.ucomsgeek.com/2014/02/pbx-replacement-series-analogs.html

Toll Fraud
http://blog.ucomsgeek.com/2014/02/pbx-replacement-series-toll-fraud.html

Overview
In my next installment, I would like to dive in to PBX Dial Plans. Chances are there is very little PBX documentation or you might also hear my favorite...  "The PBX is the documentation".

There is also an even smaller chance that if there is PBX documentation, it won't be the dial plan. Why? Because it is a pain to really track and do a dial plan well. If you have a seasoned PBX Administrator on staff give them a big hug and buy them a nice steak dinner right now, because they are your single biggest asset to understanding how things are laid out.

On a side note... many PBX Administrators are really scared of Lync right now. They think because Microsoft is replacing their PBX, they will get replaced too by the "server administrators". That is the farthest thing from the truth. Sure the server administrators will probably take a greater role in managing the communications environment, but they won't get "Voice" like a seasoned PBX Administrator. Most of the knowledge these professionals have can't be learned easily anymore. They also have years and possibly decades of experience of how not to do things that might be specific to the business environment you are working in. What you should encourage them to do is embrace learning a new skill set that will make them even more valuable because not only do they have critical knowledge about telecommunications, but they will also learn new Server and Applications skills (which is easier for them to do than for a server administrator to learn telecommunications). Those two together are really powerful, throw in some data communications and QoS and you get what I call a true Converged Engineer.

Meanwhile... back at the ranch, let's dig in to PBX Dial Plans...


PBX Dial Plan
First off, I want to go in to the two different types of PBX dial plans. They are Coordinated and Uniform (Nortel speak). Haven't heard those terms before? Doesn't surprise me. I never heard those terms until I started at Nortel even though I was a network manager at a university and had voice for the university under my domain. There is also a good chance that depending on the PBX vendor the terms might be defined differently or have different names (which can be confusing... I know). No worries, I plan to describe them in detail so hopefully we will all get on the same page regardless of what each of us calls them.

Coordinated
In a coordinated dial plan each extension in the PBX network is unique and all the same number of digits. Each person can dial each other directly using just the digits of the extension regardless of where they are.

Typically you will see ranges of numbers dedicated to a site. For instance, all the Denver numbers start with 45XX and all the Dallas numbers start with 46XX. The range is totally arbitrary and can really be any range.

A well managed Coordinated dial plan will usually break ranges in to 10s, 100s, 1000s... 10000s you get the idea. An example of a badly managed dial plan would have Denver range be 4523 through 4547 and the Dallas range be 4548 through 4581. Although it is certainly valid, these are harder to handle in routing tables in the PBX (and harder in Lync too).

If you are in the rare situation where you are developing your own dial plan, you will want to pick ranges that allow for future growth. There isn't any hard set rule on what you should do. So most people go with their gut... or base it on some knowledge they have about the business and how much they grow.

DIDs in a coordinated dial plan usually start out by matching the last few digits of the DID number. For example 3035554500 would correspond to an extension 4500. When you have 4 or 5 digits for an extension, you will find that assigning all 4 or 5 digits to an extension can chew through a dial plan number availability quickly. One way PBX Administrators handle this potential overlap is even though your carrier may send you 4500 the users DID (3035554500) they map to an extension that is really 3500. These nuances are really important to understand and have documented. When you start to write normalization rules, knowing details like this up front will save you a lot of effort. Also, keep a watchful eye for situations where the DID does not line up with an extension in some sort of pattern. You'll need to write one off normalization rules to handle these properly and you should also see if the customer can clean these up in any way (might be a multi year process).

As you might have surmised above... the biggest challenge with Coordinated Dial Plans is that they run out of digits once you go past a few sites. Depending on the number of users, you might start to feel pain around the 10 site mark. If you start to run out of room there isn't really any easy way out. You will feel pain. My suggestion these days is to move to an E.164 dial plan (along the lines of Uniform below) where users calling another site have to dial 10 digits. Within a site can still be their short extension. If you move to an E.164 dial plan there is no chance or conflict (this goes for International dial plans as well)

Uniform
In a Uniform dial plan, each site has access to the entire range of numbers, but when dialing another site, it requires a site code or prefix to identify where you are calling. In the example of Denver calling Dallas you might have a site code of 20 in front of the extension so the user would dial 204623 to reach a user and vice versa Dallas calling Denver would dial 214512 as an example. A Denver user calling another Denver user would just call the 4 digits, but certainly could call the site code too if they wanted.

Now usually with this type of dial plan you also have an Access code associated with internal site to site dialing. Think of it as like dialing a 9 before a PSTN number. At Nortel, we used to use a 6. So in the example above the Dallas user would dial a 6+21+4512 to reach the user in Denver.

Site codes don't have to be just 1 or two digits. Typically for really large PBX networks you might see more. Nortel used a 3 digit site code with 4 digit extensions. They were a truly global company with over 100,000 people at one point just to give you some perspective.


Why do we care about PBX Dial Plans?
Simple... we want to replicate the voice dialing user experience in Lync.

Normalization Rules
One primary way your users will complain is if they have to learn a new way to dial Bob in Accounting. To keep this from happening, an understanding of how the users dial numbers today is needed, so you can replicate that with Normalization rules in Lync. Need help with Normalization rules? See one of my first blog posts for some help.

So I'm going to assume you have great documentation at this point. If not, you better get cracking and better hope this deployment isn't due to be done this week. If you are having to create documentation chances are you won't get everything. In this case you need to consider using a generic normalization rules that will catch all the extensions you don't know about. To do this normalize using the HQ main office number +13035551000;ext=XXXX. When you configure your Trunk Configuration to strip out what you don't need, you'll just grab the extension and pass to the PBX and the call will complete.

As you are going through your documentation look for things that aren't consistent. If it doesn't look right, or stands out... ask questions. Usually there is something more sinister going on. Worst case scenario would be a dial plan that has different number of digits depending on what site they call. If you run in to one of these... stop the presses (hopefully SOW isn't signed yet) and tell the customer that they need to make everything consistent across the board. Proceeding will only mean pain for everyone. If you proceed, you will be in an endless loop of workarounds that at some point will become unmanageable.

When you are putting together normalization rules, you should at least be looking for information to complete the following:

• 911 with and without Access Code
• Special formatted numbers (Paging, Hunt Groups, Emergency Notification etc)
• Dial Receptionist for each site (Company Operator)
• Extension (for example 4-Digit)
• 10-Digit for Internal DIDs
• PSTN Local 7-Digit with and without Access Code (if needed)
• PSTN Long Distance with and without Access Code
• PSTN International with and without Access Code

Also, when you start out developing your dial plan in Lync, ask yourself at least one critical question. Will I need to handle Non-DID extensions? Those are the extensions that a user can call internally that have no dedicated PSTN number. They can only be reached from an internal phone, or by transferring from an internal phone. For Non-DID dial plans you have no choice but to use the +1XXXXXXXXXX;ext=XXXX format when assigning numbers to users or endpoints. I would use the format anyway for other reasons like Pin auth and Dial in conferencing authentication, but regardless Non-DID REQUIRES you use this format.

Since I am a fan of +1XXXXXXXXXX;ext=XXXX, even in environments that all have DIDs, you should always write User Dial Plan rules for extension dialing to normalize to this format, but also 10-Digit versions of Internal DIDs that specifically normalize to the +1XXXXXXXXXX;ext=XXXX format. I know... I know... Microsoft will match the first part... but I've been working with this stuff long enough that I don't trust that to work 100% of the time. I follow this rule religiously, and it creates a lot of extra work, but my deployments have a great track record. Also, don't forget to make sure you Normalize the Lync Address Book in the same way.

Now, if you have a Uniform dial plan you will want to include the site code after the ;ext= when you assign numbers to endpoints or normalize (+1XXXXXXXXXX;ext=21XXXX). Why? mainly to make Caller ID to the PBX easier. Wasn't what you expected was it? I am a fan of doing all Number manipulation on Lync. This includes having separate Trunks in Lync for PBX routes so I can strip down the Caller ID to match the user experience on the PBX. Don't do this and you'll be writing a ton of rules in the Trunk Configuration. Don't do it Trunk Configuration? Then when the user goes to dial the person back the call won't complete because they won't know the site code. Get it? Got it? Good!

Routing
More than likely you will have more than one place you are connecting to the PBX network through. Because of this you will want to know what numbers in the dial plan go where. If the PBX Network is Hub and Spoke there are finite resources available and not sending the calls to the closest PBX to its destination could cause congestion.

This is also important if you are doing any routing for analog devices that are connected to the Gateway.

Unassigned Number Handling
At first when you are doing co-existence you will not want to have Unassigned Numbers in Lync. But as you eliminate each PBX you will want to add Unassigned Numbers to Lync. This will prevent routing loops in your PRI Gateway's and SBCs. Unfortunately you can't do ranges of DIDs with the ;ext= format. You can only do straight E.164 numbers or numbers with ;ext= and the first part of the number being the same +13035551000;ext=1000 through +13035551000;ext=2000. No Bueno.

This will mean that your call will route out to the PSTN and back in before it gets unassigned number handling. Not optimal, but configuring the rest of Lync to work around this one issue causes more problems in my opinion.

So what this looks like is your User Dial Plan rule will normalize to +1XXXXXXXXXX;ext=XXXX not find a match for user, endpoint or unassigned number and route out through a PSTN Trunk. That call will then come back in on another channel and your PSTNGateway Dial Plan should normalize that incoming PSTN number to E.164 in the following format +1XXXXXXXXXX and then try to match a user or endpoint. When there is not user or endpoint found it will stop at your unassigned number handling.

911 Emergency
I know the normalization rules for 911 are fairly trivial to write, but what you need to find out in your dial plan is if each site, or floor, or zone has a specific number that needs to be passed to 911 operators. You can handle this a couple different ways. Either doing a Location Policy or handling with Voice Policies and Routes (with a Caller ID override).

If the PBX is actually doing true E-911 then you might need to consider using the E-911 function in Lync or using a similar E-911 or ELIN capability in the Gateway.

Paging
Within the dial plan you will also want to identify any paging within the PBX environment. Sometimes these are feature keys on the phone, but other times, they might actually dial something the resembles an extension. If it is a feature key, then you will need to develop a plan on how to handle Paging (usually analog FXS/FXO gateway connected to Paging system with Analog port). If it is extension based paging you have more detective work to do. You will need to identify how the paging system is connected and can you use a similar method with Lync or does the whole paging system need to be swapped out.

The above items are the critical pieces that get forgotten about when the talking heads go on about PBX replacement. PBX replacement is not easy and you need to always be prepared for that surprise that no one thought about.

Lync as a PBX Replacement Series - PBX Network Topology

Others in the series...

PBX Dial Plan
http://blog.ucomsgeek.com/2014/02/pbx-replacement-series-pbx-dial-plan.html

Analogs
http://blog.ucomsgeek.com/2014/02/pbx-replacement-series-analogs.html

Toll Fraud
http://blog.ucomsgeek.com/2014/02/pbx-replacement-series-toll-fraud.html

Overview
I thought I'd put together a few blog pieces going through some of the decision points I consider when replacing a PBX with Lync Server. This series does not cover any decision points regarding replacing PSTN connections with SIP trunks. This also does not specifically address PSTN concerns outside the United States.

Regardless of which vendor you have chosen, almost always you will need to deal with a period of co-existence when your goal is to replace a PBX. The areas I cover in this series stem from the complications of having two different systems coexisting and what areas you need to fully understand so that your strategy is sound and will be a good solution for your environment.

In this installment, I will be talking about the PBX Network Topology. Even before a Statement of Work is signed or if you are going about this on your own... you start turning the screws. Some PBX documentation needs to be dug up or created. I've fixed too many projects where someone has just started doing the integration without understanding the whole picture when it comes to the PBX. Once you have some documentation you'll probably have more questions, but that isn't a bad thing when it comes to working with the core communications of a business.

PBX Network Topology
Much like a data network, a PBX network has a topology as well. Depending on how well the PBX environment was managed this could be very logical layout... or a complete mess of spaghetti. Either way, when you look at it in a diagram you should see a network Topology pop out at you like a Hub and Spoke, Mesh, or Stand alone topology. This doesn't mean that you won't have some Branch to Branch direct connections that don't follow the topology... people do lots of crazy things over time and then forget why they did them. But overall, the design should pop out at you.

Hub and Spoke
In a Hub and Spoke scenario, there is typically one or more main sites and several branch offices connected to each main site. All sites can call each other, but for one branch to reach another branch it may have to pass through one or more main sites.

Typically Hub and Spoke is seen with TDM based connections between PBXs because the cost to connect all sites to each other is cost prohibitive. I've seen a Hub and Spoke network where all the PSTN access (Incoming and Outgoing) for a branch had to go to a main site. I've also seen where all sites had least cost routing to where a branch could make a Long Distance call and it would be a local charge because of sophisticated PBX routing.

Each PBX has its own routing table, but only to the next hop, much like a default gateway in a data network.

One last little thing to consider in a Hub and Spoke is that you may have Branch office PBX equipment that is dependent on the main site during normal operation. When you are looking at the PBX configuration, a branch may seem like it is part of the main site, but it is not. The Branch office PBX equipment is designed to come in to play when there is a failure to reach the main office. A that point the Branch office PBX takes over and starts serving the local users. In Avaya speak these are Local Survivable Processors (LSPs) and in Nortel speak you might hear CS1000B, Business Communication Manager (can be PBX too), Mini Carrier remote, or Fiber remote.

Mesh
In a Mesh scenario, all sites can route calls to each other directly. Each PBX may have its own dial plan, or they may reference a central routing server (H.323 Gatekeeper or SIP Proxy). A Mesh style PBX Network Topology is usually seen when a PBX network is VoIP enabled with either H.323 or SIP. This is also seen when there are multiple types of PBXs whether from one manufacturer or several.

Stand alone
Fairly self explanatory. You may have just one PBX you are replacing, but it is also possible your environment has several PBXs, but none of them are connected to each other. In this case, each of those PBXs would be considered stand alone. The PBX only has routing to the PSTN in this scenario.


Why do we care about the PBX Network Topology?
Gateway Placement
One of the reasons we care is that this directly impacts where we connect to the PBX network during the co-existence and the type of connection we will use.

With Hub and Spoke, it makes the most sense to use the Hub sites for PRI Gateway placement. PRI Gateway because you typically will see this with TDM based PBX networks. Placing a single Gateway at a Hub will more than likely cause a bottleneck either at PRI Gateway or a TDM connection in the PBX network. You can use ERLANG calculations to estimate the capacity needed at each hub to handle the highest volume of calls between Lync and the PBX (50% Lync and 50% PBX will be highest). When calculating you should consider calls between Lync and PBX extensions, but also Lync and the PSTN. If you don't want to use ERLANG calculations you can assume 1 out of 4 people will be on the phone at any given time calling either an Extension or the PSTN (doesn't count for contact centers). If the PBX environment has existing Call Detail Records (CDR) then those are also an excellent way to determining capacity and calling patterns.

With Mesh, if there is a SIP Proxy available, then the connection can be made there. Otherwise it is best to connect to each PBX directly. This type of connection is commonly referred to as "Direct SIP". If H.323 is involved, then one or more sites will need to be made into Hub sites and treated like a Hub and Spoke type implementation until all the sites are on Lync. One word of caution, don't assume all SIP is created equal. Make sure you have support for a Direct SIP connection, if not, you will either want to consider an SBC in between that is support by both Microsoft and your PBX vendor, or go back to a PRI Gateway connection.

With Stand alone, it becomes very important to determine if each site has a data connection present. If they do, you can deploy a Gateway to each site and use that to bring PSTN calls for those users to Lync. In order to do so, you will either need to replace the PBX in one fail swoop or do an Upstream (between PBX and PSTN) or Downstream (Gateway is connected to PBX and reaches PSTN through PBX) gateway implementation during co-existence. Since the PBXs are not already connected, the environment will need to have a dial plan created and users will need training on how to communicate directly with each other once they are on Lync.

Dial Plan
If you haven't already figured it out, this is where you will spend most of your time in designing your plan for co-existence and migration. I plan to dedicate a series to this, but your goal should be to work within the PBX dial plan and not have to change how users reach each other. Yes, this will take more work, but in the end your customer/users will be much happier.

With Hub and Spoke and Mesh, your goal is to figure out if the Topology defines how users dial a number. In other words, are you dealing with prefixed numbers that indicate a specific set of digits to identify a site. This will vastly change your Lync dial plan and create a lot of work to replicate how users dial their phone today and you need to account for this in your Statement of Work or Project Plan.

Voicemail
You got this awesome plan to use Exchange Unified Messaging once you are on Lync (I know it is the only supported)... but have you given thought to the order in which you will be replacing PBXs? Hint: if the PBX environment has centralized voicemail you won't want to start there or at the very least leave the PBX in place until all the others are migrated.

Order of Deployment
Speaking of "order of deployment".... Voicemail isn't the only thing that impacts this. Yes, you might have business reasons for the order or deployment (for future job security please don't put the executives on first), but you really want to consider your trunk capacity as you do your migration. When you start to approach that 50% mark you might want to choose one of your big sites... so that you won't ever hit that 50% mark, but jump right over it. This will help with your trunk capacity because you will go from having most of the users on the PBX to having most of the users on Lync. Once most the users are on Lync, guess what? They will call each other direct and won't be using a trunk.