Jochen Kunert

Migrating large TDM PBX systems to VoIP solutions

2008-10-31T15:58:00Z

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.

How to make sure that Office Communicator uses the right Location Profile rules?

2008-09-15T15:12:00Z

In case you need to confirm that Office Communicator uses the correct Location Profile for a particular user, you can open the user's Office Communicator trace (//%userprofile%/tracing) and search for “LocationProfileDescription”. All regular expression rules and patterns will be shown, similar to:

<LocationProfileDescription xmlns="http://schemas.microsoft.com/2007/03/locationProfileDescription"><Name>RC</Name><Rule><Pattern>…

Analog Gateways connected to OCS 2007

2008-09-03T10:55:00Z

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.

OCS 2007 German dialplan example

2008-08-27T18:05:00Z

This blog article presents and explains an OCS 2007 Dialplan that has been created for the location Germany (Country code +49) Cologne (Area code 221). In this example the company has a local subscriber number 000 and a 4 digit extension range.

We assume that there is only one OCS 2007 Mediation Server with the FQDN (Fully Qualified Domain Name) ms.com and that on outbound calls the next hop element after Mediation Server (e.g. a SIP Media Gateway or a SIP IP PBX) takes care on normalizing called party numbers from +<E.164> format back to a proper format that again the next hop after that (e.g. PSTN) would expect. The only exception is emergency numbers that are sent as is prefixed with a + sign, so that the next hop after OCS 2007 Mediation Server just has to remove the + sign.

It makes sense to start with the creation of a Location Profile that allows users to maintain their current dialing behavior as they are used to from their previous voice solution. A good starting point is to collect from every site the following most common dialing behaviors:

· Common emergency call dialing pattern

· Common internal dialing pattern (e.g. 4 digit dialing)

· Common local dialing (what’s the external line prefix?)

· Common national dialing pattern

· Common international dialing pattern

These common dialing patterns should at least be incorporated into a Location Profile. As a result of the regular expressions of a Location Profile is (except for a few exceptions as mentioned above) an +<E.164> normalized number string.

External line prefix: Most PBX systems use an external line prefix to distinguish internal calls from external PSTN calls (Example: How else should be distinguished between the internal extension 112 and the external emergency phone number?). This pattern worked for the last 30 years in the PBX world, it’s there for a good reason and users are used to it. So, do not change this behavior during the implementation of an OCS 2007 dialplan. There are high chances that numbering conflicts occur in the long run.

Coming back to the example. People of the fictitious company in Cologne/Germany are used to dial:

· 0110, 0112 Police, Fire fighters

· 0116116 Emergency number for data accidents

· 1234 Intracompany call

· 01234.. Local call, same area code

· 001234… National call

· 0001234… International call

This dialing pattern leads into the following location profile:

Dialed Number example	Pattern	Translation	Normalized Number Sent from MS to next hop	Next hop to PSTN
0110	^0(11[02])$	+$1	+110	110
0116116	^0(116116)$	+$1	+116116	116116
1234	^([1-9]\d{3})$	+49221000	+492210001234	-
012345	^0([1-9]\d{1}\d+)$	+49221$1	+4922112345	12345
0012345678	^00([1-9]\d{1}\d+)$	+49$1	+4912345678	012345678
00012345678	^000([1-9]\d{3}\d+)$	+12345678	+12345678	0012345678

Here are some remarks to the rules above:

Rule 1,2: Emergency numbers will not be prefixed with a country or area code. Just with a ‘+’ sign. The next hop needs to remove the + sign and send it out to the PSTN.

Rule 3: The next hop behind OCS 2007 Mediation Server needs to remove the prefix +49221000.

Rule 4: Local, same area code calls will be sent to the PSTN w/o leading 0. This way directory services like 11831, 11833 … work as well with the same rule.

Rule 5: To dial a national call within Germany, the area code needs to be prefixed with a 0 and sent to the PSTN such way. The replacement of +49 with 0 before sending out to the PSTN is task of the next hop.

Rule 6: International calls need to be prefixed with 00 before sent out to the PSTN. So the next hop after Mediation Server needs to replace ‘+’ with 00.

At this point, here are a couple of important notes:

Complexity around Office Communicator Phone Edition on-hook quick dialing experience has been excluded in this example on purpose.

Users will be assigned to Location Profiles in OCS 2007 based on Windows Group policies. In current Windows environments, users will be assigned to Group Policies not with respect to their physical location. So please be careful which Location Profile to add to which users.

Keep in mind as I have described in a previous blog about OCS 2007 dialplan fundamentals, that normalization rules can be bypassed by entering a +<E.164> number. So do not try to implement dialing authorizations in the normalization rules as they can be easily bypassed by the user when using +<E.164> format phone numbers.

After the creation of a Location Profile for our site in Cologne/Germany, Voice Policies (dialing authorizations) need to be created for the different type of users. In this example we’ll have 6 different classes of dialing authorizations (this is what the user is allowed to dial). I have picked self explaining names. The leading digit just shows a hierarchy of the different dialing authorization levels:

VoIP Policy	User assigned to this VoIP policy is allowed to dial…
1EmergencyGER+InternalCGN	Emergency Numbers Internal Numbers on CGN company site
2EmergencyGER+InternalCGN +NationalGER-MobileGER- PremiumGER	Emergency Numbers Internal Numbers on CGN company site National Numbers No National Mobile Numbers No National Premium Numbers
3EmergencyGER+InternalCGN +NationalGER+MobileGER-PremiumGER	Emergency Numbers Internal Numbers on CGN company site National Numbers National Mobile Numbers No National Premium Numbers
4EmergencyGER+InternalCGN +NationalGER+MobileGER+PremiumGER	Emergency Numbers Internal Numbers on CGN company site National Numbers National Mobile Numbers National Premium Numbers
5EmergencyGER+InternalCGN +NationalGER+MobileGER- PremiumGER+InternationalGER	Emergency Numbers Internal Numbers on CGN company site National Numbers National Mobile Numbers No National Premium Numbers International Numbers
6EmergencyGER+InternalCGN +NationalGER+MobileGER +PremiumGER+InternationalGER	Emergency Numbers Internal Numbers on CGN company site National Numbers National Mobile Numbers National Premium Numbers International Numbers

