Cisco and Microsoft Lync Interoperability

So far there has not been an official release on Cisco and Microsoft Lync interoperability from either company. As things get spun up in the labs and official testing begins there has been some talk at TechEd and other events on what this could look like. I have also been working with customers and partners that have set up integration in their labs. In this post I am going to describe some scenarios and currently unsupported configurations that people could stand up in their labs to start testing. Even though the scenarios I am going to outline do in fact work, no support statement or interoperability documentation is available yet but I expect to see it in the coming months.

Similar to OCS R2 interoperability with Cisco Unified Communications Manager for direct SIP, Lync will still require MTP’s (media termination points). Sometime ago I wrote about using OCS R2 with Cisco deployments utilizing MTP resources. This really wont change all that much. You will more than likely need MTP’s for direct SIP. If you have a mixed environment it’s going to make sense to still have local MTP resources at the branch but there will be some things that you can do that will lower their use and improve media flows. The reason that this is possible is because the Mediation Server role now allows media bypass teamed with a 1:many ratio for Mediation Servers and PSTN gateways (Cisco ISR).

The Survivable Branch Appliance/ Server is a really handy device. Beyond just survivability for Lync clients in the branch its now opens up a great deal of options for trunking between your Cisco and Microsoft environments. The SBA/SBS is a enhanced SIP registrar along with a Mediation server. So along with survivability it now has new trunking abilities which make it a very flexible device both in the appliance and server format.

Many large enterprises have investments in Cisco for their enterprise voice gateway platform. So making a change to one of the supported SBA partners for Lync is not somewhere that all enterprises are willing to go. Fair enough, but what options can be achieved. What I have seen to date is (even though it is not certified) Lync can use a Cisco gateway as a voice gateway but with some caveats around SRTP, Media Bypass and MGCP.

-SRTP between Lync and Cisco’s ISR platform is not compatible. Even if it were, loading certificates and setting up an ISR to do SRTP is not what I call simple the first time around and a lot of enterprises may not care about using SRTP anyway. In fact most organizations do not use encryption in there CUCM deployments so this probably isn't a big deal.

-Media bypass requires changes to set the Lync client from required encryption to support when using the Cisco ISR platform. This can be done with PowerShell CMD that I have previously documented here and it’s a one line command. Pretty simple.

-MGCP. Since the signaling traffic is backhauled to the CUCM subscriber the router loses its ability to segment a T1 and provide the ability to breakout traffic at the router. So once you enable a T1 for MGCP you will need an alternate way to get your traffic to your Lync users via a SIP trunk from the subscriber. Using SIP you could potential send inbound calls directly to the SBS and eliminate some complex routing and lower MTP use. MGCP has its pluses and minus. In a mixed environment where you may want direct trunking to your Cisco voice gateways from the SBS it limits your choices. Lucky when a WAN failure takes place the router fails back to SRST and h323 by default freeing MGCP’s grip on the routers resources, so that may bring some solace.

That being said, dual environments usually come about because of a preexisting Cisco IPT environment and introducing Lync on top of it to add UC. This is very common. Below I have outlined what this could look like with Lync. This deployment example is about maximum use of resources with multiple routes for fail over between the two environments. This setup will allow Lync to be used for conferencing and softphone (or IP standalone hard phone if your plan is to eventually replace Cisco) deployments alongside you existing Cisco environment. Now you could make this deployment much simpler and sometimes simpler is better but this diagram is about showing you full options.

Figure 1: The Setup

I think it’s important to point out a few differences between the SBA and SRST. Cisco and Microsoft have different approaches here and I am not saying one is better than another; they are just inherently different in the way that the branch is designed which is important to understand. Firstly the SBA is the primary registrar for remote clients in Lync. SRST on the other hand functions in the opposite way with the Cisco SRST router being more of the secondary registrar only being used in the case of a WAN failure. This means all signaling traffic for a SCCP or SIP Cisco IP phone flows back to the central site when the WAN is available. The SBA/SBS on the other hand can handle call routing locally when the WAN is or is not available. The SBA dial plan is also centrally managed, SRST on the other hand requires some configuration on the router for failback mode whether your phones are using SCCP or SIP. Even though I have shown my diagram using SCCP for the phone signaling it could just as easily be SIP.

Cisco is not a SBA partner and does not currently support the SBA in their Cisco router platform. Therefore it does require a separate SBS server to accommodate remote Lync clients in the branch if disaster recovery is a requirement when using Cisco ISR gateways. If DR is not required you can do away with having any device or appliance in the branch and just have a Cisco gateway.

With that said, I have drawn the CUCM cluster with a SIP trunk to the SBS in the branch along with a direct SIP trunk from the SBA to the gateway. This adds some redundancy and efficiencies which I will get to in following diagrams.

Figure 2: Local inbound and outbound Lync calling- Direct to Cisco gateway

Figure 2 is one of the efficiencies I was talking about. Combining the ability to do Media-Bypass, Enhanced Registrar and the Mediation Server role of the SBS direct routing to the Cisco Gateway is greatly simplified. As well as the ability to do translations on the Mediation server in case E.164 is not part of your current Cisco design. In this case direct inbound and outbound calls from Lync Clients registered with the SBS can go directly to the Cisco router using G.711. This is a key scenario if you desire local DID access for Lync clients at remote sites.

Figure 3: Local inbound and outbound Lync calling- Remote Lync Client to Remote Cisco IP phone

Figure 3 shows how using a direct SIP trunk from the CUCM to the SBS makes a lot of sense. In this scenario I am able to dedicate MTP resources just for the purposes of SIP trunking between the two environments. Ideally you want local MTP resources to remove the need to trombone media streams over the WAN. You will also notice the media stream is direct between the Lync client and the MTP using G.711. Unlike the SBS the SRST router is not actively processing calls until a WAN outage so the Cisco IP phone will ship call signaling back to the CUCM subscriber.

Figure 4: Local inbound and outbound Lync calling- Central Lync Client to Central Cisco IP phone

Figure 4 is really pretty simple. Using the collocated Mediation Server on the SE or EE Pool we can have direct media between the MTP and Lync client using G.711 codec and Sip trunking between the two environments. Any number translations required could occur on the collocated Mediation Server before entering the Cisco environment.

Figure 5: Remote Lync Client to Central Cisco IP phone with no Media Bypass

Figure 5 now becomes a little tricky depending on call routing for Remote users. You obviously have two options for call routing. Firstly you could route locally across the SIP trunk between the SBS and the CUCM deployment but I have chosen to take a slightly different route utilizing central resources and using RTAudio over the WAN with CAC and to conserve bandwidth with RTAudio back to the central site. I could use Media Bypass for PSTN/Cisco calls but this would limit CAC and reroute over the PSTN options should my WAN overloaded.

Figure 6: Remote Lync Client to Remote Cisco IP phone with Media Bypass During WAN outage

Figure 6 is an untested theory I have about the ability to have the two environments talk to one another during a WAN outage. The Cisco router along with providing registration when in SRST mode for Cisco IP phones should also be able to make SIP-SIP or SIP-H323 functionality enabling the isolated branch to continue processing internal calls. The only caveat I would consider is that this will require media to flow through the Cisco ISR. Like I said this is an untested theory. Feel free to give it a try.

Comments welcomed.

VoIPNorm