CUCI-Lync and why you should think twice

Update: I’ve sheathed my sword a bit and toned down parts of this post because I was a bit of a fire breathing dragon. 🙂

Chris Norman has written a fantastic post over on his blog titled Lync Native Features Versus Plugins: Where Does The Real Complexity Reside?. It’s squarely aimed at third-party Lync call control applications like Cisco’s CUCI-Lync (Cisco Unified Communications integration for Lync) and Avaya’s Microsoft add-in built on their ACE (Agile Communication Environment) development platform that take away out-of-the-box voice and video functions from Lync and cripple the product.

Having deployed CUCiMOC first hand and seen it and CUCI-Lync in action, I can say that this type of integration scenario causes infrastructure and client management problems not to mention user experience issues.
I’m going to focus on the Cisco integration in this post, I’m going to pull a few references out of my Cisco Integration Scenarios document I wrote earlier this year here to wax lyrical about this for a bit.

Why would I want to deploy CUCI-Lync?

I’ve done the due diligence and cost/benefit analysis before, and I do appreciate why you’d want to use a PBX vendor provided client side integration scenario. Here’s a few reasons:

  • Utilise your existing investment in Cisco Unified Communications Manager, not to mention the large estate of Cisco handsets you probably own.
  • CUCI-Lync provides remote call control of Cisco handsets without Cisco Unified Presence Server (CUPS) – a typically difficult piece of kit for even a seasoned Cisco Voice professional to deploy.
  • Utilises Instant Messaging and Presence functionality provided by Microsoft Lync Server 2010.
  • Doesn’t require Lync Plus CALs for voice functionality.
  • Gives the end user the option whether to use a soft phone (Cisco IP Communicator – part of CUCI-Lync) or their Cisco desk phone to make and receive calls.

Adding Unnecessary Complexity

Everything in that bulleted list looks like awesome, low hanging fruit doesn’t it? Get all the cheap benefits of Lync and still use Cisco for voice. Thumbs up right, game on?

No.

The reality here is that there are a bunch of sacrifices you need to make to achieve this. Like these:

  • No native remote user access capability – CUCi-Lync requires VPN connectivity to log in and cannot leverage the Lync 2010 Edge Server to allow for remote voice use.
  • Adds an additional application to your desktop image to maintain and contributes to the suite of applications your helpdesk team must support.
  • No central management methodology – settings for CUCI-Lync are configured client side manually via the Windows registry or using Group Policy.
  • Cannot federate media with external organisations. Federation is only available with IM/Presence via the Lync Edge Server.
  • If you want audio/video/web conferencing, you need Cisco Meeting Place for this (another licensing cost).
  • Finally, the user experience is confusing.

Luis Ramos has another good review here of CUCI-Lync from his lab. From what I’ve seen and from what you can tell from the screenshots, the plugin looks and feels buggy, and doesn’t respond as snappily as Lync does.

The User Experience is Paramount

Weighing up everything that the PBX vendors harp on about not having to pay for Lync Enterprise and Plus CALs, utilising your existing PBX investment etc.. at the end of the day the key to the success of your UC deployment is the satisfaction of your users.

You’re deploying Lync to receive the benefits of a robust, clean and functional UC solution. If you introduce an additional user experience layer on top of that that requires users to learn slightly different ways to achieve different things, written by different companies, you will encounter significant resistance.

And what do we know about user experience? If it’s terrible, users will throw your solution back in your face. Which means your project has been a failure. That money you saved not buying Lync Enterprise or Plus CALs doesn’t matter now.

Has anyone actually heard of this being deployed in production at a company? Let me know in the comments.