With the notion of Phone Usages it is possible to select certain routes for a specific call to be used. The user is allowed to dial a certain number if Outbound Routing can match the phone number to a route pattern and the user is equipped with the particular phone usage that’s needed to use this route. The available Phone Usages are:

· EmergencyGER

· InternalCGN

· NationalGER-MobileGER-PremiumGER

· MobileGER

· PremiumGER

· InternationalGER

A user that has been assigned to VoIP policy 3EmergencyGER+InternalCGN+NationalGER+MobileGER-PremiumGER has been “tagged” with the following attributes (phone usages):

· EmergencyGER

· InternalCGN

· NationalGER- MobileGER-PremiumGER

· MobileGER

The order of the phone usages is highly important as well as that there are no overlapping routes (A route that allows something that a different route tried to forbid). Here are the routes for this example:

Description	Pattern	Phone Usage	Mediation Server
EmergencyGER	^((\+110)\|(\+112)\|(\+116116))	EmergencyGER	Ms.com
InternalCGN	^\+49221000	InternalCGN	Ms.com
NationalGER-MobileGER-PremiumGER	^\+49(?!(15\|16\|17\|900))	NationalGER-MobileGER-PremiumGER	Ms.com
MobileGER	^((\+4915)\|(\+4916)\|(\+4917))	MobileGER	Ms.com
PremiumGER	^\+49900	PremiumGER	Ms.com
InternationalGER	^(?!(\+49))	InternationalGER	Ms.com

If a user of the VoIP Policy 3EmergencyGER+InternalCGN+NationalGER+MobileGER-PremiumGER and the Phone Usage attributes “EmergencyGER”, “InternalCGN”, “NationalGER- MobileGER-PremiumGER” and “MobileGER” dials a German mobile phone number like +491710000000, the following things happen:

First Outbound Routing will check all routes for the first Phone Usage attribute “EmergencyGER”. There is only one route with this Phone Usage attribute. But the number +491710000000 does not match the pattern ^((\+110)|(\+112)|(\+116116)). Therefore the user is not allowed to dial this number based on the first Phone Usage attribute.

As a next step, Outbound Routing will try to match the dialed phone number to a route that’s tagged with the second Phone Usage attribute “InternalCGN”. Same result. Dialed number doesn’t match the pattern for the route InternalCGN and therefore the user is not allowed to dial this number based on the Phone Usage attribute “InternalCGN”.

Let’s check the next Phone Usage attribute “NationalGER- MobileGER-PremiumGER”. Here is important when you look at the pattern of this route, that German Mobile Numbers and German Premium Numbers have been excluded. ^\+49(?!(15|16|17|900)) (! means: Not). So a user who would just have this Phone Usage attribute would not be able to dial this number.

In order to dial this number, the user needs to have the Phone Usage attribute “MobileGER” as this is the only Phone Usage attribute that’s assigned to a route that contains German Mobile Phone numbers ^((\+4915)|(\+4916)|(\+4917)). Now the dialed number matches the route pattern and the Phone Usage attribute of the user matches as well and the user is allowed to dial this number.

OCS will pass this call on to OCS 2007 Mediation Server. OCS 2007 Mediation Server will pass this call on to the next hop that needs to modify the called party number back to 01710000000 before sending out to the PSTN.

An Enterprise Voice Route Helper file with this example can be downloaded here:

OCS2007 Telephony integration options overview

2008-08-25T17:30:00Z

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.

Differences between TDM PBX-Hybrid PBX-IP PBX

2008-08-21T16:03:00Z

In the context of OCS 2007 voice deployments it is essential to understand the fundamentals of existing corporate telephone systems. This article describes on a high-level how a TDM (Time Division Multiplexing) PBX, a Hybrid PBX and an IP PBX look like.

TDM PBX architecture

A TDM PBX is still the most commonly used corporate telephone system in the world. The initial design of TDM PBX systems was done in a time where there were no server-like systems that we know today with e.g. PCI bus-like standardized architectures available. Therefore PBX manufactures put lots of money and engineering work in creating proprietary system architectures with self-made cabinets, bus systems to allow flexibility and extensibility, matching proprietary endpoint hardware and firmware as well as protocols for the communication between the different components. The results of excellent hardware and software engineering as well as manufacturing were proprietary systems, designed to provide enterprise-grade telephony in a reliable high quality fashion.

The General architecture of TDM PBX systems were cabinets that provided power supply, operating system, occasionally hard drives, RAM, CPUs … for all the different boards that could be bought for this particular PBX and plugged into a proprietary bus system within a cabinet. The following picture shows a Nortel Meridian system with its cabinet and a couple of mostly extension boards plugged into the cabinet:

Over the years, more and more boards became available and each board served a specific purpose. There were for example boards providing:

- 16 analog extensions

- 8 digital extensions ISDN-BRI

- 8 proprietary digital extensions

- PRI (Primary Rate Interface) cards with 1 or 2 E1/T1 interfaces

- Management boards

- Boards to connect attendant consoles

- Interface boards to provide relay functionality for e.g. door opener

- Intercom functionality boards

- TAPI boards

- Music on hold boards

- Special extension boards to connect e.g. trading systems, hospital systems…

- …

Downsides of this architecture from today’s perspective were of course that customers had to buy boards from vendor A if you had a PBX from vendor A. Basically no chance to buy boards from vendor B for a vendor A PBX. Also extensibility was only possible in stages, as customers had to buy a 16 analog extension board if they had no more analog extension available and needed one more analog extension. This became very expensive when they needed another cabinet just to plug in the new extension board because there was no space anymore in the existing cabinet(s). Also not just hardware needed to be bought but software licenses as well, depending on the type of card. Vendors tried to mitigate this pain by offering per Port pricing models. The following Figure shows a simplified view of a TDM PBX:

Hybrid PBX architecture

