Microsoft Lync Server 2010 with CUCM

Many of my customers already have an existing PBX in their environment, and do not necessarily want to swap entirely to MS Lync Server as the only telephony platform(or the previous OCS2007 R2). One way to implement Lync server with the enterprise voice feature for end users, is to make it co-exist with the already existing PBX. There are quit a few documents out there, describing such integrations. But I couldn't find any for my particular case. So here is my way of doing an integration between Lync and CUCM. First of all; Some of the customers are fairly small, and can not justify the investment in a full scale enterprise topology. They only want to keep to the minimum - Standard edition server. What's great about the Lync SE is the support of a co-located mediation server. And as long as the clients can have a direct ip connectivity to the gateway, and the gateway supports the media bypass (Cisco will refer to this as "media flow-around) you can get away with only one server (for internal purposes). To answer the important question; does CUCM support media bypass? Yes it does. At least in my lab. This guide is not a step by step guide, but a collection of settings on what I did to make it work. Refer to the documentation on exact steps to accomplish your task if you are inexperienced in any of the subjects. Here is the way I configured both the Lync server and the CUCM to make this happen: 1: In topology builder, add the CUCM ip-address as the gateway in your system (ps: make a note of ports and protocols in this view):

2: Enable Mediationserver co location on the Front end server, and point it to the gateway created in step 1 (ps: make a note of ports and protocols in this view) :

When these steps are completed, they need to be published to the Configuration store for tou to do anything more. The next steps are all done in the CSCP consol 3: Dialplan and Normalization Everybody needs a Dial-plan configures to make calls. In a small environment (such as my lab) you can get away with using the default "Global" Dial-plan. In this Dial-plan you must have normailzation rules (unless you expect everyone (I mean everyone and everything) to dial using the full e.164 format of +%countrycode%%extention%). I based my two normalization rules on the end-users dialing habits, and how I expect the called party to be displayed when coming from CUCM. (note: 0 is used as PSTN access code)

4: Voice policy, Pstn usage and routes, Now then, the following steps can be configured in different manners. But (again) in my simple deployment I decided to follow these steps. 4-1; Enable the Media Bypass in network configuration

4-2; Add a pool (or site) trunk to your configuration

4-3; Configure Media bypass on the trunk, and create translation patterns as needed. Why? Well, not all gateways will accept the + as an incoming number, ans in a large enterprise you might have different dialing rules in different locations. In my setup, I have made sure the called number (which is what we translate) is exactly identical to how numbers appear when users dial from the CUCM itself. This way, I will make use of the existing dialplan on the CUCM for outgoing calls, and only create a tiny translation pattern for call local to the PBX. == A minimum of configuration changes for CSS, PT's and TP's needed on CUCM when we get there)

4-4; Use the Global Voice Policy, and add a new PSTN Usage

4-5; In the PSTN usage, create a route (Note: I only need one route, as everything was previously normalized)

4-6; Point the rout to the PSTN gateway/Trunk

4-7; Test Voice routing in the CSCP, and verify that everything is acting the way you intended it to

5; Enable a user for Enterprise voice, and assign policies. Note that all the policies and usages are set to automatic in my scenario. They are set based on: - Some usages are global = as long as you are enabled, and no more specific rules are set they apply to you. - Some usages are based on site = in which site you belong (have not touched on site in this post) - Some settings are based on pool = which pool is your account logged in to

That's it for the Lync Server configuration. Now, let's head over to the CUCM. If you have been paying attention, you will soon realize Microsoft has changed default ports for the SIP signalling traffic. There used to be a "standard" using TCP 5060 or 5061 on sip-trunks. But as the Lync sever is growing ever more scalable and now supports multiple gateways, a limitation in just using 5060 and 5061 would soon create an issue in many environments.

In CUCM, the default listening port is 5060 for sip trunks and this does not at all match with the settings from figure 1. One way to fix this is to alter the configuration in figure 1 to match the CUCM of port 5060. The other way is to set up a sip profile on the CUCM side to match the incoming connection of TCP 5066, as shown here.

6: CREATE A NEW SIP TRUNK

Go to Device Trunk Add New to create a new SIP trunk with the following parameter settings (Figure 6):
Trunk Type = SIP Trunk Device Protocol = SIP

Figure 1

Configure the following parameters for the SIP trunk (Figure 1):
Device Pool = Default Media Resource Group List = None Media Termination Point = Checked. When this field is unchecked, the CCM sends SIP INVITEs to the UM server with no SDP in the offer. When checked, the SIP INVITEs contain SDP in the offer. The UM server supports both, Checked is required if there are Cisco SCCP phones connected to the PBX.

Figure 2

Continue: Configure the following parameters for the SIP trunk (Figure 2): Redirecting Diversion Header Delivery Inbound = Checked Calling Party Selection = Originator Redirecting Diversion Header Delivery Outbound = Checked Destination Address = IP Address of the UM Server Destination Port = 5060 when TLS is not used, or 5061 when TLS is used. Preferred Originating Codec = 711uLaw (default) SIP Profile = Standard SIP Profile (default) DTMF Signaling Method: No Preference (default). Using RFC2833 for this field should also work.

Figure 3

The standard SIP Profile is shown in Figure 3 and 4:

Figure 4

Figure 5

STEP 4: CREATE A NEW ROUTE PATTERN Go to Call Routing route/hunt route pattern Add New to create a new route pattern for the Exchange UM pilot number. Configure the following parameters (Figure 6 and 7): Route Pattern = Pilot number for Exchange UM. Gateway or Route List = Select. Route Option = Route this pattern. Calling Line ID Presentation = Allowed.

Figure 6

Figure 7