Voice Migration Strategies: CUCM to Lync

This is a common topic that I get really excited about because there some great options with Lync. If you haven’t already seen the Lync OIP interoperability page, CUCM has direct SIP IP-PBX support. Versions 4.2, 6.1 and 7.1 are now supported for direct SIP interoperability.See the excerpt from the page below:


Cisco Unified Communications Manager

Direct SIP

UCM 4.2 2000-4-4a

Configuration Notes:

1. On the Cisco IP-PBX, configure MTP to enabled and PRACK to disabled (the default for PRACK). The PRACK message sent by CUCM 4 is malformed by missing the MAXFORWARDS header.

2. On Lync Mediation Server, Media Bypass is set to enabled. RTCP and REFER are set to disabled, as Cisco doesn't send RTCP messages and REFER is not supported by this IP-PBX.

Known Limitations:

1. When a Lync user transfers a PBX call to another PBX user, the local PBX phone will still show connected to the first Lync user.

2. Comfort noise generation is not supported. As a result, comfort noise is not played on Microsoft Lync.

3. When a Lync user configures call forward or simul-ring to a PSTN IVR number, the calling party will not hear early media played from the IVR.

Back in 2009 I wrote about a similar topic with OCS R2. There have been four very significant changes in Lync that make migrations and interoperability less challenging compared to my original OCS post . They are

1. Media Bypass,

2. outbound number translation on the mediation server,

3. 1: many Mediation Server to gateways and

4. Mediation Server collocation.

Both the scenarios outlined below can take advantage of these features. Not only will you lower your server count because of these changes but it will also lower the amount of changes required to a CUCM dial plan. All-round these are great improvements.

So what migration or interoperability scenarios does Lync present?

Scenario 1


Pretty straight forward. Direct SIP from Lync to CUCM with media Bypass to the MTP. This is really a starting point for most organizations. Establishing the Lync deployment as a subtending PBX is a good way to get the Lync migration underway. CUCM has the capability to allow a combination of Single Number Reach to a Lync client to ring both the Cisco handset at the same time as well as the Lync client or in the case where the user no longer requires a Cisco handset port the DID to Lync. If you port the DID to Lync, CUCM becomes a tandem PBX being used for traffic management rather than endpoint termination.

Scenario 2


Seems like a simple step but adding a direct SIP trunk from the gateway to Lync once you have a numbers of users taking advantage of Enterprise Voice can make interoperability a little easier. A user could also use Sim Ring from Lync to ring a Cisco Phone with having the call trombone from CUCM to Lync then back to CUCM to ring the Cisco IP Handset. Call it a substitute to using Cisco’s Single Number Reach feature in CUCM which some see as a complex feature to setup.

This allows calls from the PSTN direct access to the Lync conferencing service rather than going through CUCM. My theory is the less you have transition through other systems the easier interoperability becomes. In this case you can really start to treat the trunk between CUCM and Lync as a simple tie trunk for interoffice calls rather putting every call through CUCM to get to Lync.

In the case of the ISR shown in the diagram you can use dial peers placed into a hunt group to route calls from the gateway. The caveat here is that Lync has to have the highest priority for it to work effectively otherwise the calls will still all be routed via CUCM unless there is a CUCM failure.

If you haven’t already noticed I am trying to avoid any IP-IP GW/CUBE functionality as this will add to your overall cost due to CUBE licensing. Although this feature has its place, interoperability with direct SIP between these platforms does not require the use of the CUBE feature. I have seen instances where companies have been told using a gateway with CUBE is the best way to achieve CUCM interoperability. This is not true.

For more information on interoperability check this post here. I also talk more about branch interoperability in my previous post.

Comments welcomed.



  1. Hi Chris, can you elaborate more on the CUBE interop argument? I'm not familiar with it or why you would need it. Here at our company we have a CUCM instance with Direct SIP to Lync Server 2010 and it works great....not sure why you would need anything else.

  2. I have heard of recommendation to customers (not by MS or its partners) where they have been told to do interop they need a CUBE. Basically trying to sell more boxes and trying to create a level of mistrust I think. Also I have some old posts that describe using the CUBE function. This was a handy design for older version of CUCM and OCS but not really required any more.

  3. hi Chris, you wrote "or in the case where the user no longer requires a Cisco handset port the DID to Lync. If you port the DID to Lync, CUCM becomes a tandem PBX being used for traffic management rather than endpoint termination." Can you elaborate on how one'd go about "porting" the DID to Lync? I mean, the PSTN PRI circuit is still terminated to the Cisco ISR gateway that is connected _only_ to the CUCM (in scenario 1). Thanks a ton in advance!

    1. Hi Chuck,

      You would need a route pattern point to the right route group that contained the SIP trunk going to Lync. once you removed the line number from CUCM, CUCm will do a route pattern lookup adn send the call onto Lync. once you have the right routing in place this is not to hard to do.



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