« Latest Office Communications Server (OCS) 2007 R2 Updates and Rollups April 2010 | Main | Office Communications Server (OCS) 2007 R2 July 2010 Updates »

July 13, 2010

Comments

Feed You can follow this conversation by subscribing to the comment feed for this post.

Mac

I find this post kind of funny. First and foremost the example is beyond bizarre but more importantly the post seems to go to the examples of CUCIMOC and AES as examples of integrations that dont provide the feature set of OCS enterprise grade Voice. So I have to wonder if in fact this is a reall RFP question or is it used as a preamble to somehow discredit the above integrations. Ultimately I find it disconcerting that MS would not support these integrations and more troubling that they would somehow modify their API to cause issues in the future. This is the same API that their developer network would use to add value to the OCS environment so the law of unintended consequences would apply here. I thought OCS was an open software as you are platform. How is it that they can require certification for Direct SIP (which by the way we all know puts them in voice domain at a customer) but not suppor these alternative integrations. There are many viable reasons to use a single call control entity while retaining the presence and IM functions of OCS. Lets be clear that from a traditional voice feature set most of the 3rd party vendors will provide a superset of what OCS enterprise voice provides. I fear that this approach by Microsoft coupled with their ultimate intentions of delivering this from the BPOS cloud will really limit the choices customers have.j

Curtis Johnstone

Thanks for the perspective Kevin - it's good to hear stories from the field.

I don’t fully understand “You cannot use OCS as a full-functioned soft phone while using another PBX (Cisco, Nortel, Avaya, Mitel, etc.) as the primary call controller”. We are doing voice interop using OCS 2007 R2 direct SIP to CUCM 7.1 with simultaneous ring, and life is good. Not perfect, but good. In this environment Communicator is a fully functional soft-phone, but we still have our Cisco desk phones.

I would not expect to see CuciMOC listed at http://www.technet.com/ucoip because it does not do 'voice interop' per se; it is a client side plug-in that talks native Cisco over IP to provide the functionality.

