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.

Why Location Profile on OCS 2007 Mediation Server?

jkunert — Mon, 18 Aug 2008 11:21:00 GMT

In my last blog article OCS 2007 Dialplan fundamentals I have explained that we need Location Profiles in order to maintain the users dialing behavior before the OCS installation. A Location Profile is a set of regular expressions that will be applied on a called party number that is not in +<E.164> format. In General all called party numbers will be normalized to +<E.164> format before being processed by OCS to match a user SIP URI to this +<E.164> number or to pass it on to one of the OCS Mediation Servers. On outbound calls – there might be few exceptions – OCS Mediation Server will always be hit with +<E.164> formatted called party numbers.

On OCS Mediation Server you have to specify a single Location Profile. This is needed for incoming calls coming from a SIP Gateway/SIP connection into the OCS world when the called party number has not been normalized by the previous hop (e.g. Gateway) to +<E.164> format. If OCS Mediation Server receives a SIP INVITE with a called party number that is not in +<E.164> format, OCS Mediation Server will add the Location Profile information to the SIP INVITE (phone-context=<Location Profile>) and OCS Translations application (Not OCS Mediation Server) will apply regular expressions for this Location Profile on the non +<E.164> number in order to normalize the number before trying to match it to a user’s SIP URI using msRTCSIPLine attribute.

To proceed with the example started in blog OCS 2007 Dialplan fundamentals, the OCS Mediation Server in Frankfurt/Germany would be configured to use Location Profile FRA which would be a symmetric use of the Location Profile for local site dialing as well as for the OCS Mediation Server on inbound calls.

It is technically possible and in few situations technically necessary to use an asymmetric Location Profile on OCS Mediation Server. This means that a local OCS Mediation Server will not have the same Location Profile configured as for the local users of the same site. An example might be that the SIP Gateway that is connected to OCS Mediation Server has limitations in manipulating the called party number before sending to OCS Mediation Server and always adds an extra “0” as first digit of the called party number. In such a situation you would create a new Location Profile e.g. FRA_incoming that has basically the same normalization rules as FRA but an additional “0” in front of the called party number will be cut off.

Jochen Kunert : Mediation Server

Analog Gateways connected to OCS 2007

OCS2007 Telephony integration options overview

Why Location Profile on OCS 2007 Mediation Server?