CUCiMOC, is it too late?

I had a bit of hectic week last week, so coming up with ideas to write about fell a little to the side but I thought I would talk a little about Cisco’s upcoming integration to Microsoft Communicator. At the CIPTUG national conference last year CUCIMOC was announced during NDA sessions so now that they have released more information on I feel a little more comfortable talking about it on the Blogosphere.

Matt Mcgillen has written a bit about the functionality here in his blog so I am not going to cover all the technical details. I really wanted to talk more about where this may or may not fit into a enterprise and is it too late for some enterprises to take advantage of what CUCiMOC may have to offer. Matt’s blog by the way is an excellent source of information from a guy doing this stuff day in and day out. I highly recommend subscribing to it.

Once an enterprise commits to a deployment path it can be extremely difficult to turn the ship around and head in the other direct. So, I do not believe that Cisco were aiming this product at those that were already committed to OCS Enterprise voice. This product, I feel, is aimed at stopping enterprises from heading in that direction in the first place. There are a couple of things that I think are very beneficial and a few things that may need to be considered if looking at deploying CUCiMOC.

The benefits for an enterprise could be simplifying your environment and maybe, just maybe a reduction in licensing. Simplifying your environment is from a dial plan perspective and the ability to do RCC without CUPS. This is really from an infrastructure standpoint and not the desktop, which I will get to. Having one dial plan is a bit misleading though for a large enterprise that may have multiple clusters but it does mean not learning a new products dial plan. It does however provide a reduction in servers both for CUPS(RCC) and OCS mediation servers (OCS Enterprise voice). It also means not having to purchase the OCS license that includes voice features. Now depending on your current Cisco licensing this really may not amount to much anyway, so it’s all about crunching the numbers to see what comes out the best for your company.

Some things to consider would be a reliance on the desktop to provide the integration and a lack of collaboration between Cisco and Microsoft on development of this product. These two points are really intertwined. Let us just hang on the first point here for a second. This is what I consider a pretty complex integration happening at the desktop which unlike other desktop products like for example outlook where real time information is being exchanged to achieve a task. This is a complex task to achieve at a server level at times and now we are relying on the desktop to provide it. Not that I am questioning the ability of Cisco to provide a reliable integration but more of question of a user’s ability to break things through inadvertent activities, like installing an application they should not. I guess the comeback to this is users have been breaking stuff a long time we are used to that happening. This could be somewhat a of a benefit to, because if it does break it may only be the one user affected, unlike current RCC solutions where many could suffer.

On to my second point. When you look at the history in the UC space of the relationship between Cisco and MSFT it is rather contentious. This really comes through in the fact that MSFT has stated that it will not support this integration , which in essence may mean that when moving from one version of Communicator to the next, parts of or all of this integration may no longer work (RCC ring any bells out there). So, now we have a complex integration on the desktop that one company may refuse to help with should you deploy it and Cisco will have to ensure that they stay current with the latest version of MSFT Communicator to ensure it works. Which means it is quite possible your whole OCS deployment could become dependent on a plug-in being available for the version you want to deploy should your customers become reliant on it. Interesting scenario and a situation you may already be familiar with through other products, so may be not totally new.

I hope this didn’t seem to harsh on Cisco as this is a very innovative way to integrate the two environments and I know from experience, something customers using RCC products have been asking of Cisco for a long time. But at the same time I really feel the development of this is late and the uptake on it may be less than hoped. In the end only time will tell. If you have had experience with deploying CUCiMOC please feel free to post your thoughts, I would be interested to hear them.

For a comprehensive look at third party plugins for VoIP and Microsoft Communicator:


  1. Just rolling it out now in sub division of a major UK telco. We've got an existing CM6 with CUPC system but we need OCS to intergrate with other parts of the business so cucimoc for us is a great option to have. Its nothing like as responsive as CUPC but its not bad and at least it makes the vital switch to OCS far more smooth than it would otherwise have been.

  2. same - doing the ocs bit in the cloud and ipt in house - works well! Owenos at hotmail


Note: Only a member of this blog may post a comment.