37 thoughts on “CUCI-Lync and why you should think twice

  1. Blake Douglas

    I agree with all your points and really appreciate the write up, it’s really good to hear an open and transparent review of the call control integration aspect of a Lync/OCS deployment. For what it’s worth, I thought I’d share my thoughts on Lync – telephony (Avaya focused) integration based on my first hand experience over the last 3 months as I’ve attempted to deploy a new Polycom Video solution involving a migration from OCS 2007 to Lync and an Avaya telephony estate.

    My company has a OCS 2007 – Avaya Remote Call Control (RCC) integrated deployment through Avaya’s AES product today and whilst it does have some of the sacrifices you described, it doesn’t need a desktop install at all and is very transparent to users.

    We want to move to Lync because of some of the key features within the Polycom video endpoints whilst keeping the telephony related features we have today and enabling audio communication between all three vendors products and video between the Polycom/Lync clients. Avaya have advised me that there’s no ACE based integration method available until the 3rd ACE release which is due on the 5th of Dec 2011. When it does come, it’ll have a desktop app (One-X Communicator) which can be ‘headless’ and performs underneath the Lync client similar what you described with Cisco. The 3rd ACE release will provide the necessary audio capabilities to the integration.

    I’ve got a suite of Polycom HDX endpoints and an RMX pencilled for deployment in conjunction with the Lync roll out. All the Polycom nodes will effectively act like Lync clients and hang off the Lync server.

    From here on, it gets complicated for us since the Avaya’s ACE-Lync integration solution has the desktop based app integration pit falls that you’ve mentioned for Cisco. In addition to those, it’s not available till Dec 5th and I need to deploy my Lync/Polycom solution today AND the One-X Communicator client won’t support Video calls until mid 2012…which basically rules ACE integration out as a viable option today.

    There are today, two other Lync-Avaya integration options as I understand it from many conversations with Avaya; RCC and SIP integration. They advised that the Microsofts’ Lync RCC integration does not support a Video calls with a Lync client at the same time as a RCC call, so it’s not going to be possible to have the call audio via the telephone and the video on the desktop. With RCC, users would have to either talk on the phone without video or use a headset and talk through the PC, which is not the user experience we want to deliver as part of our new Polycom video deployment. I confirmed what they described by testing OCS 2007 based video calls with RCC calls and found that the Video and RCC calls were treated as two separate calls and the experience was exactly as described above.

    That appears to leave us with a straight SIP integration between Lync – Avaya as the last option. Whilst I believe that this will tick all the telephony related features and user experience requirements and do it better than an RCC integration, I am fairly confident that I’ll encounter the same user experience issue for any video calls with Lync clients as I mentioned would occur with the RCC integration. Basically any Lync user who wants to have a video call will have to use a headset through the PC, which we didn’t want to have to push onto the users as they have a perfectly good phone on the desk that they should be able to pickup and use for the video calls audio.

    I don’t believe that Lync will be able to split the audio off to the Avaya phone and keep the video in the Lync client without attempting to do something with the PC’s audio. At best I suspect that we may have the audio through the phone at the same time the video call is active and users will just have to mute the mic and speaker on the PC to prevent feedback or other audio, which is a poor experience at the end of the day.

    I remain uncertain as to whether we’ll be able to achieve the experience we want for video calls with lync clients but am hopeful that my Polycom and Microsoft contacts will pull a rabbit out of the hat. If you’re interested in the final outcome let me know and I’ll come back to you.

    Reply
  2. Pingback: CUCI-Lync and why you should think twice | Justin Morris on UC « JC’s Blog-O-Gibberish

  3. Pingback: Cisco UC Integration for Microsoft Office Communicator (CUCI-MOC) | a Single Point of Contact

  4. Sash

    I have seen people go both ways, and let me tell you this. Neither way is great at this point of time. CUCI-LYNC has its cons as mentioned in a thousand other Web Sites around that have Slammed CUCI-LYNC and CUCI-MOC. I am gonna have to do a Detailed Write up on LYNC for Voice and Video. Myself coming from a UC background and dealing with so many different Voice Vendors, and Video, telepresence, Presence, Contact Centers, Unified Messaging Platforms and now recently the Merging of IM, Presence and UC all into the UC platform. Let me tell you what Microsoft told us in a Sales Pitch. They plain told us that we have throw our Cisco Unity Connection Server out the window (alright) then use Microsofts Voice Platform for UM. and to top it off they use need the Media Resources from your Cisco Gear (trust me we did a POC and caught Microsoft lying to us red handed about Media Resources) I have no respect what so ever for Microsoft’s Solution since they lied to us, trying to sell a product just like everyone else. Cisco does it too, But it sucks when a bunch of Telecom Newbies like Microsoft start blowing smoke up your you know what.They Both suck at (both Micorosft UC and CUCI-LYNC)

    As a Customer and an Engineer I want to see who does it it better in teh future.
    My opinion is as follows;

    I like the LYNC User Experience
    I dont like the CUCI-LYNC Experience, it is confusing and ridiculous

    I Like the Cisco Backend Technology used
    I HATE Microsoft’s Backend Technology, it is the the worst designed voice product and is in its infant stages, Microsoft should be giving this away for Free for the next 5 – 6 years until they actually get some experience in the Voice world.

    Oh and for those who claim it is all about the user experience, here is something to think about !

    Uninstall Microsoft LYNC, throw your server out ! replace with Cisco Unified Presence, get yourself Cisco Personal Communicator instead, Install Meeting Place, run Webex. Use Jabber

    problem Solved, Fully Integrated and fluid User Experience not just on your Damn PC, but on your MAC, iphone, Android as well.

    Oh and if you are thinking about Cost, with CUWL we did the cost analysis too, it works about a little under the Cost incured for LYNC. The Only reason we couldnt toss LYNC out the windows was because of Political reasons and LYNC team didnt want to lose their jobs !

    Reply
    1. Justin Morris

      Thanks a lot for your feedback Sash. I really appreciate your candid and authentic real world take on your experience with CUCI-Lync.
      I think Microsoft has come a long way since say, the OCS days and still has room to improve, but Cisco is waning considerably and this is only reinforced by their recent attempts to stifle integration between Microsoft and Skype.

      Reply
  5. Corey Harrington

    Why would you ever replace Lync with any Cisco product? The complexity and cost model of Cisco is ridiculous. While Lync may be younger than a lot of other UC platforms, its a step in the right direction. I hate the argument that because its new its inferior. If that was the case a lot of companies and products that have changed the world would have been thrown out. There is no argument here. With 15+ years of telecom experience, Cisco ranks at the dregs of the telephony/UC barrel for me. Honestly I would tell my client to throw their money in the trash can before I recommend a Cisco purchase. There are so many ways to deploy Lync to reduce the complexity of the architecture while still keeping the integrity of the core feature sets. In addition there are many options for management in the form of UC control panels to clean up the backend of the system. There is a reason why almost all Fortune 500 companies use OCS/Lync, and its not politcal..its because it works.

    Reply
    1. Greg

      I bet I can tell what each of you have done for a leaving just by reading these posts. It is crazy that some of you have not realized that these platforms are all dependent on what service you are trying to provide and when it comes to the standard UC platform, if you ask a life long Cisco guy he will say Cisco and guess what, if you ask a MS guy guess what he will say. It is very easy to say throw out your CUCM or your Lync but if your responsible for the budget you may think twice. I have been and always will be a Cisco guy, it has paid the bills but I would think about putting in Lync if I was calling the shots and have put it in for several companies. My biggest concern is CAC and how to control or keep the cost for EF CAR down. Has anyone installed Lync with a CUCM and run them in parallel for a while? If so how did you handle your EF CAR as far as calculating how much to purchase?

      Reply
  6. randy wintle

    Hey Sash, curious about your experience.

    What are you referring to with using Cisco media resources?

    Also, can you name some specifics about what makes the Microsoft backend for voice so horrible?

    Is it the choice in hardware? Maybe the higher quality voice codec’s, or maybe its the consolidation of im/p, Mcu, and voice all in one box that has you upset…

    🙂 seriously though, am curious about why you have issues with the core infrastructure.

    Reply
  7. Rob Pop

    What is the Microsoft UC guys perspective on Microsoft conceding video support from Lync via RCC integration?

    Concession?

    Reply
    1. Justin Morris

      It’s a double edged sword I think. On one hand it allows a lower barrier of entry for orgs still invested in their PBX to deploy Lync with RCC and get all the good benefits of Lync such as desktop video. However on the other hand, it means RCC deployments could stay in place longer, delaying a full Lync Enterprise Voice deployment and replacing the PBX.

      Reply
  8. Matt

    Honestly Lync simplified the configuration model from Cisco, but at the cost of much of the enterprise functionality. Maybe 1/10 of my customers have a simplified dialplan and third party integration setup that can be supported with Lync, it just isn’t flexible enough.

    Saying Microsoft has the highest quality voice codecs is a farse, G722 is a fine codec, as is ILBc, oh and H.264. The killer is that everyone in the telecom world has multiple open codecs that can be used to interoperate…accept for microsoft. They only support G711…DUD. The cost to integrate with anyone else is sky high because of this. Microsoft did this and is putting up barriers to integration. I have integrated Cisco, Avaya, Shoretel, tons of vendors together with no problems what so ever because they use codecs like G711, G729, ILBc, and H.264 for video. I have to buy a 100k plus box to transcode RTV to H.264 just to get basic Conferencing integration.

    Second part, saying Microsoft has an MCU integrated is laughable. Unless something has changed, Microsoft does not support anything but current/loudest talker. There is no true simultaneous presence in LYNC unless you use…gasp an external hardware based MCU.

    The truth is Microsoft has two things going for it, Standard CALs are basically free now, and they have the only seamless edge client right now. When Cisco finishes releasing Jabber with integrated Anyconnect code across the board, one advantage will be removed. And free is no good if it can’t integrate into the $$ you’ve already spent on a phone system.

    Microsoft had dreams of people tossing their existing systems. No way. Every argument I see for people saying that there is a cost advantage to LYNC blatantly ignores the fact that people have already bought into another infrastructure and the costs of that can not simply be ignored. If you have a Cisco CUWL infrastructure you won’t throw it away, because renewing UCSS for another 3 years is so dirt cheap. Microsoft can’t compete with that pricing, so integration is the only reality. BTW, the cost model with Cisco is almost exactly the same once you consider Enterprise and Plus CAL costs and CUWL and CUWL is just as simple as LYNC. Also deployment complexity is very low for Cisco, as long as you are a Cisco engineer. I found it just as crazy to try and learn LYNC coming from the Cisco world.

    I used to love trying to push microsoft for the softclient infrastructure because it was such a great client, but Microsoft went the opposite way, instead of trying to improve compatibility and integration with existing system, they have tried to block it. I like what Microsoft is doing, but I can’t recommend it anymore to my existing Cisco customers, the integration is simply too crazy. Performing a RCC, Simulring SIP setup is painful.

    Reply
    1. Justin Morris

      Some really interesting points Matt, thanks for providing your feedback from a Cisco perspective. I agree re: the RCC/simring setup, which is why my preferred integration method now for Lync to existing PBXs is by Direct SIP or via a gateway only. RCC is just too much trouble than it’s worth and you lose native Lync functionality like voice over the Edge.

      There’s no doubt that Microsoft are pushing voice hard within Lync, which is why supporting PBX integration methods from the LCS 2005 days are waning and becoming more and more scarce on the ground.

      Reply
    2. Randy Wintle

      @matt I really am glad you brought up the G729 point because this has been bugging me.

      Microsoft picked a FREE industry standard codec, called G711.

      For any customer that is deploying OCS or Lync that wants a low bandwidth, high quality codec, RTAudio will do the trick. G729 is a licensing mess, and Microsoft should not be forced in to that. You could also argue, with the amount of deployed OCS/Lync seats, why don’t Cisco or Avaya license RTAudio on their systems to integrate with Microsoft?

      I think picking a free, industry standard codec makes more sense than licensing G729.

      As far as the quality of the codec, I will put RTAudio WB 16Khz against any audio codec out there, guarantee the quality is better, and the network impact is better. Play with it, do some research and you will see. We are not talking about G722 when we talk about quality of codecs….

      As far as the MCU Comment, I agree the Lync video MCU is not as feature rich as a hardware MCU. The Audio MCU is indeed a real MCU, it is mixing and processing audio.

      Video is limited to two possible streams being sent out, active and last speaker. However, this is a software MCU that is included on the Lync front end server at no extra cost, so it meets the needs of most customers.

      If you want to be able to integrate with Lync, you should work with a partner that actually wants to integrate with Lync, Polycom, they are natively working with RTV. Of course Cisco is not using RTV, and requiring you to purchase their expensive gateway to transcode. If you want to integrate cisco with any other platform, I am sure you will have to purchase that same gateway, not just with Lync….

      Reply
      1. Thor Hammer

        @Randy
        And as of Wave 15, not even Microsoft Lync will be using RT Video. Because from here on, it is all H.264 SVC. Let´s hope that all the millions spent on integrating two worlds that just went out of fashion has not been all wasted.

        Reply
  9. Pingback: CUCI-Lync and why you should think twice | Justin Morris on UC « JC’s Blog-O-Gibberish

  10. Matt

    @Randy Cisco did license RTV/RTA, well technically Tandberg did and the AMG is the result, it must be a super expensive licensing fee because the cost to transcode 10 sessions is about $10k a piece list (which is probably $6k real world). In my opinion microsoft should at least support iLBC, everyone supports it and it’s free. iLBC isn’t perfect but it would make a good integration point for everyone that is relatively low bandwidth and has good support for lossy environments. G711 is too bandwidth intensive.

    I believe Sash was referring to utilizing Cisco Transcoders/MTPs for analog/digital PSTN termination and G711 to G729/iLBC transcoding. Although you can use other vendors, Cisco is our recommended vendor in this arena and I know quite a few large VARs do the same.

    No doubt Polycom is very supportive of Lync, I wouldn’t be surprised if Microsoft buyout came. The problem is, most customers already have significant investments in legacy Polycom, Tandberg, Radvision, or Lifesize units throughout their organization. If they are HD, they are support H.264, which other video conferencing vendors are supporting for interoperability…even if they have their own proprietary codecs. In the mean time we are looking at Radvision and Polycom for advanced media gateways (hoping to get them cheaper), but honestly we have largely written off using Lync video for most of our integration deployments due to the cost of interoperating with existing HD video confereces.

    @Thor It seems to me much of our problems would be solved if Microsoft would support iLBC and H.264. I’m hoping wave 15 delivers, as I continue to love the Lync soft client from a usability perspective and I think Cisco and others are at least another year away from parity.

    The problem for Microsoft from a marketing perspective, is as long as these CUCILYNC like solutions are deployed, it’s just as easy for a customer to fall into the Cisco softclient camp as it is to fall into a full Lync deployment.

    Reply
  11. Jackie Chan

    @Matt – Ha! Microsoft won’t buy Polycom. They will play nice to take gain as much info as they can until they can build there own stuff that actually works, then ditch their relationship with them. If there is one thing that is certain, history repeats itself…ie- the nortel/MS “strategic” alliance. what a joke.

    @Thor Hammer…Come on…H.264 SVC as a standard. Just like Lync is a “SIP” client. lol.

    What would be nice is if both company’s could play along, use real standards and give their customers the experience they are asking for…Lync registered to CUCM as a direct 3rd party SIP endpoint.

    Reply
  12. Otto

    @Justin,
    Is there any solution out there that gives customer IM+ Presence, that at the same time can leverage the current cisco investment on cucm and unity conn. Provided that the customer runs on a MTS environment?
    Appreciate your comments.
    I was thinking CUCILYNC was an option, what do you think? jabber/webexconnect/cupc wont support MTS.

    Thanks.

    Reply
    1. Justin Morris

      Hi Otto, can you elaborate as to what a MTS environment is? If you want to leverage your Cisco investment for IM and Presence you need to use Jabber.

      Reply
  13. James

    Hi Justin,

    I read your whitepaper from Modality regarding the various options to intergrate CUCM and Lync/OCS. Is there any way to use Direct SIP, and replicate the users off hook presence? I can’t really find a definitive answer.

    My client doesn’t have a CUPS, and I am against recommending the CUCI-Lync option.

    Cheers,
    JR

    Reply
    1. Justin Morris

      Hi James,

      Unfortunately there’s no way to pass presence/call information through Direct SIP between CUCM and Lync today.

      Reply
  14. Tom

    If a company has already made significant investments with Cisco handsets, Cisco Unified Messaging, and Cisco/Tandberg Video endpoints/infrastructure then the answer seems pretty straightforward. We’ve tested/piloted all of the various Lync/Cisco integration types (CUCI, DirectSIP, SimRing, RCC) and the complexities and costs required to preserve the MS & Cisco environments while providing UC to the masses are just too great. Also, scrapping current technologies and investments is simply not an option when you consider where the ROI of UC comes from… it ain’t click-to-call & escalations, it’s travel reduction, LD reduction, and lower maintenance costs, which we already get from our existing products. Bringing UC functions together in a single interface isn’t the easiest ROI to show.

    Microsoft could have done their customers a great service by simply allowing MOC/Lync to register as a SIP endpoint for voice and video calls to any PBX/Video system. But they didn’t and we, along with many others, will be forgoing our upgrade to Lync and moving to the Webex Connect cloud or CUPS for IM/Presence. This allows us to continue to use our Cisco voice and video investments.

    Our telephony investments exceed $5 million and our video investments are around $500k. We use Webex a lot and tried Live Meeting but even the MS team doesn’t like it. The only other piece that MS is providing besides Exchange is IM & Presence and that tail won’t wag this dog. If you piloted either model of Jabber I think you’ll agree that current feature set is great and the promised future looks even better.

    For a Cisco voice and video shop(there are a LOT out there) I don’t really see how integrating with Microsoft for the desktop UC experience is really an option. If it were greenfield we’d be giving MS a BIG look but we’d still be leery of the tender young age of the product.

    My two cents…

    Reply
    1. Justin Morris

      Thanks for your opinion Tom, appreciate your input on this. I think the reason Microsoft didn’t allow MOC/Lync to register against any SIP registrar is pretty clear – they want a whole experience that is guaranteed, supported and doesn’t need loads of testing to provide interop. And probably, a “it’s either us or them” approach also.

      Reply
  15. Randy Wintle

    Glad this comment popped back up. I just got done working with a customer to help do a business case analysis for Cisco vs Microsoft.

    What the customer was able to realize, is that the UC Solution you deploy has to work, and has to work the way you want it. If it doesn’t do that, then there is no way users will use that system, and there is no way you will achieve your ROI. When you look at Cisco and MSFT UC at a high level, yes they both do the same thing, they provide a check box in the features you need, however its the details that will really come back to haunt you if you go down the cisco path.

    Cisco “UC” is made up of the following components:

    Cisco Messenger- IM/P and P2P A/V
    Cisco Webex- we all know webex
    CUCM for On Premise Enterprise Voice
    Cisco ASA for remote connectivity

    Now, those 4 platforms spread the workload across the following clients:

    Cisco Connect- IM/P P2P AV and can hook in to CUCM(More in a sec) + Enterprise Video
    Cisco Jabber- IM/P P2P AV and can hook into CUCM
    (note, I may have even got these two clients mixed up, point is there is two, and there is a feature gap between them)
    Cisco Webex- webex client, web client
    Cisco Anyconnect- VPN Client required for enterprise voice connectivity- yes, if you want to make or receive PSTN calls, you must VPN in. Lets also not forget that webex messenger is one service, and CUCM is another, so you are splitting that app in two just to make that happen…
    The story of clients on the mobile is pretty similar as well…

    Take the most basic scenario-
    I am in a call with Bob, I want to turn that into a conference with Alice. Remember when OCS R2 had live meeting still baked in (that product is 3 generations old btw), and you had to launch live meeting to do that? Well in the cisco world, it will load a webex web page, and start a new session in a conference.

    Now, you tell me, are your end users going to prefer to spread their workload across that disjointed “UC” product, or prefer to use a single application to do anything, from anywhere?

    I don’t even consider CUCIMOC as a valid approach anymore. There is not a single succesfull CUCIMOC deployment out there, and every organization that tries it, throws it away. Combine this with the fact that cisco cannot provide any valid references for enterprise voice using jabber, not P2P, it becomes pretty clear where their shortfalls are. We have to understand that the future is roaming clients, not IP Hardphones. Cisco does a great job at making a hard phone work on a managed LAN/WAN, however that is not how users work these days. Users need a seamless experience wherever they are, and even if they sit at the same cubical all day, they need that experience to be seamless within a single application, not multiple.

    Reply
  16. James Waite

    I think I had read this some time ago before you toned it down a bit. I was searching for it today to forward to someone else. I think I preferred the angrier version.

    James

    Reply
    1. Justin Morris

      Thanks James, good to know my passionate vitriol didn’t go wasted. 🙂 I think I only kept that version up for 12 hours or so when it was first published this time last year.

      Reply
  17. Avi Davidowitz

    Justin –
    Excellent piece overall and it is definitively making me rethink our Lync integration strategy. We are a branch office with separate VoIP infrastructure (Cisco) from HQ. We are in the process of upgrading from CUCM 6.x to 8.5 (or 9 – not final yet). Our HQ uses Lync Standard for IM only (well I guess Presence too). What would be the best way to offer our users interoperablility with HQ users for IM (and I guess presence) if not with CUCI Lync? Of course the other side DOESN’T have any CUCM infrastructure nor will they be willing to push Jabber clients out. Would our Jabber clients be able to receive IM and Presence data from their Lync server?

    Reply
    1. Justin Morris

      Hi Avi,

      No, Jabber cannot interoperate with Lync. Even if you deploy CUCI-Lync, you still need Lync to provide IM and Presence and to connect to HQ.

      Reply
  18. Will

    I just moved to a new company which uses OCS 2007 and CUCM 8.x. It seems to me that OCS doesn’t really provide ‘presence’, just provides a busy/free view into someone’s calendar or whether they’ve moved their mouse in awhile. I’d like to be able to see phone line status as well.

    What’s the least kludgy option for ‘integrating’ to to CUCM in terms of adding phone status? Is cucimoc the only choice?

    thanks,
    will

    Reply
  19. Doug

    So, is the conclusion that if you’ve chosen Lync for your IM/presence client, you are essentially stuck picking Lync for the PBX/backend? This sounds like cart before horse.

    Reply
  20. Matt

    Avi, you could setup federation between your CUPS server and their Lync server.

    Randy, believe it or not we have several very successful CUCILYNC deployments. It hardly matters as I feel there will be no CUCILYNC for Lync 2013…and I, like every engineer hate it is as a solution from an engineering standpoint.

    Lync to Cisco Voice and Video integration is almost impossible in my opinion, the only way to really do it is to hang one off of the other as a separate PBX, with separate phone #s and perform some silly simulring gymnastics. In addition to that you are stuck doing some major transcoding, and 2013 actually made things worse for now. H264 SVC is of course as standardized as SIP, and now there is no h263. Basically things are very ugly.

    I’ve now decided there is almost no way to justify both solutions with the licensing cost of Plus CALs involved. Unfortunately it means I have to wait for Cisco to stop dragging their feet and get REAL client parity up and running for Jabber. Cisco mobile clients are fantastic now and work wonderfully, they have a really smart approach to mobile client hand off now that works with existing features..not perfect still.

    Cisco has also made things more palatable with their current licensing changes. They still need a cheap, soft client only license (with video and voice). I really didn’t want it to end up this way.

    Doug…unfortunately, your conclusion is correct.

    Reply
  21. Pingback: Skype for Business and Cisco integration options | UC Road Map

  22. Pingback: Skype for Business, Lync and Cisco integration options – Hari Babu Online

Leave a Reply to Randy Wintle Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.