Now what happened to the TDM PBX systems once Voice-over-IP technology could not be ignored anymore by the PBX vendors? PBX vendors designed a new board. Not just one but depending on the manufacturer a couple of boards that provided H.323 registrar or SIP proxy functionalities and had an Ethernet plug in order to allow IP phones to connect to the PBX (well now it’s a “hybrid” PBX as it provides IP and TDM extensions). But not just extensions became connected via IP to the cabinets but also entire cabinets could be placed in a distributed fashion, connecting with the main system via IP. Proprietary protocols tunneled in H.323 or SIP packets (in order to claim to be standard compliant) provided the same feature set to users as they were used with their previous phone. The good thing was that savings for the company by just using one common data/voice cabling system could be realized, no user trainings needed to be performed as the user experience basically was that they have a new looking phone now plugged into a different wall socket. I don’t want to sound sarcastic here: There was definitely the advantage for administrators as well as users to become familiar with VoIP technology and to figure out the right migration path for companies to move to VoIP. At the same time VoIP technology in General had the chance to mature. For hybrid PBX systems as an example, the following boards for the existing cabinets were offered:

- H.323 gatekeeper or SIP registrar boards

- Call server boards

- Signaling server boards

- …

The following Figure shows a simplified view of a hybrid PBX:

IP PBX architecture

Initial idea behind the design of IP PBX systems was to build corporate telephone system using VoIP technology, standard server hardware and existing corporate IP network infrastructure. Gateways were built to establish connections between the TDM world and the IP world. Similar to the board idea in the TDM world, Gateways became available that allowed connections to most endpoints were a direct IP connection wasn’t immediately possible (standalone FAX machines, modems, analog phones, door opener solutions, PSTN connections, PRI trunk connections to existing TDM PBX systems…). The heart of the system was usually one or multiple servers that were running on state-of-the-art server hardware. New functionality was added by creating new application servers. Depending on the manufacturer either proprietary endpoint hardware was needed to buy in order to gain most functionality out of the system (sadly, most of the time proprietary endpoints were designed to match a certain SW server release so that occasionally you had to buy new endpoint HW in order to be able to use new server functionalities) or standard endpoint HW could be connected with limited functionalities. Sometimes even dedicated logical IP networks for voice became necessary to eliminate conflicts with other business-critical IP applications. The following Figure shows a simplified view of an IP PBX:

Summary

It is essential to understand roughly the fundamentals of TDM PBX, IP PBX and PBX system in order to figure out the best migration path for an OCS 2007 voice deployment as no deployment should be designed following a “rip-and-replace” approach.

OCS 2007 dialplan using non-DID numbers

2008-08-19T16:15:00Z

In a previous blog article OCS 2007 dialplan fundamentals I have excluded the complexity around non-DID (Direct Inward Dialing) numbers for syntactic reasons. In this blog article I will describe how to handle non-DID numbers in an OCS 2007 dialplan.

A non-DID number is a phone number, that cannot be reached directly from the PSTN. Such a phone number can be dialed within a corporate PBX/IP PBX network by dialing an extension number, but this extension number is not publicly reachable from the PSTN. However, it is technically possible, if the extension has not been restricted, to dial a PSTN phone number from a non-DID extension. In General, the corporate main phone number will be signaled as calling party number to the external callee so that the external callee can initiate a call back to the user by using this main number. The call back will result in a call to the receptionist or an auto attendant that offers the possibility to the PSTN caller to enter e.g. by DTMF tones to postdial the user’s non-DID extension after the connection had already been established.

To proceed with the example introduced in the blog OCS 2007 dialplan fundamentals:

Within the Frankfurt site there is a number block on the PBX (extension range 50000-50999) that is a non-DID phone number range. The sample company had usually a 4-digit extension range from 1000 to 9999 but with the exception of the 5000-5100 range where this range has been expanded to 5 digits. This is from the German PSTN numbering plan possible as there is no fixed number length as for example in the USA, Denmark or France. If we take a look at the local dialplan for the sample company on the Frankfurt site, it would look like this:

49                           country code
69                           Frankfurt area code
000                         Company’s subscriber number
-0                            receptionist/auto attendant/corporate main phone number
-1000-4999          DID phone number range
-50000-50999     Non-DID phone number range
-5100-7999          DID phone number range
-80-89                   Cross-site prefixes
-9000-9999          DID phone number range

In the previous blog article OCS 2007 dialplan fundamentals the way to make the DID-phone numbers unique was to expand the user’s phone number to +<E.164> format so that corporate numbering plan matches the PSTN numbering plan. But what about non-DID phone numbers? What’s the correct way to fill in the msRTCSIPLine tel URI field? How to make these numbers worldwide unique as there might not just be an extension 50232 in Frankfurt but also on the other site in Hamburg?

There are – as always – multiple ways to solve this:

Using +<E.164 main phone number>;ext=<non-DID extension> format:

The recommended way for OCS 2007 which has already been mentioned on my friends Jens Trier Rasmussen’s blog would be to expand the phone number to a format that contains the corporate main phone number for the particular site in +<E.164> format followed by a prefix “;ext=” and the non-DID extension. In other words:

+<E.164 main phone number>;ext=<non-DID extension>

For our example the correct format for a Frankfurt non-DID user with the extension 50232 would like:

+49690000;ext=50232

And in the msRTCSIPLine attribute field (Line URI field in AD) you would need to enter:

tel:+49690000;ext=50232

+4969000-0 is the corporate main phone number of the Frankfurt site and 50232 is the non-DID extension of the user. By associating the non-DID extension to a particular site using the site’s main phone number, the non-DID extension became worldwide unique within the corporate telephone network.

Before using this format you have to make sure that in case you have connected a SIP Gateway between OCS Mediation Server and a PBX and you have remaining non-DID users on the PBX, that the Gateway is capable to eliminate the entire prefix “+49690000;ext=” before sending the called party number to the PBX.

For the Location Profile you have to make an additional regular expression rule that expands non-DID extensions to the format as presented above:

Pattern: ^(50\d{3})$
Translation: +49690000;ext=$1

For your convenience I have created an additional Enterprise Voice Route Helper file with an added rule to handle the non-DID phone number range 50xxx following this approach:

Using an arbitrary prefix to identify non-DID phone numbers:

Another option to make non-DID numbers unique within the worldwide OCS 2007 environment is to choose an arbitrary prefix for each site. An example would be +0001 for the first site, +0002 for the second… This procedure is only recommended if the Gateway or IP PBX that is connected to OCS Mediation Server is not able to handle the recommended syntax as presented above. You need to have rules configured on the Gateway or IP PBX that manipulate the called party number on outbound OCS calls by removing the arbitrary prefix and eventually replacing it with a DID main phone number.

