So, time for a tech blog. Office Communications server 2007 (R1 & R2) - let’s just call it OCS for now - has numerous telephony integration options, and a lot of people can find them quite confusing. I thought then that I’d qualify what the options are, and what their names are, just so we can be clear when discussing them.

Firstly, you don’t have to integrate OCS with any telephony system at all. In this environment you can still make VoIP calls between your Communicator users and do ad-hoc or arranged conferences again using Communicator. You can of course also use LiveMeeting for hosted application sharing and collaboration. To be fair, this is probably the most common scenario I see, with users making the most of Instant Messaging (IM), presence, and desktop VoIP.

Ok, so what can we achieve if we integrate into a telephony system? Well, there’s numerous options. First, let’s qualify the integration types.

Remote Call Control (RCC)

Remote Call Control (sometimes called third party call control) is the most basic of integration types. In this scenario, Communicator connects to and controls an existing telephone handset. Incoming calls on the phone result in a pop up toaster on Communicator showing you who is calling - you can use Communicator to answer the call however the call is answered on the physical phone device. This is a very important distinction.

You can right-click to call too from Communicator, and of course type in phone numbers. Communicator then takes the physical desk-phone off hook and dials the number for you - your call is made on the physical phone device. Also, your status on Communicator goes to ‘In a call’.

So, this is the most basic of telephony integration.

Enterprise Voice (EV)

Enterprise Voice is the next step up on the telephony level in OCS. In this instance, you replace your traditional phone with a soft-phone - I.e. Communicator. You place and receive calls using a headset or handset plugged in to your computer system. This is Microsoft’s preferred deployment type and they’ve been pushing it hard since the release of OCS R1.

Note that in this instance the user does not have a traditional phone. It’s a vitally important point that this solution replaces an existing desk-phone, it’s not intended to augment it. I hope the boldyness there helps express how important this point actually is.

Enterprise Voice with PBX Integration

This option is probably the most flexible as it combines the above two functionality sets. In effect a user can both control his traditional desk phone as well as make/receive calls using his Communicator client as if they were an Enterprise Voice user. They have the choice on which device to answer/make calls on.

This may seem like the nirvana of integration scenarios however there’s a few gotchas on this idea. Before we get to them, let’s consider the user profiles.

User Profiling

User profiling involves working out what your layout of users do, how they work, and solution would suit them best. Let’s start by making an assumption that all users will have OCS for Instant Messaging and the traditional OCS functionality. How do you handle their telephony requirements? Well, I tend to find that user populations full into the following rough groups:

Static Users

Static users have a desk, and a desk-phone. They’re unlikely to roam offices/sites/locations and when they do can use traditional call forwarding for their requirements.

Roaming Users

Roaming users have a desk however they’re also likely to regularly work from random locations for parts of their work time.

Remote Users

Remote users don’t have a desk and typically work from client sites or home (for example).

Now the above user profiles typically fit in to the following telephony models.

Static Users. These users would tend to prefer Remote Call Control (RCC).

Roaming Users. These users would suit the Enterprise Voice with PBX Integration.

Remote Users. Remote users would suite the Enterprise Voice (EV) solution

The above is just a rough guide on how tend to start tackling the user/telephony components of an OCS implementation.

Now, we need to look at roughly how each integration type is achieved with your existing telephony solution as I this also affects how you do your user profiling.

Remote Call Control (RCC)

RCC integration is achieved by implementing a ‘Computer Supported Telephony Application’ (CSTA) gateway into your existing telephony system. For example, with Cisco Call Manager (CUCM) this would involve implementing a ‘Cisco Unified Presence Server’ or CUPS. With Mitel, you’d be implementing a ‘Live Business Gateway’. You do not need an OCS mediator in this solution as there’s no media transfer between OCS and your PBX - only call control information. Other IP-PBXs have various offerings for CSTA gateways. For the current supported list have a look at the ‘open interoperability program’ (OIP) site.

Enterprise Voice

Enterprise voice is where it gets a little more complex. Firstly, you need an OCS mediation role in your solution. The OCS Mediator converts Microsoft’s Real Time Protocol (RTP) into a more traditional voice codec G.711 for use on your PBX system. The other thing is to consider is how the mediator connects to your PBX system.

Assuming your PBX is an IP based PBX you may be able to perform a direct SIP trunk from the mediator to your PBX. A number of systems are supported for this scenario - see the OIP page detailed earlier.  What affects this decision? Well, in my experience, the ability to implement a direct SIP trunk is limited by the IP-PBX’s ability to interpret E.164 telephony numbers (I.e. the +12122222954 fully qualified number). First, let’s just accept that all telephone numbers within OCS must be in E.164. Really, they must. Honest. Now, let’s consider how we get those numbers through to your IP-PBX.

