Join Teams work meetings from Microsoft Teams (free) and vice versa

Microsoft Teams (Free) users can currently join Teams for work (or school) meetings only as guests, which requires them to use a browser and results in a sub-optimal experience. The new feature rolling out will allow these users to join Teams for work (or school) meetings in one click, without being redirected to the browser or asked to fill in their name/surname. They will also be able to continue collaborating with the meeting organizer and other participants via meeting chat after the meeting.  The feature will work in the opposite way as well, so Teams for work (or school) will just as easily be able to join meetings hosted by a Teams Free user with one click. This is associated with Roadmap ID: 167326

Lync in coexistence with CUCM part 3 (pro's and con's)

Now then, after looking at two ways of integrating CUCM and Lync, let's discuss some of the alternatives I have not covered, the different scenarios and some pro's and con's of the implementations.

There are of course other ways to create an integration between CUCM and Lync. One of them is to install a CUPS (Cisco Unified Presence Server) in the CUCM environment, and set up a federation. This however; Can not be done if and when the CUCM has an integration with AD (same ad as Lync), or if they share the same domain name space. Also bear in mind, you still need an enterprise voice solution for those users residing on Lync. Having two different presence systems might also be an administrative burden, and quite difficult to maintain.

Another way to do an integration, is to use the application component of Lync, and create a "SIP Trunk" to a CUPC (Using what some call "Simple SIP"). I consider this as a kind of federation (though not going through the Edge server). But if I have understood our partner contacts correctly this is probably not a solution Cisco (nor Microsoft) will put much development efforts into in the future.

What about the options I highlighted in part 1 and part 2? Which solution is the best? Well, there is no black or white answer to that question. If there had been, I would have left the other one out. What You as a technician/consultant have to focus on, is this: What suits your organization best? Where do you see the company in few years time? Are you (or your customer) going to stay with the CUCM as your primary PBX, or will you switch to Lync down the road?

In my mind, if you are not planning on switching to Lync, the Lync plug-in described in part 1 is probably the best solution. It will give you presence information in every scenario to both platforms. You have only one PBX, and there are very few sources for complex errors. And it is probably the "only" really supported solution from Cisco (to the best of my knowledge at this point).
The only real big drawback with this solution, is the lack of built-in remote capabilities. This could probably be remedied by using some kind of VPN or direct access. I know there is a remote capability in CUCM now (including the use of a Cisco ASA) for hardphones, but I have not seen it put to use for the plug-in yet. Nor do I know if it's going to be possible.
But since you're not enabling enterprise voice you might be missing out on some great features in Lync. I'm not saying you can not implement all of these capabilities in Cisco's world. But for now, I consider Lync the fastest (and easiest?) all-in-one box you're going to get. Some might consider it a shame, not to make the best of it ;)

The solution in part 2 is much more flexible when you have to take travelling employees into account. And since you do enable enterprise voice in Lync, you will be able to use every feature available to you. The major drawback in this scenario is the lack of presence information shared between the systems.
These are my findings so far:
- If a call is made from PSTN to a subscriber, and it is answered in/by a CUCM device (or vice versa): There will be no presence update to Lync.
- If a call is made from PSTN to a subscriber, and it is answered in/by a Lync device: There will be a presence update to both systems (*1).
- If a call is made from Lync to the PSTN: Presence is set on Lync, but not visable to CUCM.
- If a call is made from Lync to a CUCM device: The CUCM will recognize the Lync as a "local" device (since the extension is registered as a destination), and the CUCM device will see this as a local call (as if it was a CUCM to CUCM call). Presence is set on both systems for the calling device, but only on CUCM for the called device.

Again, I really can't tell you which solution is the best for you. And who knows, maybe you end up implementing both solutions into your environment. Giving different groups of subscribers different options. I know I do all the time :)

Hope this post answers some of the questions I've seen regarding these posts.

Happy labbing!

(*1) By presence on CUCM, I am really talking about "busy line" status. Which in it's own way is a presence status.

See the other posts in this series for more info on CUCM and Lync:



Like this post

Comments

Anonymous said…
Great Post!! Well done man, this is quite explanatory.

I'm looking to deploy this and I'm still not sure which deployment model would be the best, either the solution described in Part 1 or part 2.

The customer is running CME in about 15 remote sites and they have Lync 2010. They're now however looking to deploy CUCM in the main office and conver the remote sites to SRST.

Since they're already using Lync quite well, I guess it would be important to have a discussion with them to ensure they don't lose any existing functionality they have in Lync that thy're already used to.

I guess I'll be back here to ask you some questions.
us vpn said…
I sure that a VPN or direct access would fix that problem also.
vpn service said…
Amazing post. Thank you for sharing.