Here is an example: A Gateway is connected between OCS Mediation Server and a PBX. An OCS user in Frankfurt dials 50232 in order to reach a non-DID PBX user on the same site. As the user has not been migrated to OCS yet, the call will be sent to OCS Mediation Server/Gateway. A normalization rule has been added to the Frankfurt Location Profile expanding non-DID phone numbers with a prefix +0001 (e.g. +000150232) that represents the Frankfurt site. On the other hand a rule has been configured on the Gateway that eliminates the prefix before sending it to the PBX so that on the PBX just the extension 50232 arrives. Downside of this procedure is that for every site you should have a dedicated prefix and you have to keep a manual translation table matching prefixes to sites.

The regular expression that needs to be added to the Location Profile when following this approach looks like:

Pattern: ^(50\d{3})$
Translation: +0001$1

For your convenience I have created an additional Enterprise Voice Route Helper file with an added rule to handle the non-DID phone number range 50xxx following this approach:

Using the subscriber number as arbitrary prefix to identify non-DID phone numbers:

The last option is to use the local corporate subscriber number (+4969000 in our example) in order to create a fake +<E.164> format number to handle non-DID extensions. This procedure is also just recommended in those situations if the Gateway or IP PBX that is connected to OCS Mediation Server is unable to work with the “main number ;ext=” prefix. The advantage of this procedure compared to the procedure above using an arbitrary prefix is that you only need one rule on the Gateway to remove +4969000 as a prefix before just sending the 4- or 5-digit extension number to the PBX/IP PBX.

The regular expression that needs to be added to the Location Profile when following this approach looks like:

Pattern: ^(50\d{3})$
Translation: +4969000$1

For your convenience I have created an additional Enterprise Voice Route Helper file with an added rule to handle the non-DID phone number range 50xxx following this approach:

Why Location Profile on OCS 2007 Mediation Server?

2008-08-18T11:21:00Z

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.

OCS 2007 Dialplan fundamentals

2008-08-15T18:00:00Z

I have noticed that many people, in particular those who have a telephony background or were working with common IP PBX solutions, try to match their gained dialplan know how, that they acquired over the last couple of years with many, many PBX/IP PBX projects, on OCS 2007. While there are few similarities with other IP PBX systems, there is at least one fundamental difference in the overall dialplan design of OCS 2007:

Traditional PBX and IP PBX dialplans were created mainly from a node-by-node or site-by-site perspective. If you had a node on site A and another one on site B in e.g. a different area code, the design of the dialplan was primarily focused on this particular site with some cross-node/cross-site prefixes in order to allow inter-site phone calls.

Here is an example: We have a PBX on site A with the subscriber number +4969000 with a 4-digit extension range (+4969000-xxxx). On the other hand we have a PBX on site B with subscriber number +4940000 and also 4-digit extension range (+4940000-xxxx). The two PBX systems were connected either physically or virtually with a direct link provided by a TDM (Time Division Multiplexing) carrier so that inter-site calls did not need to use the PSTN.

If now a user on site A with x1212 wants to make a phone call to the user on site B with extension 3699, she/he has to dial a site-prefix (that she/he needs to know of course, imagine this for 100s of sites!) followed by the extension of the user e.g. 88-3699. On the other hand, the user on site B has to dial 87-1212 in order to reach the user on site A with extension 1212.

PBX/IP PBX systems could even be configured to use the cross-site prefixes on incoming PSTN calls. So that a user in e.g. Hamburg could avoid a long-distance call to Frankfurt by dialing the local Hamburg subscriber number (here 000) followed by the cross-site prefix and the extension of the user (here 000-87-1212).

By using cross-site prefixes the dialplan of each site’s PBX could be kept unique. At any situation, even though if the same extension e.g. 1212 was given to a user of site A and to a user of site B, the dialplan was unique. If an incoming call from the PSTN on site B wanted to reach extension 1212 it was clear that extension 1212 on site B was meant. If another user on site B just dialed 1212 it was clear that she/he wants to cal extension 1212 on site B and not extension 1212 on site A, because then she/he would have dialed the cross-site prefix.

OCS has datacenter-model oriented architecture! This means it has been designed to provide real-time services (incl. voice/telephony) even for large enterprise environments by setting up a pool of OCS servers located in one or few worldwide datacenters. These datacenters are connected through the company’s corporate IP network with one another and all users, independent from their physical location, can connect via IP to these servers in order to receive real-time services. Effectively this means from a telephony perspective that formerly separate telephony nodes will be concentrated in one physical and logical location and therefore the formerly well-known site-oriented perspective on dialplans cannot be kept anymore as the uniqueness of the formerly known extensions cannot be maintained anymore.

So, how do the “extensions” have to be modified in order to become unique within the OCS “worldwide telephony system”?

The PSTN (Public Switched Telephone Network) gives an example of a telephony system where each endpoint has been given a unique numeric address, also called phone number. With this numeric address every endpoint can reach every endpoint and two endpoints do never have the same numeric address. The typical format that we are also all used to from our mobile phones is the E.164 format, usually written with a ‘+’ sign up front. Typical formats are

+<CountryCode><SubscriberNumber> or
+<CountryCode><AreaCode><SubscriberNumber>.

OCS uses this format to assign a unique phone number within the worldwide OCS environment to a user. This is one fundamental difference to most other PBX/IP PBX systems.

In the OCS world a phone number will be assigned to a user and not to a device. In the PBX/IP PBX world usually you would say: “This phone over there has extension 156”. So everyone initiating a call using this particular phone will obtain the identity that extension 156 represents. If this is usually Bob’s extension and Bill is initiating a call from it, callee John will have to assume that Bob is calling him on an incoming call. So Bill has to explain to John at the beginning of the call that he is not Bob. This is fairly easy even for John to notice as Bob and Bill will have a different voice, but in a Unified Communications environment where communication involves all media (e-mail, Instant Messaging (IM), video call, voice call, application sharing, SMS…) an outgoing call from Bill can be answered by John with an IM. Now, John has to be sure that he is communicating with Bob, because otherwise he might reveal information as part of the IM conversation that was not intended for Bill.

In order to avoid such situations in a Unified Communications (UC) environment, two things have to be assured by the system:

1. phone numbers need to be assigned to users in a worldwide unique fashion

2. Users need to identify themselves with the system before starting to communicate (e.g. Logon to Windows/Office Communicator using Windows credentials out of Active Directory)

