Jochen Kunert : OCS

Migrating large TDM PBX systems to VoIP solutions

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

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

TDM to VoIP migration using PRI tie lines

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

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

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

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

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

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

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

TDM to VoIP migration using IP trunk connections

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

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

TDM to VoIP migration using GW fronted PBX approach

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

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

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

Conclusion

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

OCS 2007 Dialplan fundamentals

jkunert — Fri, 15 Aug 2008 18:00:00 GMT

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

jkunert — Wed, 30 Jul 2008 11:52:00 GMT

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.