Jochen Kunert : gateway

Migrating large TDM PBX systems to VoIP solutions

jkunert — Fri, 31 Oct 2008 15:58:00 GMT

This article describes aspects of the migration process from a TDM (Time Division Multiplexing) PBX to a VoIP solution like Office Communications Server.

TDM to VoIP migration using PRI tie lines

A large enterprise TDM PBX consists of one or multiple PBX nodes. All endpoints (mostly PBX phones) on one site are connected to these nodes using two or four wire technology.

Before it is possible to connect a Gateway (GW) to a TDM PBX, a PRI link needs to be provided by the PBX. If no board with a currently unused PRI link is available in the PBX, an investment needs to be taken into this PBX by adding a PRI board. Costs are around 5.000 USD for a board + configuration (also anticipate delivery times for the new board) + sometimes networking licenses that need to be paid to the PBX vendor in order to configure a tie line. Worst case, if there is no space for another PRI board, a new shelf needs to be added or even an entire cabinet to place the PRI board into the PBX.

Now that an unused PRI connection became available in the PBX that can be configured to match a protocol of our GW, the VoIP GW can be connected to the PBX. Since it’s going to be a big VoIP deployment, an 8 PRI GW (=8 x 23 channels (US) or 8 x 30 channels (Europe)) will be purchased right away but in the initial stage only one PRI link will be connected to the GW.

Now it is possible to start moving users over from the TDM PBX to the VoIP solution by rerouting the extension of the TDM PBX user to the tie line where the GW is connected to.

More and more users will be migrated from the TDM PBX to the VoIP solution so that the need for tie line connections (PRI connections) between the TDM PBX and the VoIP solution increases. Why? Because users don’t change their communication behavior, just because they have been migrated. Migrated users will need to communicate with non-migrated users to the same extend as before the migration. Therefore the need for PRI connections (new PRI boards, PBX licenses …) increases while increasing the number of VoIP users.

The need for tie line capacity will increase up to a point where migrated users will start to communicate more and more with other migrated users. These communications will occur on IP without a need for Gateway and tie line capacity. At this point, there is no need for more PRI tie line connections anymore and the more users will be migrated to the VoIP solution less just previously installed PRI boards and sometimes even entire GWs become obsolete. This could be called a “Tie line paradox”.

This means at a given point, it becomes financially attractive to end the “smooth” migration process and do a “rip and replace” migration where the PBX solution will de decommissioned and the VoIP solution will become the only voice solution in the enterprise. At this point, the VoIP solution needs to take care also on the remaining extensions and connections of the legacy TDM PBX. This means the VoIP solution or the GWs need to provide a solution to connect fax machines, alarm systems, elevator phones, modems …. which has to be taken into consideration before pulling the plug on the TDM PBX.

TDM to VoIP migration using IP trunk connections

What happens, if the TDM PBX would be able to provide an IP trunk connection that matches the SIP requirements of the VoIP solution?

Essentially the migration path is the same. PBX needs to be configured for every migrated user and eventually licenses need to be purchased in order to install the IP trunk in the TDM/IP PBX (Hybrid PBX). But a significant difference is that no HW (PRI boards, GWs) needs to be purchased. To be more precise: No HW needs to be purchased that will be thrown away after the migration. The IP trunk connection is scalable.

TDM to VoIP migration using GW fronted PBX approach

Another approach is to place a GW between the PBX and the PSTN. In this approach the PBX needs to be configured for every migrated user to route the call to the PRI connections that were previously directly connected to the PSTN so that a call from a PBX user to a migrated user will pass through the GW. Also it needs to be configured on the GW that calls to migrated users from the PSTN will be routed to the VoIP solution and not to the PBX based on called party number.

Since the extension of users that will be migrated will never be in continuous number ranges, every extension needs to be manually configured in the routing table of the GW (of all GWs if there are multiple).

Please check with the GW vendor on how many routing entries are possible to configure as this number is currently rather limited and would prevent to use this scenario for big migration projects.

Conclusion

A “smooth migration” can be achieved in multiple ways. The PRI tie line approach is only good for the initial rollout. Before significant amounts of users will be migrated from the TDM PBX to a VoIP solution, IP trunk connections could to be used at first. But as soon as the majority of users (maybe >50%) has been migrated to the VoIP solution, the “rip and replace” method is the only financially interesting solution.