In order to proceed with the example above, unique phone numbers for the sample users in Frankfurt and Hamburg would look like this:

User A1	+49690001212	User B1	+49400001212
User A2	+49690003699	User B2	+49400003699

The phone numbers will be assigned to users in the Active Directory user configuration as part of the communications tab. The “Line URI” field is the place where the user will receive her/his phone number. It’s also called msRTCSIPLine attribute. The format has to be in the following way:

tel:+<E.164> e.g. tel:+49690001212 or tel:+49400001212

What’s now becoming obvious, is that this format is not a really user friendly. Simone in Frankfurt who had extension 1212 with the previous PBX/IP PBX system might argue that it is not very comfortable for her to dial +49690003699 just to reach her coworker Christine who is sharing an office with her and had extension 3699 before the OCS roll-out. Agreed! In order to preserve the users dialing behavior and to allow an easier adoption of the OCS system as an enterprise voice solution, logical “dialing zones” can be built in OCS around a number of users of the same site that have the same dialing behavior. These zones are called “Location Profiles”. A Location Profile is a set of regular expressions that modify a called party number to the +<E.164> format that is uniquely used within the OCS environment to assign phone numbers to users. These regular expressions allow Simone to enter 3699 and based on her Location Profile the number will be expanded by Office Communicator to +49690003699 before sending to the system. This is transparent for Simone and she doesn’t need to know this. (After a while Simone will become used to the fact, that it is much easier to call Christine by clicking on a contact in OC or on a button in Outlook, but for the beginning of the adoption she should be able to maintain her previous dialing behavior.) If Simone wants to make an outbound call to the PSTN, she also can keep her behavior to dial “0040…” for a call from Frankfurt to Hamburg (First “0” is an external line prefix and second “0” needs to be dialed within Germany to reach other area codes) as the regular expressions of the Location Profile will convert this called party number to +4940… by replacing the first two leading “0” with “+49”.

For the example above we will have two Location Profiles, one for all Frankfurt users named “FRA” and one for all Hamburg users “HAM”.

How to create Location Profiles on OCS will be explained in a separate blog article. Location Profiles are assigned to Office Communicator users by Windows Group policy. An article about this topic can be found here. On Office Communicator Phone Edition 2007 users are able to change their Location profiles by themselves.

Up to this point we have seen that local Location Profiles on OCS solve the problem of having duplicate extensions on one worldwide, enterprise-wide voice system as well as the need for cross-site prefixes as known in the site-oriented PBX world.

We have to keep in mind though that endpoints on OCS at the end are not registered with a tel URI (tel:+4940000xxxx) but with a SIP URI (Session Initiation Protocol Uniform Resource Identifier) of a user (sip:example@company.com). So if Simone in Frankfurt dials 3699 to reach Christine, the regular expressions of the Location Profile will modify this called party number to +49690003699 and after that the User Services application of OCS will try to match this phone number to its entries of the msRTCSIPLine attribute field in the User Database. If the entry matches (this means that the called party has been enabled for Enterprise Voice on OCS), a SIP URI of the called party will be retrieved and a SIP session (SIP session with media voice = phone call) can be established between the two SIP users. If no SIP URI can be found within the OCS User Database that matches the modified called party number, this means that there is no user on the OCS system who has this tel URI (phone number) assigned. This means further that the called party has to be found in the outside OCS world.

To summarize at this point: Here are the three options to establish a voice call using OCS:

1. To enter the SIP URI (by clicking on contact in Office Communicator, by typing the SIP URI into Office Communicator …)

2. To enter the tel URI in the +<E.164> format (like you are used with your cell phone when e.g. dialing international numbers)

3. To enter a non-E.164 phone number

What happens on OCS?

1. OCS will send a SIP INVITE message to the entered SIP URI

2. OCS Translations Application will try to match the tel URI in +<E.164> format to a SIP URI of his User Database. If successful, SIP URI will be retrieved and SIP INVITE will be sent to the found SIP URI

3. Office Communicator will apply Regular Expressions of the Location Profile that the user has been assigned to. As a result of this Number Normalization process, a +<E.164> format number will be generated and sent to OCS. Further on as above in step 2.

If OCS has determined that a call is not in the OCS world (Reverse Number Lookup fails as no SIP URI can be found that matches a dialed +<E.164> number by a user), the call needs to be handed over to the outside-OCS telephony environment. For voice calls the boundary to the outside world (PBX with Gateway, Gateway connected to PSTN, SIP carrier…) is built by an OCS Mediation Server. While OCS Audio/Video Edge Server builds the boundary to the Internet for calls to Remote users or to other federated enterprises that use OCS as well, is the OCS Mediation Server break in/out point for connections to non-OCS users, currently mostly used for voice calls.

In the example above two OCS Mediation Servers with Media Gateways sitting between the PSTN and the OCS Mediation Servers have been added. One sitting in Frankfurt/Germany and the other one sitting in Hamburg/Germany. After the decision has been made by the OCS system that the endpoint called party number must belong to an endpoint outside of the OCS world, two things have to happen as part of the OCS Outbound Routing application:

1. It has to be checked by the system whether the user is allowed to dial this number to the OCS-external world.

2. OCS has to determine the most suitable break-out point (OCS Mediation Server) to hand over this call to the outside OCS world.

In common PBX/IP PBX system class of service rights have usually been assigned to extensions. Extension 1212 was allowed to make internal, local and national calls, while extension 3699 was allowed to make internal, local, national and international calls but no calls to premium numbers (e.g. 900). In OCS users will be tagged with attributes (representing “dialing rights”) and not extensions. There can be an attribute called “local” but there can also be an attribute “local_and_national”. These attributes are called “Phone Usages” in the OCS world. It is also possible to name the Phone Usages “A” and “B” as while defining Phone Usages they have no immediate relevance on the numbers that a user is allowed to dial. So don’t get confused.

One or multiple Phone Usages will be grouped in a so called “Voice Policy”. In the screenshot above of the Active Directory user configuration it is shown how a user will be assigned to a Voice Policy. There could for example be a Voice Policy named “InternationalGER-Premium” that includes the Phone Usages “Internal”, “Local”, “National-Premium”, “International”.