In terms of Microsoft supporting CuciMOC, in the recent Microsoft AND Cisco Joint Interoperability Support Statement (http://www.microsoft.com/downloads/details.aspx?FamilyID=78814f28-2df5-4cff-a166-73622c7830bb&displaylang=en) Microsoft fully recognizes and supports CuciMOC in-so-far as supporting whatever functionality it uses for its published communicator API's. Which is fair IMHO - any platform vendor will provide support for the API's to function as published, but does not take responsibility for the actual 3rd party application.

A bigger CuciMOC issue for the deployments I have seen is the 130 Mb client side deployment and VPN requirement. That can be very rough in many environements.

Kevin Kieller

Mac,

While the examples may be "beyond bizarre" they are, unfortuantely, from a real RFP. And this is the type of things that I see asked for by customers almost every week.

I certainly believe that CuciMOC and AES are fine integrations with OCS; however, when with CuciMOC and AES you use OCS only for IM and presence, you should not expect to get any other OCS Enterprise Voice features.

Really the theme of my post is "know what you need and what you are buying or you are likely to be dissatisfied".

I would suggest that as the OCS platform evovles and especially as it becomes a full fledged voice and UC platform with the release of CS14, using OCS/CS for IM and presence and integrating it to another vendor's call control will make less and less sense and will propose more and more technical challenges.

As an analogy, this would be like trying to integrate the Cisco CUPC IM desktop client with Avaya Call Manager or trying to integrate the Avaya One-X desktop client with Cisco Call Manager for call control -- maybe possible(?), but clearly technically challenging and likely not supported.

I continue to believe that for a complete UC solution, "best of breed" using separate IM, presence and call control vendors is not the best approach.

Kevin

Kevin Kieller

Curtis,

Good feedback. Perhaps I was overly zealous when I wrote "You cannot use OCS as a full-functioned soft phone while using another PBX (Cisco, Nortel, Avaya, Mitel, etc.) as the primary call controller”.

Clearly when you use OCS for just IM and presence then you don't get all of the OCS voice and call control features. Some people seem to think that with CuciMOC and Avaya AES the audio path flows throw OCS -- this is not the case. With CuciMOC and AES you are using a Cisco desktop soft phone and an Avaya desktop soft phone respectively -- not OC.

The VPN requirement you mention with CuciMOC is a perfect of example where I see customers expect they get the VPN-less ability OC provides as a soft phone -- which of course they don't (because as above they are really using a Cisco soft phone).

In terms of CuciMOC support and Microsoft you provided a good link to the joint statement. For me this is Microsoft trying to "walk a fine line" in terms of supporting an API while not really liking what Cisco is doing. I think this post provides some further balance:
http://blogs.technet.com/b/uc/archive/2009/12/03/cisco_3a00_-just-like-any-other-office-communications-server-isv_3f00_.aspx

You correctly point out that in a Direct SIP environment OCS functions as a perfectly good soft phone, because with Direct SIP you really have two PBXs -- a traditional one and OCS as a PBX. And like two PBXs if you setup sim ring (or dual forking, or whatever you chosoe to call it) then both endpoints can ring. Of course to set this up you need to setup OCS voice services (and have the OCS Enterprise CALs) as opposed to with CuciMOC and AES where Cisco and Avaya promote that you only need the Standard CALs.

From what I have seen, both between OCS and Cisco, OCS and Avaya/Nortel or even Cisco and Avaya/Nortel, Direct SIP is a "clean" and supportable integration.

Kevin

Mac

Well I think the example you site is a bit different than integrating with OCS. For one its generally not the case that Avaya or Cisco has a major desktop presence and its clear that Microsoft Does. Second Microsoft is also more widely accepted from an IM/Presence perspective than Avaya or Cisco. Third from an enterprise voice feature both Avaya and Cisco have a stronger traditional voice feature set as you would expect. As I stated in my previous post, you will definitely find a superset of the traditional voice features in Avaya, cisco, or other voice platforms when compared to the OCS platform at this point (I would also include the new version of OCS in this comparison. Again this makes sense. So while MS has a strong IM, Presence, web conferencing offering these other vendors have a strong voice capability coupled with some other capabilities its clearly a complimentary solution. The issue I see with Direct SIP is that it does introduce another call control platform on the network and all of the redundancies that such a platform introduce. 2 sets of dial plans, routing, management overhead, feature interworking parity, different resiliency schemes and so on. This is not trivial and the complexity increases as you scale it up. Finally I think the API that MS provides is solid but lets not forget it takes 2 to tango so these other vendors must clearly have a viable set of software services from which to embed into OCS and specifically MOC. If they are willing and able to keep their interfaces clean than one would expect MS could do the same. I have a much different question that I am pondering. What does this all mean when OCS get delivered from the BPOS cloud. Will these same integrations that can be done today on premise be supportable in the cloud. I would hope so but I would be interested in anyone's perspective.

Kevin Kieller

Mac,

You are correct that Direct SIP introduces extra complexity but from my standpoint it is supportable and supported by both vendors so wortthy of strong consideration before going down CuciMOC or AES integration route.

Not sure I agree that CS14 has less "usable" voice features as compared to Cisco or Avaya. I like this quote from Henry Ford “If I had asked people what they wanted, they would have said faster horses." Microsoft with OCS decided not to make a faster horse but rather to invent the car. They handle voice (and other communication modalities) differently but from my experience, if the objective is to improve collaboration and productivity, OCS/CS14 does this better than a traditional VOIP PBX.

As I understand it, Microsoft has a roadmap to add voice services into BPOS. Carriers are already doing this with BPOS-D (the dedicated version of BPOS). See technet ucoip link in original blog post for list.

I do not think Microsoft will pursue BPOS linked into other call control providers. I don't think that would make business sense for them.

Call Controller Feature

This is the problem since PBX can't be made compatible with OCS from another manufacturer. This is crazy!

Mr Sheone

This is my first time at your blog and I've really enjoyed looking around. I will come back again in the future to check out some of the other articles. http://testvoiproutes.com/

The comments to this entry are closed.

My Photo
MVP_Logo_Horizontal_Preferred_Cyan300_CMYK_72ppi
Dino Caputo is a Skype for Business MVP delivering Microsoft UC solutions and Partner at enableUC.com

Visitors

Blog powered by Typepad