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
UCM 4.2 2000-4-4a
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.
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?
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.
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.