Phone Usages determine which “Route” a user is allowed to use for an outbound phone call. An OCS Route consists of a regular expression rule, one or multiple Phone Usages and an OCS Mediation Server FQDN (Fully Qualified Domain Name). The user is allowed to make an outbound call using a particular Route when the following two parameters match:

1. The dialed and normalized +<E.164> number matches the regular expression rule for this Route

2. The Phone Usage(s) for a particular route matches the user’s Phone Usage attribute (assigned to the user via Voice Policy) for this particular Route.

Here is an example: The Frankfurt user Simone has the Phone Usage attributes:

User Simone:

Location Profile:               FRA
VoIP Policy                          “NationalNoPremiumGER”
Phone Usages:                  “Internal” and “NationalGER-Premium”

OCS Routes:

Description	Regular expression	Phone Usages	Mediation Server FQDN
Internal FRA calls	^\+4969000	Internal	GwFRA.company.com
Internal HAM calls	^\+4940000	Internal	GwHAM.company.com
National GER calls No Premium	^(?!(\+49(?!(190\|900))))	NationalGER-Premium	GwFRA.company.com

She dials 0230001 in order to call for a taxi (“0” is the outbound dialing prefix). With the regular expressions of the Location Profile “FRA” the number will be normalized to +4969230001, Reverse Number Lookup fails as no SIP URI can be matched to this number and a Route needs to be determined to break-out this call to the PSTN. The user Simone has been tagged with two Phone Usages via VoIP Policy “NationalNoPremiumGER”. “InternalFRA” and “NationalGER-Premium”. The order of these Phone Usages in the VoIP Policy is important! OCS Outbound Routing will first apply regular expressions on the normalized called party number of these routes that have been tagged with the Phone Usage attribute “InternalFRA”. The regular expression for an “InternalFRA” route will look like ^\+4969000 as this Route should only be used for calls that are within the Frankfurt company site.

Description	Regular expression	Phone Usages	Mediation Server FQDN
Internal FRA calls	^\+4969000	Internal	GwFRA.company.com
Internal HAM calls	^\+4940000	Internal	GwHAM.company.com
National GER calls No Premium	^(?!(\+49(?!(190\|900))))	NationalGER-Premium	GwFRA.company.com

Since regular expression does not match the called party number, there cannot be a Route found for the Phone Usage attribute “InternalFRA”, OCS Outbound Routing will try to find a Route for this number to match for the second Phone Usage attribute “NationalGER-Premium”. A Route that matches this Phone Usage attribute would e.g. have the regular expressions ^(?!(\+49(?!(190|900)))) which basically means that the regular expression matches for all phone numbers starting with +49 but not +49190 or +49900, which are premium numbers. So if Simone would have dialed a premium number the regular expression would not have matched and Simone would not have been able to dial this number.

Description	Regular expression	Phone Usages	Mediation Server FQDN
Internal FRA calls	^\+4969000	Internal	GwFRA.company.com
Internal HAM calls	^\+4940000	Internal	GwHAM.company.com
National GER calls No Premium	^(?!(\+49(?!(190\|900))))	NationalGER-Premium	GwFRA.company.com

Simone has dialed +4969230001. Therefore the regular expression for this route will match. Since Phone usage attribute and regular expression match, a SIP INVITE will be sent to the particular OCS Mediation Server FQDN for this particular route and Simone is able to make this phone call.

An OCS Mediation Server is either connected via IP to a SIP IP PBX or via IP to a SIP/TDM Gateway that is connected either to one or multiple PRI (Primary Rate Interface , E1=30 channels, T1=23 channels) tie line of a TDM PBX or to the PSTN. In either way the next hop after the OCS Mediation Server has to modify the normalized +<E.164> number back to a format that is expected of following hops. In case that OCS Mediation Server is e.g. connected to a SIP/PSTN Gateway, the Gateway has to convert Simone’s call from +4969230001 to 230001 as expected for a local call by the PSTN.

I have prepared an Enterprise Voice Route Helper file (this is the tool you should always use to configure OCS 2007 dialplans, which you can get here) for the example above. You can download the example here (I have excluded the complexity around Emergency Numbers in this example but I have added a translation rule for the cross-site prefix that allows the user to dial the previously used cross-site prefixes):

Voice scenarios with OCS 2007

2008-07-30T11:52:00Z

Office Communications Server (OCS) 2007 offers multiple voice scenarios that are not necessarily easily understandable just by their names. However, it is essential to understand the different “flavors” of OCS voice in order to determine the best voice integration option for the specific customer environment. For this reason, I have explained and summarized the different voice integration options as follows:

PC-PC communication

Overview

This voice scenario was already available in OCS 2007 predecessor Live Communications Server 2005 SP1. OC acts as a soft client (software telephone), does not have a phone number (extension) assigned (only it’s SIP URI like someone@somewhere.com) and needs an audio or audio/video device connected to the PC in order to make and receive audio conversations by using your PC. Tricky: This is a VoIP scenario, but does not use any of the voice functionality, that has been added for OCS 2007! It’s peer-to-peer voice only between OC clients by using the SIP URI, no phone numbers.

User experience

In this scenario there is no connection between the OCS environment on the IP network and the existing PBX/IP PBX environment or the Public Switched Telephone Network (PSTN) at all! All calls are pure Intra-IP network calls from one OC user to another OC user, independent from any other installed PBX/IP PBX environment in the company.

In the office

The user can establish audio conversations (I could say "call" as well but want to make a small distinction here) by clicking on a contact in OC. The contacts OC client will start ringing and the callee will get a pop-up notification showing the caller’s name. The callee can pick up the call by clicking on the pop-up notification and a VoIP call will be established using the company’s IP network. Hook functionality provided by connected USB audio devices, even if they are UC certified, is not supported.

At home/on the internet

Same behavior as in the office. OCS Edge Server with Audio/Video Edge Server need to be deployed to allow this scenario from the internet without setting up a VPN channel to the company.

How it works in a nutshell

There is no additional hardware that needs to be deployed or configured. The only thing that needs to be done is to configure the user for this scenario in Active Directory, as shown in the following screenshot:

Summary

OC is an internal voice solution that only works on the IP network! You can use OC to talk to your colleagues that also have OC via IP but you cannot call your cell phone! You need to have another PBX/IP PBX phone standing on your desk for all non-IP calls.

Remote Call Control (RCC)

Overview

