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 4 (what a mess my lab is...?)

I didn't think I was going to write more posts on this subject, but I was obviously wrong. I've read through all of the comments on my posts (and some in my mailbox and on twitter), and have tried to answer all of them to the best of my knowledge. (And keep on answer if questions come in)

After a few more months of experience, and a couple of customer implementations in the "bank", I have opened my eyes for a third option for your coexistence. This time I'm trying out RCC through the Cisco Presence server. And to my surprise, I think this might be the best option for users who do not need to have enterprise voice when they're not in their office.

RCC through Cisco presence will give the user the best of two worlds:
- All of Lync integration options for Outlook and exchange
- Direct control of your Cisco IP Phone through click to dial
- Answer your phone through Lync
- Phone status update to the Lync client (when logged into lync)

I am not going to write a big how-to with screen-shots all, as I found the Cisco documentation very well written, but I am going to write a few pointer you might find helpful.

Here are a few things that will help you understand, and hopefully implement a RCC integration successfully.

About domain names: The Lync SIP address and the presence SIP address must be different, as you create an application server and routes to the application in Lync. This was a hassle in older versions of Presence and OCS, but in Lync we specify the Presence server name as the route to macth (and not only the domain, which would be in conflict with the Lync sip address).

About certificates and security: I skipped the entire section 8 and 9 of the document, and made it work without the security. I would recommend doing the security for a live environment, but for a lab it's not necessary at all.

About the plugin in section 10: This plugin will give the user some enhanced experience of the integration, but it's really not needed for the basic functionality.

About configuring the user in Lync: Of the different ways of configuring the Lync user, I have found the following string to be the best:
tel:xxxx;phone-context=dialstring;device=SEP0002FD3BB5C as it leaves out any issue with shared lines in CUCM

About authentication: There are several ways you can authenticate to the presence server, but here is what I found is an easy option:
- Make sure the user's email address and sip address is the same
- Integrate your CUCM (and presence) with your active directory
- Have your CUCM synchronize the email address.
This way, the email address will be what the RCC will use for authentication.
(I say this, because I've seen a lot of implementations where sign in name may differ in the two worlds :)

About topology: Here is the most important bit of information. Read the Cisco doc carefully, and you'll notice the application server you create is created with the ip-address of 0.0.0.0. The RCC will not work with the "all ip-addresses" as this address represents. You must enter the ip-address of the cup server. Follow the simple instruction in the doc, and you'll be good to go. miss it, and you'll fail.... (as I did at my first attempt).

I hope this post may be of help to you in your labs. I might create a how-to, with screen shots, if there is any interest for it at a later point. (But if you google it, there are several out there already).

Comments

Amir said…
Would it be possible to setup RCC and have a soft phone too?
That I haven't tested, but as far as I know, the Lync doesn't really know what device it is controlling, so it should be possible.
Niclas Strøm said…
how can you confirm that you have access both way from the cups and lync?
Niclas Strøm said…
How can you check that both lync and cisco callmanager are connected to each other
Hi Niclas,

A good question. There is no service panel og control applet to verify all of this in. The best indication is done by logging into Lync, and try to make a call. Or, call the user configured with rcc. It should signal the Lync client right away.
Anonymous said…
This is very helpful. I'm up against a similar challenge. I'm the Manager of Network Engineering for a very large distribution network company. We made an acquisition of another company and the scenario is as follows.

Voice
My Company: Cisco CUCM 8.6
Bought Company: Microsoft Lync 2010

IM(Presence)
My Company: Microsoft OCS 2005
Bought Company: Microsoft Lync 2010

Task: "Integrate" voice and presence systems.

In your scenario, I'm assuming that the Lync enviornment and the CUCM environment reside on the same network. My challenge comes in trying to accomplish this same task, but with the systems on two different networks that currently do not connect to each other in any way. To add insult to injury, the two phone systems IP subnets overlap. The only way to address this that I have found thus far is for one of the phone systems to re-address their subnets (no small task by any means). I came up with the idea of renumbering our phone system to a subnett that does not overlap with any networks involved in this integration effort. Then create a VPN tunnel between the two environments. And finally create a SIP trunk between CUCM and Lync.

Do you, or does anyone reading this thread know of any other way to accomplish this? ANY and all input is greatly appreciated as I'm running out of time to provide a clear and precise solution.


Thanks for your time and for reading this.
Hi,

I would urge you to change the address scheme to one without overlap. It's just that more easy to maintain in the long run.

A VPN tunnell of some sort would seem like the appropriate way to solve some of your issues. And is necessary if you want to accomplish a direct SIP trunk calling scenario.

You might keep in mind how to handle possible media bypass (or not), and remember to turn of REFER support in between CUCM and Lync.

The OCS 2005 is way outdated, and I woul reccomend you to either replace your 2005 with a Lync deployment, or, if possible, move your users from 2005 to Lync (but there are no migration tools for this task).
BrokenSword4 said…
Good morning,

I'm a french studient trying to list : what are the best ways to implement Lync Server and CUCM ? And at the end if the integration is interesting for my enterprise without changing everythin because they have CUCM and CUPS and CUPC.

So after a month of research I found one thing that would be the best.
The integration with Cisco Unified Presence Server with RCC.

I have 2 questions about that :

1) if you use RCC, when calling from Lync, the callee will answer and the caller have to hookup his Cisco Phone to take the call.