First thing to consider is that there is actually a way to have the mediator drop the leading ‘+’ sign on the numbers. This means that using our above example your PBX would recieve ‘1212222954’ instead of ‘+12122222954’. You can then use traditional numbering manipulation in your PBX to ensure the appropriate actual number is dialled - prefixing a 9, stripping DDI to dial an extension etc. etc. Nothing that complex about that.

This method works for example with Cisco CallManager 6.x & 7.x (again, see OIP for tested & approved platforms) however it doesn’t work for CallManager 5.x. Also, it doesn’t work with the Mitell 3300 kit that I’ve been able to test on, although to be fair I don’t get that much playtime with that kit.

So, a quick summary - you can do a direct SIP if:

1. A)Your IP PBX understands full E.164 numbering
   OR
   

2. B)You can drop the ‘+’ on the mediator and manipulate on the IP-PBX to get the correctly dialled numbers.
   

To drop the ‘+’ OCS R1 see this article. It’s a WMI setting on R2 so it’s done slightly differently - see here.

What do you do if you can’t achieve the above? Well, you can put a gateway in them middle between the OCS Mediator and your PBX. You need slightly differing gateways depending on your PBX - for example if your PBX is a TDM based unit (Which I hope it isn’t) it’s more complex as you’ll need a gateway that supports QSIG or DPNSS. I’m going to assume that your PBX is an IP-PBX for the sake of this article.

By putting a gateway in the middle you can have a connection between the Mediator and the gateway, and then onward from the Gateway to your IP-PBX. The IP-PBX can then manipulate the phone numbers before forwarding them on to your IP-PBX. Additionally, the Gateway can re-format numbers coming from your PBX into E.164 for calls to be received on OCS.

So, there’s a little bit more to Enterprise Voice - as you can see! I’m working on another article on configuring a gateway such as a Cisco 2800 series for this purpose. Check back in a few weeks this should be published.

UPDATE: Article is here.

Enterprise Voice with PBX Integration

Now, this is an unusual one as it’s not typically possible to implement this with most IP-PBXs currently out in the wild - for example CallManager 5/6 or Mitel 3300s. Why not? Well, EV with PBX integration relies on a technology known as ‘Dual Forking’. An important element of dual-forking that’s essential to understand is that dual-forking allows the same phone number to be housed on two different PBXs. For example extension ‘5000’ could be housed on the PBX (so a traditional handset) and as an OCS client.

This is different to things such as Single Number Reach (SNR) where you have different phone numbers on different systems and the client simply knows to ring multiple numbers.

If you wish to support EV with PBX integration your PBX must support Dual-forking. Again, check out the OIP for currently tested platforms.

For what it’s worth, CallManager up to and including version 6 does not include dual-forking. It’s due to come out in a service release for version 7 however and I for one think it will make my implementation life a lot simpler, as the scenario of EV with PBX integration is often asked for.

Summary

Breaking down the above voice types can lead you to work out what functionality to offer which users. Firstly, does your PBX support dual-forking? If it doesn’t, and I’d guess it doesn’t, then you ONLY have the choice of:

Remote Call Control (RCC)

Enterprise Voice (EV)

If it DOES support dual-forking, your options are:

Remote Call Control (RCC)

Enterprise Voice (EV)

Enterprise Voice with PBX Integration (Can’t think of an acronym)

From that you can then map your static, roaming, and remote users to the functionality. The difficult ones to map are usually the ‘roaming’ users who also want a deskphone. If your PBX doesn’t support dual-forking and they do need Enterprise Voice then maybe an option is to replace their IP-PBX connected handset with a handset that is homed on OCS. That way they get their handset as well as their roaming capability.

The Polycom CX700 can fulfill this role for example.

You can download the data sheets for a few devices here:

Polycom CX100 - Speakerphone

Polycom CX200 - USB Deskphone for OCS

Polycom CX700 - IP Phone for OCS

I know Cisco is working a Communicator plug-in that will allow the choice of RCC/Enterprise Voice type functionality without the need for dual-forking - CUCIMOC I think it’s currently known as (Cisco Unified Communications Integration for MOC). Currently rumored for release in July 2009 it could address some of the difficulty in flexible deployments. Also, it would appear that CUPS will no longer be required, simplifying deployment on the telephony side too. There’s a presentation on it here you may find interesting.

Anyway, I hope the above helps qualify what the telephony options are for you. I’ll go into the technical requirements for integration in other articles.