Also this voice scenario was already available in OCS 2007 predecessor Live Communications Server 2005 SP1. The users OC client does not act as a soft phone, does not need an audio or audio/video device connected to the PC and the user is not able to make or receive phone calls by using her/his PC. This is not a VoIP scenario!

User experience

In this scenario, an OCS 2007 user has a PBX or IP PBX phone with an extension (e.g. 1212) standing on her/his desk. In addition to that, Office Communicator (OC) 2007 is installed on the user’s PC.

In the office

On an incoming call the user’s PBX phone rings as well as that she/he receives an incoming call notification (pop-up window) on the bottom right of her/his PC screen, showing the Calling Party Number (Caller ID, phone number of the person who called) and also the caller’s name (if OC could resolve the phone number to a name by matching the phone number against Active Directory or Outlook contacts). The user is able to accept the call by picking up the receiver of the PBX/IP PBX phone or by clicking on the pop-up window for the incoming call on her/his PC. In both cases, media (voice stream) will stay on the PBX/IP PBX and there will be no VoIP connection to OC! The user does not need an audio device for telephony connected to her/his PC.

At home/on the internet

If the user receives an incoming call to her/his office number while being connected to the company’s IT environment over the internet (e.g. at home), the users PBX/IP PBX phone will ring in the office (what she/he most likely will not be able to hear J) as well as that she/he can see the pop-up window generated by OC on her/his PC. Accepting the call by clicking on the pop-up window will result in this scenario that the phone in the office will activate the speaker phone, but the user is not able to use her/his PC to talk to the caller. No VoIP connection through the internet is established! (However, the user can redirect an incoming call to her/his mobile phone and can pick up the call this way while working remotely.)

How it works in a nutshell

A CSTA Gateway (GW) needs to be installed between OCS 2007 and the PBX/IP PBX. Some PBX/IP PBX systems come with a CSTA interface natively so there is no need for an additional GW. Between OCS and the PBX/IP PBX call control commands will be sent, packed into a SIP INFO message that uses a long-lasting SIP dialog between OCS and the CSTA GW. The CSTA GW converts these call control messages into a format that the PBX/IP PBX understands. A CSTA GW is not a media GW so voice cannot be converted by a CSTA GW from a TDM (Time Division Multiplexing) or PSTN protocol to VoIP! OC can only control the functions of the PBX/IP PBX phone.

The OCS user needs to be configured in Active Directory as shown in the following screenshot:

Summary

What the remote control is for your TV, is OC configured for RCC for your phone! You are not able to use OCS as a replacement for your PBX/IP PBX phone.

Enterprise Voice

Overview

User experience

In this scenario, an OCS 2007 user does not need to have a PBX or IP PBX phone with an extension (e.g. 100) standing on her/his desk. Office Communicator (OC) 2007 is installed on the user’s PC and has its own extension (e.g. 1212).

In the office

On an incoming call to extension 100, in case there is still a PBX/IP PBX phone standing on the user’s desk, the PBX/IP PBX phone will ring and nothing happens on OC.

However, on an incoming call to extension 1212 the user’s OC client rings and the user receives an incoming call notification (pop-up window) on the bottom right of her/his PC screen, showing the Calling Party Number (Caller ID, phone number of the person who called) and also the caller’s name (if OC could resolve the phone number to a name by matching the phone number against Active Directory or Outlook contacts). The user is able to accept the call by picking up the receiver of USB audio device or by clicking on the pop-up window for the incoming call on her/his PC. In both cases, media (voice stream) will start flowing as a VoIP connection to OC using the corporate IP network!

At home/on the internet

If the user receives an incoming call to her/his office number while being connected to the company’s IT environment over the internet (e.g. at home, connected through VPN or via OCS Edge Server), the users OC client will ring and the user will see the pop-up window generated by OC on her/his PC. Accepting the call by clicking on the pop-up window (or picking up the receiver on the USB audio device) will result in a VoIP call using the internet and/or corporate IP network.

How it works in a nutshell

If you just want to use IP-IP calls within your corporate environment you don’t need a Media GW. Compared to the PC-PC communication scenario as described above, the only difference will be that you can use UC-certified audio devices as well as that you can call other OC users by entering their OC phone number. But then OC cannot replace your current PBX/IP PBX phone at your desk as you cannot receive or make phone calls to e.g. phone numbers on the PSTN. A Media GW needs to be installed in order to establish a break-in/break-out (connection) point between the corporate IP network and the corporate TDM telephony network or the PSTN. You cannot call your mobile phone or your mom at home without having a Media GW. Recommended and certified Media GWs can be found here: http://technet.microsoft.com/en-us/office/bb735838.aspx . In addition to the installation of one or multiple Media GWs, you need an OCS Mediation Server (can be collocated on the GW, so called hybrid GWs) that – among other things - converts Microsoft’s dynamic audio codecs to simple, static G.711 codec, that most standard GWs support.

The OCS user needs to be configured in Active Directory as shown in the following screenshot:

Summary

OC is your phone at your desk! You can use OC to talk to your colleagues that also have OC via IP or you can call your cell phone by using the corporate IP network and a Media GW. You are able to use OCS as a replacement for your PBX/IP PBX phone.

Enterprise Voice with PBX integration – blank SIP Server URI (aka Dual Forking)

Overview

This scenario is new with OCS 2007. OC acts as a soft client (software telephone), has a phone number (extension) and needs an audio or audio/video device connected to the PC in order to make and receive phone calls. This is a VoIP scenario! In addition to that the user has a PBX/IP PBX phone standing next to her/his PC with OC on his desk that has the same phone number (extension) as OC! OC and the PBX/IP PBX phone will ring both on an incoming call to your extension.

No CSTA GW is deployed, but only a Media GW!

User experience

In this scenario, an OCS 2007 user needs to have a PBX or IP PBX phone with an extension (e.g. 1212) standing on her/his desk. Office Communicator (OC) 2007 is installed on the user’s PC and has the same extension (e.g. 1212) as the PBX/IP PBX phone.

In the office

On an incoming call to extension 1212 the user’s PBX/IP PBX phone rings as well as the user’s OC client (that’s what “Dual Forking” is and that’s what’s behind the setting “Enable PBX Integration” in the AD user configuration) where the user receives an incoming call notification (pop-up window) on the bottom right of her/his PC screen, showing the Calling Party Number (Caller ID, phone number of the person who called) and also the caller’s name (if OC could resolve the phone number to a name by matching the phone number against Active Directory or Outlook contacts).