Analog Gateways connected to OCS 2007

jkunert — Wed, 03 Sep 2008 10:55:00 GMT

Depending on the country where OCS 2007 Enterprise Voice will be deployed, it might become necessary to connect analog Gateways to OCS 2007 Mediation Server. If there is no way to avoid this, a Gateway should be chosen that has been certified for OCS 2007 (http://technet.microsoft.com/en-us/office/bb735838.aspx). Furthermore please note:

· On Inbound calls: Neither calling nor called party information will be submitted to OCS, unless the Gateway has the chance to add this information. Another problem is that you can only assign as many DID extensions to OCS as you have analog lines coming from the PBX/PSTN.

· On Outbound calls: Unless the Gateway has some special functionality implemented, that allows the Gateway to address the correct analog extension line that has been associated to a certain extension based on the calling party number, the Gateway will use any available of the analog extension lines for outbound calls. This leads to the fact that called parties might get signaled wrong calling party numbers. Also since any extension line will be used for outbound calls, it might happen that OC users, that are being called from the PSTN/PBX world via the Gateway, will be signaled as busy to the calling party even though they are not in a call on OC.

OCS2007 Telephony integration options overview

jkunert — Mon, 25 Aug 2008 17:30:00 GMT

This blog article shows integration options of OCS installations with existing telephony environments from a high-level perspective.

An OCS 2007 voice deployment in a corporate environment typically starts with a pilot installation. Within this pilot installation, a handful of users, users of an entire department or an entire user population of a small enterprise site will be equipped with Office Communicator (OC) or Office Communicator Phone Edition (OCPE). The company has to decide whether they think that the right approach for their users to become comfortable with OC/OCPE is to get OC/OCPE in addition to or as a replacement for their currently used phones. The decision to remove a couple of phone extensions and replacing them with OC/OCPE has nothing to do with the final decision to replace the current TDM PBX/IP PBX with OCS! Sometimes I notice that there is confusion.

The adoption of OC/OCPE by users as the user’s “corporate telephone” is significantly depending on the design of the integration with the existing telephone environment. If the goal of the OCS voice pilot is to get experiences with Microsoft’s Unified Communications approach and its impact on the daily business, the migration of the existing user phone number to OC/OCPE should be targeted and OC/OCPE should be the only voice solution on the user’s desktop. Why? As long as a user has e.g. a PBX phone and OC standing on their desk, she/he will always fall back to the phone in case the user gets unsure about a specific functionality. Therefore the user is not challenged to change its usual behavior, occasionally even rethink his current behavior or adopt new behavior. E.g. if the user’s previous PBX phone always rings on incoming calls, the user will tend to accept or reject the call on this device. She/He will not notice the value of responding an incoming call with an Instant Message (like “not now, 5 mins”) and will continue e.g. to reject the call on the PBX phone so that the caller will be transferred to voicemail, leaves a message, this message has to be listened to by the user …

What are the integration options now to provide a smooth migration scenario that’s transparent for the users? One or multiple OCS 2007 Mediation Servers build the boundary to the outside OCS telephone environment. All supported connections of OCS 2007 Mediation Server on the non-OCS side can be found on Microsoft’s Open Interoperability Page. Based on this list, the following integration options with existing corporate telephone systems can be identified:

1. Connection via SIP Media Gateway

a. “MS-Gateway-PBX” scenario
The SIP Media Gateway will be connected to trunks provided by a TDM PBX

b. “MS-Gateway-Gateway” scenario
The SIP Media Gateway will be connected to trunks provided by an IP Gateway

c. “MS-Gateway-PSTN” scenario
The SIP Media Gateway will be connected to trunks provided by a PSTN carrier

d. “MS-Gateway-IP PBX” scenario
The SIP Media Gateway will be used as a SIP-SIP Gateway to provide protocol translation between SIP on OCS Mediation Server side and SIP on another vendors IP PBX side

2. Connection directly via SIP

a. “MS-IP PBX” scenario
OCS Mediation Server will be directly connected via SIP to a SIP IP PBX

Connection via SIP Media Gateway

“MS-Gateway-PBX” scenario

In this scenario OCS Mediation Server is connected to a SIP Media Gateway which is connected to a PRI trunk to an existing TDM PBX. This TDM PBX is connected with one or multiple PRI (Primary Rate Interface, E1=30 channels or T1=23 channels) to the PSTN. DID extension number range is 5 digit.

A PRI trunk connection will be used to route calls between the OCS system and the TDM PBX. On an incoming call from the PSTN or from another PBX extension, the PBX will route the call to the user extension (here e.g. 38999) via the PRI trunk connection to the SIP Media Gateway which is connected to OCS Mediation Server. On an outbound call from an OC user (here e.g. 38999) to a remaining PBX user or a PSTN subscriber number, OCS will route the call via OCS Mediation Server and the PRI trunk to the TDM PBX. The TDM PBX afterwards has to route the call to the designated PBX extension or to the PSTN.

“MS-Gateway-Gateway” scenario

In this scenario OCS Mediation Server is connected to a SIP Media Gateway which is connected to a PRI connection that’s been provided by an existing IP PBX Gateway. This is a possible integration option for those companies that have an IP PBX that has currently not been certified for direct SIP connection with OCS Mediation Server.

On the existing IP PBX/IP PBX Gateway a route will be configured that routes calls for OCS extensions to the PRI trunk connection where the certified SIP Media Gateway is connected. Incoming calls from the PSTN or other IP PBX extensions will be routed by the IP PBX via IP PBX Gateway/SIP Media Gateway and OCS Mediation Server to the OC user.

“MS-Gateway-PSTN” scenario

In this scenario OCS Mediation Server is connected to a SIP Media Gateway which is connected directly to the PSTN. The company has e.g. an old TDM PBX that does not offer the capabilities to provide a PRI trunk for SIP Media Gateway connection or the company had no corporate phone system at all (e.g. they only had cell phones).

There are multiple integration options now. One option is to order a new PRI link from the PSTN with a new number range and to forward the PBX extensions via the PSTN to the new PRI link. In this scenario the OCS user gets a new phone number and another disadvantage of this solution is that the OCS user usually just gets incoming calls from his old phone number as the forwarding phone number will be signaled on an incoming call and not the correct calling party number.

Another option is to connect the old TDM PBX to a PRI connection provided by the SIP Media Gateway. The SIP Media Gateway routes calls coming from the PSTN based on the dialed extension number to either OCS Mediation Server or to the trunk connection and therefore to the TDM PBX. This is an elegant way if most users have already been migrated to OCS Mediation Server and only a few users/extensions like e.g. fax machines, modems, alarm systems remained on the TDM PBX.

The last option is for recommended in such situations where only a handful of extensions could not be migrated to OCS. There are SIP Media Gateways on the market that provide ISDN BRI (Basic Rate Interface) or analog connections for extensions directly on the Gateway.

“MS-Gateway-IP PBX” scenario

In this scenario OCS Mediation Server is connected to a SIP Media Gateway which is connected to an IP PBX via IP connection. This is a recommended scenario for such IP PBX systems that have not been certified yet for direct SIP connection with OCS Mediation Server and the back-to-back SIP Media Gateway approach (“MS-Gateway-Gateway” scenario) does not seem to be appropriate.

The SIP Media Gateway has no PRI trunks connected but acts as an IP-IP protocol conversion Gateway. Depending on the Gateway it is possible to connect e.g. an H.323 IP PBX with SIP OCS Mediation Server or a SIP OCS Mediation Server with another vendor’s SIP IP PBX that has not yet been certified.

Connection directly via SIP

“MS-IP PBX” scenario

In this scenario OCS Mediation Server is directly connected via IP to another vendor’s SIP-based IP PBX that has been certified for direct SIP connectivity with OCS Mediation Server.

On an incoming call from the PSTN or from another IP PBX extension, the existing IP PBX routes the call to OCS Mediation Server and finally to an OC user. On an outbound call from an OC user to the PSTN or to an IP PBX extension, OCS will route the call to OCS Mediation Server which will route the call to the existing IP PBX. The IP PBX has to route the call after that to either the designated IP PBX extension or to the PSTN.

Conclusion

All the presented integration options above are possible integration options for OCS users that have been enabled for Enterprise Voice (also see here). Some of the direct SIP connection options (currently there is only one) can be used also for Dual Forking or Dual Forking with Remote Call Control if this connection option has been specifically called out on Microsoft’s Open Interoperability Program website.