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

clip_image002

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

clip_image004

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

clip_image006

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

clip_image008

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

clip_image010

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

clip_image012

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

23 comments:

  1. Chris,

    In Scenario 5 to clarify myself, since you have inter site (branch site -data center link) CAC B/W policy define, hence Media dosen't flow through remote site SBS and to data center Cisco MTP to cisco phone is that correct ?

    Second question:- How do you create SIP trunk between CISCO gateway (isr router) and SBS server?

    ReplyDelete
  2. I like you questions and they are good ones. Firstly, it really depends on your routing for the branch site. I wanted to show the most effective way to route the call and show how to take advantage of CAC and RTAudio while calling the DC site from the remote. There are infact three different ways to route the calls. I could have routed over the driect SIP trunk from the SBS but this would mean using G.711 over the WAN link and no Lync CAC. It would also mean using a remote MTP which is much better to be used by local resources. I could have also routed out the PSTN gateway as well.

    Creating a SIP trunk from the CUCM subscriber to the SBS is very simlar to the DC mediation server but you need to define your Branch site first in topology builder. Then the PSTN gateway SBA and mediation Server configuration will appear within it. A PSTN gateway can be a CUCM subscriber. Obviously there are some control panel work in there as well with routes and Trunk configuration in the Lync Admin UI to get the right numbers to route out the trunk and enable media bypass.

    ReplyDelete
  3. My problem is trying to figure out really how CAC is going to work with this. We already have CAC on CUCM handling calls to/from all of its known and defined sites. With Lync and CAC, maybe Im a little fuzzy on how this will work. By looking at your post about CAC, we know its defined by subnet. If we use the scenario of SBA---SIP----ISR router... and calls *at this site* stay local, etc makes sense. Its fairly easy to setup Dial Peers and SIP end points on the ISR and point traffic to/from the SBA/Med server. Its when a Lync client goes to make a call to another Lync client elsewhere on the network outside of this site. You basically are managing two separate CAC enviroments... Lync and CUCM. From a network management perspective.. how is this going to be "fun" to manage?

    I see more and more companies wanting "hybrid" solutions of OCS/Lync voice end points, but keeping their Cisco/Avaya/Mitel phones around (with callmanager, Aura, etc). To me, the snap in clients to the MOC client are almost if not as good as what MSFT is offer today for voice. Granted, I have not tested the newer CUCIMOC or ACE modules, but I have heard the voice integration is to the MOC client is tightly bound to the client, where first versions did a poor job. (voice was fine, but integration to MOC was not). Using these snap in modules to MOC eliminates all the SBA gateways and CAC requirements for Lync, basically eliminating the need for Lync "voice" at all.

    I know the snapin modules are not the saving grace to all deployments... but from a voice management and routing perspective, it sure makes life easier. The end user may give up a Lync voice feature or two that possible a power user would miss, but the general OCS voice user probably not. (im guessing of course!)

    I love the options presented. I need to re-read it a couple times and digest your scenarios.

    ReplyDelete
  4. Chris,

    In CUCM world if we already have G.729 calls configured across two different sites. Now remote Lync client calls DC Cisco phone. If I decide to route through SBS -> local MTP -> DC Cisco phone (So No LYNC CAC enabled), would G.729 be applied in this scenario?

    Secondly, what i meant with SIP trunk to Cisco Router was not from Subscriber to SBS but from SRST router to SBS. How do I achieve this if CUCM is in SRST mode.

    ReplyDelete
  5. @Tommy
    So if you are making a Lync to Lync call you will be using Lync CAC. In saying that beyond the setup how much work do you really have with CAC, not that much. Maybe if you have a new site come online, which in Lync you could script and upload via a CSV file. Let me put it this way. By the time you test , deploy and maintain a plugin like CUCiMOC/CUCiLync (that is also on a completely different release schedule than the Lync client) you probably could have setup CAC and a simplified dial plan in Lync. The key to integrating these two environments is by keeping the Lync dial plan environment simple so once you set it up there isn’t to many changes to make. Seeing as you can build CAC environment in Lync completely with PowerShell it is not a huge task if you already have your subnet information at hand.

    To your second point about plugins. I would strongly argue against your voice was fine point along with the other points you made about the end user experience. Using plugins just doesn’t remove voice but also makes significant changes to the conferencing experience if you plan to use Lync for audio conferencing. I just recently had a company dump using a plugin to go to using native MOC voice features because the end user experience was terrible with the plugin versus using native features. For an IT person the experience with a plugin maybe acceptable but to most users it completely breaks the experience. Although I could harp on all day here about this in the end if the end user experience is bad because of a plugin the likely hood of uptake of its use is going to be low and it is not going to be seen as a replacement to a handset.

    Sometimes in life the easy answer isn’t always the best one. Sometimes, some work upfront can be the difference from a well-received deployment and one that falls flat on its face because of a poor end user experience. If you cant tell I am not a plugin fan:-)

    ReplyDelete
  6. @ anon,

    The only way it could be G.729 is if you have some local transcoders available as well on the Cisco side.

    Second question, SRST will control the phone registration not call routing which is controled by the dial peers on your router. Dial peers should still function as they would on a router during normal operation. But like I said it was a theroy that wasnt tested. This link from the Cisco support forum generally has the same answer. Although our case is a little different with trunk to trunk connections to Lync. The only thing that you would need to clarify is how SRST controls inbound routing to Phones and other trunks.

    https://supportforums.cisco.com/message/3069656

    ReplyDelete
  7. Since I am new to voice (Lync and OCS world) and not enough knowledge on cisco side hence throwing this question.

    In theory:-
    So even though in normal world, you will create SIP trunk from CUCM subsciber to SBS server in remote site, SRST router do get this config information stored in its memory (or in other words SRST router has the information about SIP trunk config/SBS server). So now during WAN outage, SRST router has this SIP trunk information and with router dial peer information would connect the call? Is my understanding correct?

    ReplyDelete
  8. @anon,

    Yes your understanding is correct. Unlike the SBA, SRST on the Cisco router is not centrally managed so this is one of the negatives here but it should function as you have suggested.

    ReplyDelete
  9. @Chris,@Tommy

    Just a thought want to share don't know if possible.

    If Organization is using CUCM and CUCM CAC, most likely they will also have Internal business number calling setup to route through WAN across sites.

    Now with Lync on top, what if we enable Lync CAC across sites but give B/W availablity as 0 and reroute all calls to PSTN, which in this case will be CUCM and CUCM should be able to route Lync to Lync calls across sites through WAN and can monitor using CUCM CAC.

    By Disabling Lync CAC, we will loose monitoring of Lync to Lync calls. Can the above thought be a workaround while in mixed mode?

    ReplyDelete
  10. @Anon,

    It could be a workaround but you would loose the ability to dynamically control codec selection across the WAN. Using Cisco CAC you would likely be stuck with G.711, unless you provision hardware transcoders at the site to do G.729.
    It coudl also limit your ability to reroute to the PSTN should you run out of bandwidth and end with blocked calls. So although it might seem like a good solution you would still need to provision Lync CAC to set it to 0 and not get any of the benifits it has to offer.

    ReplyDelete
  11. Hey Chris, can you confirm if media bypass works with an ISR for inbound calls? We're seeing outbound calls from Lync to the ISR work, but an inbound call generates an error in the Lync client and the user cannot pick up or decline the call. Any tweaks that would allow inbound calls to work? No encryption in play here.

    ReplyDelete
  12. Hmmm. I can neither confirm or deny any issues I have seen since the testing I have been privy to was by someone else and they confimed success both inbound and outbound. An error generated by the Lync client besides not being very descriptive also doesnt indicate to me that media bypass is the issue. The first step I would take is to turn off media bypass to eliminate it as the issue and capture any errors generated.

    ReplyDelete
  13. Yeah, media bypass definitely seems to be the issue. As soon as we disable it the inbound calls work just fine. The Lync client says: An error occurred. When contacting your support team, reference error ID 87 (source ID 7).

    A client-side snooper trace shows a SIP 500 Server Internal Error message:
    User-Agent: UCCAPI/4.0.7577.0 OC/4.0.7577.0 (Microsoft Lync 2010)
    ms-client-diagnostics: 52001;reason="Client side general processing error."

    ReplyDelete
  14. Seems odd it would work one way and not the other. If media bypass wasnt going to work I would assume outbound would also be broken. You could try changing your ISR IOS version on your router with version that was recommended for OCS R2 or a later version of that same code. Also check the codec that the ISR is offering up to make sure its Lync supported. Since there is no current support or documentation its a hard one to point to specific issues. Hopefully over the next few months this should change.

    ReplyDelete
  15. Hi Chris,

    If Sip trunk is configured from Cisco ISR router to SBS and we are in mixed mode. User's don't want to change their DID which means we will have random DID in Lync and random DID for Cisco. What I mean by random is Lync users DID are not in block.

    So in dial peer I will have to specify each number correct as there is no block of numbers to Lync?

    Secondly, currently we are using dummy digit route pattern for inbound to work for OCS R2. So all DID's are handled by Cisco, We then create Directory number on CUCM and forward it to dummy number range which is a Route pattern to OCS Mediation Server. We are planning to apply same logic with Lync...Can the dummy route pattern be configured on ISR router with Lync?

    ReplyDelete
  16. I am putting a few questions I have recieved in comments together to have a blog post on it. Look for it over the next few weeks.

    Quick Answer:
    So there is an easy way to route numbers to Lync and CUCM with both sharing the same number block using hunt groups configured on the gateway dial peers.

    Not sure the reason of your second point and what you are trying to acheive since CUCM can route the DID block to Lync even when there phones registered in CUCM from that number block. If you can expand on why you are doing this I can probably address this better.

    Cheers
    Chris

    ReplyDelete
  17. Thanks for your comments.
    For second point, basically the concern is in SRST mode. How can I make inbound working to Lync when in SRST mode, if the DID used are not in block.

    ReplyDelete
  18. So if you have a remote site where you have a DID block that is shared across Lync and the SRST router you could potentially have this work. Although I was unable to track down the exact call processing method used in SRST going by some reading I did on this blog post http://www.netcraftsmen.net/component/content/article/70-unified-communications/802-redirecting-called-numbers-in-srst-the-alias-command-and-hairpin-methods.html

    the method for call routing seems to be match registered ephone first then route using dial peers which means any unregistered DID could be routed to Lync. I havent tested this but it makes sense according to the testing used for hairpinning mentioned in this blog post.

    One thing to be aware of is any commands that are used for SRST to change inbound numbers to match abbreviated dialing will need to be mathed on dial peers as well that pass calls to Lync.

    ReplyDelete
  19. Chris,

    We are having CUCM and SRST routers with MGCP controlled gateways at branch location.

    In OCS R2, when we build Mediation server, we usually define next hop as CUCM IP address at Data center and at Branch location.

    Where as in Lync, I can no longer give CUCM IP address at 2 different sites.
    in Lync Topology, at DC, I say PSTN gateway is CUCM IP address but at Branch site, I cannot give CUCM IP address.

    So question, is which IP address I should configure at Brach site PSTN gateway? IP address of gateway router where MTP's are configured? Will gateway router support early media?

    ReplyDelete
  20. We will be in a little different scenario possible. All of our remote offices are running Cisco Call Manager Express whcih Cisco phones and currently a very old version of Cisco Unity.

    Our corporate office is running a old Nortel switch which is using Cisco Unity for voice mail as well. There is a big debate between staying with Cisco for the new corp phone system or using Lync voice since we will be deploying Lync anyway for the other features.

    So its possible we will end up with Lync @ Corporate for voice and CME out at the remote offices although the users will have Lync clients for the other functionality.

    Voice mail with either be Cisco or Exchange 2010 UM. We do have some basic requirements that voice calls cannot go across the heavily utilized WAN links put Voice mail processing can. At the remote sites full VM functionality must continue to work if the WAN is down.

    This really brings me down to two broad questions.

    1. Can we get any type of integration between the remote offices Lync clients and their local Cisco phones? Many of the users in these offices would benefit from the soft phone funcitons of Lync since they travel a lot.

    2. What will be the WAN down experience for the Cisco users connecting to the Exch 2010 UM back @ corporate. What pieces need to be in place to make this work over PSTN?

    One other question. If we end up going Cisco across the enterprise for voice what the best non-Cookielync integration we could expect between Lync and the Cisco phones?

    Thanks

    Robert

    ReplyDelete
  21. Hi Robert,

    Answers:
    1. Yes you can integrate Cisco CME with Lync with either the SBA/SBS or a mediation server with a direct SIP trunk from your CME to Lync. Having the expectation of sharing the same number between the two environments is not really all that realistic and you will most likely have users having two different numbers if they want a Cisco hard phone and Lync Softphone. Sometimes this can be worked around by having slight variations of the same number (4 digit extsion on Cisco phone full E164 for Lync as an example) but that is a pain to deal with. Certainly having both ring at the same time will probably not be possible with CME unlike CUCM or Lync which could possibly do that. So my best advice is make users make a choice. Softphone (Lync) or hard phone (Cisco CME) in this case.

    2. Looking at the Cisco CME configuration you would need a second PSTN dial peer configured with a higher preference for when your WAN is down. I haven’t tested this myself but it seems possible to still provide voicemail for Cisco IP phones during an outage with Exchange UM.
    so

    dial-peer voice 550 voip
    description ** Exchange Unified Messaging **
    destination-pattern 550
    session protocol sipv2
    session target ipv4:192.168.10.4
    session transport tcp
    dtmf-relay rtp-nte
    codec g711ulaw
    fax rate disable
    fax protocol pass-through g711ulaw
    no vad
    !
    dial-peer voice 551 voip
    description ** Exchange Unified Messaging **
    destination-pattern 550
    port 1/0/0
    preference 2
    !
    telephony-service
    voicemail 550

    This is a simple example but setting the preference should allow the call to be pushed out over the PSTN when the WAN is down. Obviously there will be no MWI but at least they will reach the UM server.

    This link should help with the initial setup
    http://www.aaronhall.net/cisco-cme-exchange-unified-messaging.html

    3. In this case Lync can be setup as another subtending PBX off of CUCM with full integration for voice using direct SIP between both environments. Depending on your Voicemail choice (in this case Exchange UM is a easy choice as it can service both) you configuration can be a little different. RCC is a bit different and I am only referring to voice integration not controlling desktop phones.

    Cheers
    Chris

    ReplyDelete
  22. you have done a realy a great work and informatic,i am trying to implement voip in our company.
    Thanks
    http://20best.net

    ReplyDelete
  23. You have done a realy a great work and informatic,i am trying to implement voip in our company.
    Thanks

    ReplyDelete

Note: Only a member of this blog may post a comment.