When VOIP/UC RFPs Fail

Asking for an impossible combination of features in an RFP is a sure path to disappoint. And yet every week I see this in VOIP/UC RFPs.

Presence status = Busy (facing ethical debate – is it wrong to say "yes" to a question the asker doesn't understand?)

In my current role every week I receive UC/VOIP RFPs that ask for features and functions that are not available from any vendor!

Many times, the "ask" that is most problematic is from organizations looking to leverage Microsoft Office Communications Server (OCS) on the desktop as the soft phone and want all the features and functions that OCS Enterprise voice provides but want to combine these features with call control from a more "traditional" PBX.

Here's a recent example of two requested soft phone minimum requirements:

• "Integrate with Microsoft Office Communicator 2007 R2 (MOC) client to provide soft phone functionality. All calling functionality should be performed in OCS and not require the use of 3rd party interfaces."; and,
• "Remote soft phone operation must be equivalent to OCS Enterprise Voice mode".

The only way to meet these requirements is to actually use MOC as your soft phone!

Let's be clear once and for all, you only get all of the features of OCS Enterprise voice when OCS is providing the call control. You cannot use OCS as a full-functioned soft phone while using another PBX (Cisco, Nortel, Avaya, Mitel, etc.) as the primary call controller.

As much as people would like to choose two vendor solutions, put them together and get the superset of features, this is not how things work. See the Integration Myth for more details.

For further clarity:

• Cisco CuciMOC which integrates with Microsoft OCS only uses OCS for instant messaging and presence. Any of the OCS Enterprise voice features are not available when using Cisco CuciMOC.
• Avaya AES which integrates with Microsoft OCS only uses OCS for instant messaging and presence. Any of the OCS Enterprise voice features are not available when using the Avaya AES solution.

And neither Cisco CuciMOC nor Avaya AES solutions are supported by Microsoft.

Both CuciMoc and AES solutions are solutions created independently by Cisco and Avaya respectively using the publicly available APIs Microsoft provides to extend OCS. With both Cisco CuciMOC and Avaya AES, OCS is not participating at all in the call control so you get none of the OCS call control features. And while both Cisco CuciMOC and Avaya AES do work, neither the Cisco CuciMOC nor Avaya AES solutions are guaranteed to continue to work as OCS is upgraded; in fact, there are many signals that neither is likely to work with the release of OCS 2010, currently called Communication Server 14 (CS14) slated for Fall 2010 release.

Once again, because Microsoft neither supports Cisco CuciMOC nor Avaya AES integrations, Microsoft makes no attempt to test these solutions as new patches or releases are made available – and a more pessimistic person might even suggest Microsoft would like to "break" either of these two solutions.

Because Microsoft OCS 2007 R2 mostly provides the key voice functions of a PBX and because Microsoft CS14 provides all of the voice functions of a traditional PBX (plus lots of other UC functions), sharing call control between a Microsoft "PBX" and another PBX makes limited sense – it is either impossible or virtually impossible to get this to work in a "deeply" integrated fashion.

Would you put both a Cisco PBX and an Avaya PBX in the same office? (Likely not.) And if you did, some users would be connected to the Cisco PBX and would use Cisco IP sets while other users would be connected to the Avaya PBX and use Avaya IP phones. The two PBXs would be connected to each other via an internal SIP trunk so that a common dial plan could be used.

This, Direct SIP integration, is exactly the type of integration that Microsoft OCS R2 supports and CS14 will continue to support. With OCS integrated to another PBX via Direct SIP, some users use OCS endpoints (which can include OCS IP sets!) and some users use the other PBX vendor's IP sets. You do not try to give a user two "phones": an OCS phone and another IP set.

The specific integrations supported by Microsoft are always listed at the site http://www.technet.com/ucoip. Note that Cisco CuciMOC, a Cisco CUPS integration, an Avaya AES or Avaya SES integration are not on the list (and thus are not supported by Microsoft.)

The only PBX that Microsoft supports in a "deeper" integration manner is the Nortel CS1000 and this is only supported using Microsoft OCS 2007 R1 (released October 2007) not the OCS R2 release (released February 2009).

So, here we are then.

Customers would like to leverage their desktop investment in Microsoft OCS and their PBX investment and ask for integrated solutions between Microsoft OCS and other vendor PBXs that are not supported and do not provide the features customers think they do.

No Microsoft supported integration solution allows shared call control between the current version of Microsoft OCS and a Cisco or Avaya or Mitel or other PBX.

Of course, if you are a customer, you can ask for the impossible in your RFP. Or you can hire a consultant (who doesn't know any better) to help you write an RFP that asks for something impossible!

Just keep in mind that sales professionals are trained to say "Yes" or "Comply" to each and every RFP ask because customers have trained them that "telling the truth" is a quick way to disqualification. (This presupposes that sales professionals have enough experience to know the correct answer – which is often not the case.)

Instead, my advice to customers is to ask for what you really need based on having documented, prioritized business requirements. (For more thoughts on documenting your business requirements see Werewolves and UC.)

And perhaps while you are listing your requirements, consider only making "mandatory" the requirements that truly are mandatory for your business.

Presence status = Free (from guilt having said what others either don't know or choose not to say.)

Have you had to respond to RFPs asking for an impossible list of mandatory requirements? How did you handle your response?

If you are considering issuing a UC or VOIP RFP, do you really know what current UC solutions can deliver and what they can't?

Comments

[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/