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.