OCS2007 Telephony integration options overview

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.