The user is able to accept the call by picking up the receiver on the PBX/IP PBX phone in which case the voice stream will be handled by the PBX/IP PBX and there will be no VoIP connection to the callee's OC client. Since no CSTA GW has been deployed and no SIP Server URI has been configured for the user as part of the AD user configuration, OC does not get a notification that a call has been established on the PBX/IP PBX phone and does not change its presence state to “in a call”. In addition to that the user is not able to use in-call control features through OC.

However, if the user accepts the incoming call by picking up the receiver of her/his USB audio device that’s connected to the PC/OC or by clicking on the pop-up window for the incoming call on her/his PC, media (voice stream) will start flowing as a VoIP connection to OC using the corporate IP network, presence state will change to “in a call” and the user is able to use all in-call control features of OC!

At home/on the internet

If the user receives an incoming call on her/his office number while being connected to the company’s IT environment over the internet (e.g. at home, connected through VPN or via OCS Edge Server), the users PBX/IP PBX phone in the office will ring (again, she/he will most likely not able to hear this) as well as OC client will ring at home and the user will see the pop-up window generated by OC on her/his PC. As the user is not physically in the office, the appropriate way to accept this incoming call is by clicking on the pop-up window (or picking up the receiver on the USB audio device, connected to the PC) which will result in a VoIP call using the internet and/or corporate IP network.

How it works in a nutshell

To enable this scenario you need at least one Media GW but no CSTA GW. It makes only sense to enable this scenario if the connected PBX/IP PBX system supports “Dual Forking” as well. If not, only calls that initiated on OCS (e.g. an OC-OC call) will be forked to the PBX/IP PBX by OCS but not vice versa. If someone calls from the PSTN the extension 1212, the PBX/IP PBX phone with extension 1212 will ring but the PBX/IP PBX will not fork the call over to OCS, so OC will not ring. If the PBX/IP PBX supports Dual Forking as well, incoming calls to extension 1212 will be forked to the other system regardless of its origin. Since no CSTA GW is deployed and no Server Line URI is configured for the user, call control information that can result in presence state changes will not be reflected.

Certified PBX/IP PBX systems for Enterprise Voice with PBX integration/Dual Forking (if any) can be found here: http://technet.microsoft.com/en-us/office/bb735838.aspx .

The OCS user needs to be configured in Active Directory as shown in the following screenshot:

Summary

As you might already notice, having Enterprise Voice with PBX integration configured but without a CSTA GW (aka Dual Forking) does not provide a consistent user experience as presence states do not reflect the actual user’s status. The user has to decide before picking up the phone which endpoint (PBX/IP PBX phone or OC) will offer appropriate functionality to handle the upcoming conversation.

Enterprise Voice with PBX integration (aka Dual Forking with RCC)

Overview

At least one CSTA and one Media GW need to be deployed!

User experience

In the office

On an incoming call to extension 1212 the user’s PBX/IP PBX phone rings as well as the user’s OC client where the user receives an incoming call notification (pop-up window) on the bottom right of her/his PC screen, showing the Calling Party Number (Caller ID, phone number of the person who called) and also the caller’s name (if OC could resolve the phone number to a name by matching the phone number against Active Directory or Outlook contacts).

The user is able to accept the call by picking up the receiver on the PBX/IP PBX phone in which case the voice stream will be handled by the PBX/IP PBX and there will be no VoIP connection to OC. Since RCC is enabled (CSTA GW deployed and Server URI configured for the user), OC gets a notification that a call has been established on the PBX/IP PBX phone and changes its presence state to “in a call”. As in the RCC standalone scenario, no VoIP media stream will be sent to OC for this call, just call control information.

However, if the user accepts the incoming call by picking up the receiver of her/his USB audio device that’s connected to the PC or by clicking on the pop-up window for the incoming call on her/his PC, media (voice stream) will start flowing as a VoIP connection to OC using the corporate IP network!

At home/on the internet

If the user receives an incoming call on her/his office number while being connected to the company’s IT environment over the internet (e.g. at home, connected through VPN or via OCS Edge Server), the users PBX/IP PBX phone in the office will ring (again, she/he will most likely not able to hear this) as well as OC client will ring and the user will see the pop-up window generated by OC on her/his PC. As the user is not physically in the office, the appropriate way to accept this incoming call is by clicking on the pop-up window (or picking up the receiver on the USB audio device, connected to the PC) which will result in a VoIP call using the internet and/or corporate IP network. The user’s presence state will change to “in a call”

How it works in a nutshell

Enterprise Voice with PBX integration with CSTA GW deployed and Server URI configured (aka Dual Forking with RCC) is a combination of the RCC scenario and the Enterprise Voice scenario. You need a CSTA interface from the existing telephony environment or a CSTA GW as well as a Media Gateway to convert VoIP traffic between the TDM and the VoIP world. The user is free to accept an incoming call or make an outgoing call on either endpoint (PBX/IP PBX phone or OC) and the two systems (PBX/IP PBX and OCS) will exchange call control/call status information using the CSTA interface. While it looks like a “benefit” for the user to be able to become familiar with the new technology and still being able to fall back to her/his legacy phone, there are taxes that need to be paid. On one hand there is the need to buy and configure both GWs (CSTA and Media) incl. configuration of OCS and the legacy PBX/IP PBX and on the other hand there is the chance to confuse the user about using which phone in which situation having different sets of capabilities during the call.

Certified PBX/IP PBX systems for Enterprise Voice with PBX integration/Dual Forking with RCC can be found here: http://technet.microsoft.com/en-us/office/bb735838.aspx .

The OCS user needs to be configured in Active Directory as shown in the following screenshot:

Summary

OC and your previous PBX/IP PBX phone are both your phones at your desk! You can use OC to enter a phone number to establish or receive a call or you can use your legacy PBX/IP PBX phone to establish or receive a call. If you have picked up a call from another OC user on OC, you will be able to exchange IMs, adding video to your conversation, escalate to Live Meeting sessions etc. out of the conversation window. If you pick up a call from another OC client on your PBX/IP PBX phone, you will just be able to use voice-related basic call functionalities (incl. hold, transfer …) but no multimedia capabilities.