Can The Lync Caller make a call from lync client with a microphone ?

2) If the user is outside the compagny with a VPN connection; and his Iphone connected by VPN too and associated with CUCM.

If the user make a call with Lync, and his account his associated with the Iphone, is this possible that instead of hook-up his cisco phone he hook-up the Iphone ?

I hope it's not written in a too bad English !

Thank for reading this.
Hi BrokenSword4,

When using RCC, you have two options.
1) You turn off AV in Lync completely, to spare users of the confusion of where to pick up the call.
With RCC turned off, all the AV is kept within the CUCM environment. When you answer the call in Lync, it is the Cisco phone which goes off hook.

2) You leave AV in Lync enabled. Then the users can make both Cisco calls (with RCC) or Lync calls (Pc-toPC). This last setting will sometimes confuse users.

regarding your VPN scenario. This is where RCC might be a drawback. Even though the user is remote, he will still se the signalling of his Cisco phone. But when answering that call, it will be the Cisco phone which is answering, and not the Lync client.

I have found the best way of configuring the Lync RCC is by hardcoding the SEP address on the Lync user. Whit this setting, you would not be able to pick up the call on your iPhone with Lync (Unless it's the iPhone address configured as the RCC).

You are not requiered to enter the SEP address on the Lync user. And it could be possible to make it work with you iPhone. But how would Lync know which device to terminate the call to. I am not sure it would be a good solution.

You could, however, use a the CUP client as a softphone, and register this as your RCC device. Then, your scenario would work.
BrokenSword4 said…
Good afternoon,
Thank you for this answer.

I think that the 2) option would be the best.
This integration will be in an IT compagny, so users can easily understand I think.

"But when answering that call, it will be the Cisco phone which is answering, and not the Lync client."
I don't understand that, because you said a the beginning of the topic:
"Answer your phone through Lync". Does it mean that when you receive a call, you cannot answer from Lync ?

I have found the best way of configuring the Lync RCC is by hardcoding the SEP address on the Lync user. Whit this setting, you would not be able to pick up the call on your iPhone with Lync (Unless it's the iPhone address configured as the RCC).

With the Cisco RCC plugin I have read that you can choose one of all remote device associated with user account in CUCM.
In that way, if the Iphone is connected by VPN, when calling from Lync, the call will be forward to the Iphone ?

I think that using CUP Client as softphone would be confusing for users and also more expensive.

Thank you for your time.
brokensword4 said…
Good afternoon,
Thank you for this answer.

I think that the 2) option would be the best.
This integration will be in an IT compagny, so users can easily understand I think.

"But when answering that call, it will be the Cisco phone which is answering, and not the Lync client."
I don't understand that, because you said a the beginning of the topic:

"Answer your phone through Lync". Does it mean that when you receive a call, you cannot answer from Lync ?

I have found the best way of configuring the Lync RCC is by hardcoding the SEP address on the Lync user. Whit this setting, you would not be able to pick up the call on your iPhone with Lync (Unless it's the iPhone address configured as the RCC).

With the Cisco RCC plugin I have read that you can choose one of all remote device associated with user account in CUCM.
In that way, if the Iphone is connected by VPN, when calling from Lync, the call will be forward to the Iphone ?

I think that using CUP Client as softphone would be confusing for users and also more expensive.

Thank you for your time.
Hi Again,
RCC stands for remote call control. With this, you will control your Cisco device with Lync. Signalling to the Cisco device will also signal the Lync client.

But clicking "answer" on the Lync client will make the Cisco device go off hook. There will be no audio in Lync with RCC.

When calling from Lync, if you choose option 2, the end user must make a conscious decision on what to call with: RCC- Cisco device (PSTN) or Lync call (PC to PC only, and you cannot reach PSTN or Cisco devices this way). Which is one of the reasons I personally think option two is not a good option.

When using RCC, there will be no forwarding from Lync to a Cisco device. All the call handling is done in CUCM (and it is the CUCM, through CUPS, which is signalling Lync).

I hope this was clarifying.
BrokenSword4 said…
Good Morning,

Thank you for your answer, it's clearer now.
Finally I think that it's not a really good idea and investment trying to implement an integration of Lync solution and cisco Unified Communication.

This blog really helps me in my research and I'm sure it will do it for others for a long time.

Have a nice day
Anonymous said…
Have you tried video call with Lync client when RCC is enabled? Is it possible?

Thanks.
Best Practice is to disable A/V when using RCC. So a video call from Lync to that user would fail. A video call from Cisco to that user would work, but not through Lync. You would nedd Cisco Software to handle the video call as well as the audio.

Video between Cisco and Lync (When enabled), should be done through a VCS or similar device.
Sergey said…
Hi Lasse,

In your lab testing or at customer, did you have an issue with Calling name mapping to the user for the incoming call when DNs in CUCM are NOT in E164 format?

My CUCM extensions are 4 digits - say 1001, the telephone number attribute in Active Directory for the user is provisioned with full E164 number for that extension - say +16178631001. I have configured address book rules and tested they work:
1001 -> tel:+16178631001
Matching Rule in Company_Phone_Number_Normalization_Rules.txt on line 22
^(\d{4})$

Address book on the client is updated and normalization rules are in the registry.

Nevertheless, when the call comes in, it is displayed as coming from 1001, rather than the user name. If I normalize to E164 on the CUCM, then the user name is matched on the for the incoming call. It almost seems like Lync client doesn't do address book normalization before lookup.

Did you encounter this issue?

Sergey
Hi Sergey,
I believe I did. As far as I understand, the address book normalization only applies to the generation of the address book itself, not live normalization of incoming numbers.
My solution to this, is to have both systems use the fully E.164 format. Not by having CUCM endpoints have the E.164 number, but rather fully normalize and globalize the numbers when crossing the CUCM "barrier".

There is however, one more thing you could try, and that is to add a normalization rule for the user's dial plan (in Lync Controlpanel), and mark it as "internal". I believe that would fix your issue.

Kind regards,
Lasse
Sergey said…
Thanks Lasse!

Globalizing number to E.164 when crossing CUCM "barrier" would be ideal, but the problem is that in RCC scenario that "barrier" is CUPS and I couldn't find anything in CUPS which would normalize number to E.164.

I've tried dial plan normalization rules on Lync, but they didn't work and my understanding is that they only apply to Enterprise Voice calls.

I've tried playing with Calling Party Normalization on CUCM by globalizing the calling number first to E.164 and then localizing it on the phone, so I actually both E.164 and extention number in the calls directory. I was hoping that CUPS will report the E.164 number, but that didn't happen. It appears that CTI reports to CUPS whatever is displayed on the phone and CUPS just passes it along.

Anyway, thanks for your posts and response to my comments!

Sergey