Updated: CUCM SIP URI Dialing to Lync 2013–Adding Cisco Expressway for Video

I created the original post for this configuration back in July 2012 and its seen quite a bit of traffic and had some great comments. I just thought with the release of Lync 2013 and some new interesting developments it would be worth adding new info and refreshing some of the content to better speak to Lync 2013.

I have recently added community fixes to issues that have arisen so this post is certainly worth a revisit when I make updates. Please continue to comment and make suggestions. I know quite a few companies are now using this configuration based on this blog post so keep the info and questions coming and I will keep updating.

What's this post all about?

I have seen quite a bit of using Cisco’s mobility feature to dual ring a Cisco phone and Lync. There is an interesting feature in CUCM that could make your life easier. Its called SIP URI dialing. This isn't a new feature as its been around since 7.x days or possibly earlier. It sparked my interest back in 2008 but I never really investigated it further until 2012.

SIP URI dialing is really a pretty basic concept. Instead of using a normal DID route pattern to designate a destination you use a SIP URI such as lyncuser1@contoso.com. By specifying @contoso.com as your SIP route you assign a SIP trunk that points to Lync. Its actually pretty simple and works with Cisco’s mobility feature used in Remote Destination Profiles.

There are some caveats with this feature though and its not terribly flexible. It does require some special configuration but could possibly make dial plans and  interoperability a little easier. Also you can remove the issue of requiring unique DID’s on both systems because now that your ringing between systems with a unique SIP URI using the same DID on both systems is much less problematic. So users don’t have to change numbers or use a new number for Lync, it can be the same as their Cisco IP phone.

To make things a little easier to understand, in this post I am referencing the To field in a SIP message when I am talking about Tel URI or SIP URI. I am using Tel or SIP to define trunk routing behavior even though both are configured as SIP trunks when configured in CUCM. Its just the routing behavior based on the address format I am trying to better define. Hope that’s not to confusing.

Why use it?

While working in the field I get a lot of questions from engineers around how do I make my Cisco phone and Lync ring at the same time. As I have covered here on my blog there are a couple of ways to do this from either CUCM, Lync or even potentially from a gateway. But there is a level complexity in regards to how to configure DID’s and how to make DID’s unique enough so that you can route between the two platforms. Well using SIP URI dialing instead of DID’s this simplifies this portion of the configuration and leaves Lync’s Sim Ring feature open for users to configure it for their cell phones. Using Sim Ring as the tool to ring a Cisco desk phone in my opinion is a waste of an easy to configure end user setting. I strongly believe this feature is better used to ring a cell phone or other devices self administered by the user.

The interface for configuring Cisco Remote Destination Profiles is potentially very intimidating for normal users. There are settings and timers that if set incorrectly can cause issues. That’s why in my opinion RDP’s should be configured by an administrator and Sim Ring on Lync is a better choice for self service by the average user. There is only one timer and phone number fields can be prepopulated making the users phone number selection easy. Also Sim Ring has the ability to use the business hours set in Outlook where as Cisco’s RDP requires this to be recreated under the RDP profile. If your using RDP’s for more than just ringing Lync this might be handy.

image

From a self service point of view Lync allows the user to set Sim Ring and Business hours which are inherent in Outlook straight from within Lync. Timers for voicemail forwarding are available but other timers are system controlled and not exposed to users removing the potential to create issues. Sim Ring can also be changed by the user from all the mobile apps.

image

image

RDP’s although not overly end user friendly can be used in different ways to help integrate Lync into your preexisting environment. It can ring up to 5 endpoints. RDP could also be used as way to keep voicemail in a different voicemail messaging platform other than Exchange UM for Lync users but still allow a user to have Lync as a softphone. This might be important for companies that do want voicemail in email for compliance reasons etc. So RDP has some great uses for working around common issues.

Caveats for SIP URI dialing?

The single biggest caveat for SIP URI dialing is that when you create a SIP Route pattern in CUCM it does not allow assigning a route group to it. You have to directly assign a trunk to the route pattern. The main issue is that once assigned to the SIP route pattern you can no longer assign the same trunk to a route group which limits your options. The best way to deal with this is to have a SIP trunk just for SIP URI routing. In CUCM 8.6 you can have multiple endpoints (in our case mediation servers) assigned within a SIP trunk which means that this isn't a redundancy problem. Its more a configuration issue on the CUCM side but since this configuration is for a specific purpose I don’t consider this a show stopper.

With Lync 2013 this trunk can now have its own port within the Lync trunk configuration. This means we can create a trunk with its own rules on either system. It really doesn’t mean that its simpler but certainly more configurable from a call control point of view.

How to set it up?

The easiest way to do the setup is to follow this guide with a few alteration which I will call out below. This is the Microsoft produced guide. In the Microsoft guide they make use of Calling Search Spaces (CSS) which gives a more complete picture of the settings required. In the Cisco guide there is no call authorization setup so unless you know which CSS to configure you could easily miss a setting as there are multiple places to set CSS on various pages. The one that caught me out was the rerouting CSS on the Remote Destination Profile.

image

What's needed for Lync?

The SIP URI trunk is for inbound use only. This means that setup on the Lync Server is pretty simple if you already have a SIP trunk setup for your CUCM deployment. As long as your CUCM servers are already added to the topology as gateways you are already done. Just make sure that the inbound SIP URI trunk to Lync is using already established ports.

In Lync Server 2013 we can take the configuration a little further than 2010. We can define individual trunks for each dialing type. Like I said earlier this doesn’t make it simpler to configure but it can make the configuration clearer to understand. Now we have two well define trunks to the same gateway and we can name it accordingly so we have a clear understanding of the configuration.

image

If creating two trunks in Lync 2013 the individual trunks are identified by the inbound port on the gateway side of the configuration (in our case CUCM).

image

The trunk configuration is then completed in the Lync Control Panel or PowerShell. Below are a couple of screen shots for the configuration I completed in my lab but for more complete details on setting up a SIP trunk to CUCM refer to this document http://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=26800. Although this document refers to Lync 2010 a lot of the same rules apply to 2013. Also keep in mind there are variances in the exact setup according to the version of CUCM you are using. In my example lab REFER is support by CUCM 8.6 so I left it as enabled but other versions this will differ. Use this link to match your CUCM version setting requirements http://technet.microsoft.com/en-us/lync/gg131938.aspx.

image

Trunk settings for encryption, enable media bypass and REFER for CUCM 8.6.

image

The last time I posted this info Alex Lewis asked the question about “You say the DID can be the same in Cisco and in Lync but if I'm in Lync and dial another user then only their Lync endpoint will ring.” Well thanks to an Anonymous tipster I believe that we have somewhat of a solution to this. There is an attribute that can be added to the users Tel URI that will stop Lync from doing the usual RNL behavior. This means that any call to the users extension can be routed to CUCM regardless of whether its configured in Lync as the user line URI while allowing the RDP in CUCM to ring the Lync client. Now this is by no means a perfect solution. There is potential hair pinning of calls through Lync to CUCM and back to Lync. While this has the potential to consume some extra resources its not going to be life threatening in most cases. Its just a matter of planning for it and understanding call flows in your environment.

What you potentially end up with is a Line URI that looks like this:

tel:+12345678;ext=5479;ms-skip-rnl

The ms-skip-rnl is what will cause Lync to pass the call directly out to CUCM rather than follow normal reverse number look up behavior for calls to be routed to users. This attribute is actually used else where in the product for certain functions such as CAC and RCC so its not a total mystery of its existence but this is not its normal use.

Lastly I just want to mention, use this configuration at your own risk. This is not the usual configuration that one would follow in setting up Lync. When calling in a support ticket this attribute may be required to be removed if you are having issues. As my friend and college Doug wrote to me in an email exchange “The mechanism that it leverages will probably remain in the product forever but, if they called support, the engineer would probably go, “huh?”. I think you get the idea now.

image

How do I configure CUCM?

In my testing I was using CUCM 8.6 so your settings may vary depending on the version you have.

SIP Trunk

The thing with this configuration is that you are creating a SIP trunk for one purpose and that is to ship messages with headers that have the “to” field with a SIP URI format to Lync. So LyncUser1@contoso.com as an example.

Your Tel URI and SIP URI SIP trunks can share the same SIP Security Profile and outbound ports to Lync but you will need to use different DNS/SRV names or IP address DNS name combinations. So as an example:

SIP URI Trunk – FQDN – 2013-lync-fe.contoso.com

Tel URI SIP Trunk – IP Address 192.168.0.170

Below is my trunk configuration for my SIP URI routing with a FQDN for my Lync 2013 Mediation Server.

image

SIP Profile for calling out a specific listening port:

image

In my case I used a IP address on one trunk for Tel URI calling and the FQDN on the SIP URI trunk. Now if you are not that fixed on configuring route groups and route lists for the SIP trunk connecting to Lync you can configure the trunk directly on both DID and SIP URI route patterns and just have one trunk. I tried both in my lab and it worked either way.

In this 2013 update I changed around my configuration somewhat to route to separate trunks that have separate port numbers as well. Like I said earlier this give the ability to create more control at either end of the trunk on either Lync or CUCM.

Update: SIP Normalization Rules

I received quite a few emails and comments from people that ran across an issue. If your Lync deployment was larger than a single pool the port specified in the SIP invite from CUCM would cause calls to fail. If you user wasn’t part of the pool associated with the mediation server receiving the invite from CUCM redirecting the invite to the correct pool would fail. The error message generated indicated a port issue.

LogType: diagnostic
Severity: warning
Text: Message was discarded by the application
Result-Code: 0xc3ee7964 ES_E_REQUESTURI_VALIDATION_FAILED
SIP-Start-Line: INVITE sip:firstname.lastname@contoso.com:5060 SIP/2.0
SIP-Call-ID: a5c03a60-e790-4490-9e02-75baf13b8250
SIP-CSeq: 51567 INVITE
Data: application="http://www.microsoft.com/LCS/UserServices"
$$end_record

Seems Lync didn’t like the header with port 5060 being part of it when passed to another pool. The exact reason why it doesn’t like it I am not sure why but this was the issue identified.

This really stumped me. I wasn’t quite sure how to work around it but luckily a reader supplied the answer. CUCM has the ability to create normalization scripts to fix header issues like this. This is somewhat similar to MSPL scripts in Lync which many of you are probably familiar with but uses an open source scripting language called Lua http://www.lua.org/docs.html. Here is a similar example I also found that replaces IP address with a domain name.

Creating the Script: Device>Devices Settings>SIP Normalization Script

image

Add new-

image

Paste in the follow contents, name the script and save::

M = {}
function M.outbound_INVITE(msg)
local method, ruri, ver = msg:getRequestLine()
local uri = string.gsub(ruri, "5060", "5061")
msg:setRequestUri(uri)
end
return M

image

Finally apply the script to your CUCM SIP trunk for SIP URI dialing.

image

SIP Route

Probably the new piece of configuration to most people will be the SIP route itself. Its pretty easy to configure. See below. I created a domain route to contoso.com to route my SIP URI traffic that I setup for my users on their Remote Destinations.

image

User Setup

As far as the user setup goes the only variation between the standard setup mentioned in the guide I referenced earlier is to configure the user with a SIP address to route calls in the Destination Number under Remote Destination configuration. In my case I used garthf@contoso.com as my destination number rather than a DID or other number.

image

This configuration is probably one of the most important interoperability pieces I have written in a while. I can see this alleviating quite a few issue I have come across in the field and hopefully this article will get good circulation so more people know about it. If I look over all the possible ways to do interoperability between Lync and CUCM (RCC, Plugins etc, etc) this really does give the best of both worlds without sacrificing one for the other unlike other methods like plugins which ruin the Lync UI experience. There are some complexities for the initial setup but at the end of the day your using the features available of both products without the use of third parties or additional servers. Call it the biggest bang for your buck if you will.

Video with Expressway

So you have done your audio interworking following  this post and from all the feedback I have received this has been hugely popular way to do it, now its time for video. So lets assume you’re a standards based room video user and you want to add video interworking with Lync from CUCM. On the Cisco side this requires the use of Expressway which allows internetworking from standards based endpoint using H.264 AVC to H.264 UC SVC. Microsoft like many vendors has its own variant only implementing part of the standard which isn't unusual and can be found here :Unified Communications Specification for H.264 AVC and SVC UCConfig Modes. I personally don’t know if any other vendors besides Polycom and Microsoft have implemented this variant but it does provide some backward capability to H.264 AVC in mode 0 which is good.

Even though Microsoft has some video codec backward compatibility with H.264AVC with Lync 2013 signaling is still a challenge and that's where Cisco Expressway comes in to the picture. Expressway works on both interworking the signaling coming from Lync as well as adjust for video code differences.

image

Now I am not going to go step by step through how to configure this setup but I will just hit on one area where you may fall into issues if you have already followed the earlier info on using the ability to dual ring the Lync client using a SIP URI. Seeing as the Mediation Server is audio only but we are still sending URI’s to it our video endpoints wont be able to use the same path for dialing Lync clients. Dialing back the opposite direction from Lync to CUCM/Expressway is a little easier as Lync has no way to dial pure audio devices without a DN to be able to route to them. Video on the other hand Lync can use a Static route to forward to the video domain. CUCM how ever we have hit a point where different devices are trying to route over different paths via the same URI potentially. One SIP trunk for audio and one SIP trunk via Expressway for video.

Although this is a very generic depiction below using CUCM Call Search Spaces and Partitions we can ensure our devices are using the correct path. This should be pretty straight forward for most CUCM admins but if your focus is Lync this might be a little less obvious. This is the same sort of concept as routing via geographical location but this time we are doing so based on the feature/service required versus a location.

 

image

This configuration ensures that peer to peer video will be processed between the two environments regardless of the calling direction. Calls from Lync to video MCU resources residing on CUCM work pretty much the same way but unfortunately calls from CUCM video devices to the Lync AVMCU from video endpoints other than audio calls using a DN will fail. This is because of Microsoft’s use of CCCP protocol which is basically buried in SIP SDP signaling. Expressway does not support CCCP.

Eventually RDP and content sharing support beyond what's available today will also be a part of the picture as announced recently on the Cisco blog.  Keep an eye out for more updates to this post.

If folks need more explanation please feel free to post your questions. I have used the comments to keep expanding on this post multiple times now so if you have done something that adds to this please let me know, no matter how minor it is.

VoIPNorm

Cisco UC Application Virtualization Explained

I spend quite a bit of time discussing Cisco’s Unified Communications Applications in a virtualized environment. There is a ton of information available for deploying and also support guidelines at the Wiki site below:

http://docwiki.cisco.com/wiki/Unified_Communications_in_a_Virtualized_Environment

So much information that it is hard to work out where to start. I thought I would break down what the options look like and help give a base level knowledge to folks in need. It took me quite a while to get around the site especially with trickier questions around CPU speed and changing CPU’s etc.but as you learn the different areas and requirements it makes a great reference to support guidelines. It is the definitive guide for virtualized Cisco UC applications. Actually for anyone doing a UC project the guidelines presented for Cisco can also be helpful to apply some of the same guidelines for any real-time application.

Hardware Categories

There are three main categories when it comes to the hardware that is supported when deploying Cisco UC applications in a virtual environment.

UC on Unified Computing System (UCS) Tested Reference Configurations (TRC) – This is probably the easiest way to buy, deploy and support Cisco UC applications on supported and tested models of UCS hardware. These are specific models of hardware that cover everything from CPU speed, RAM and hard drive size. Some models such as the Business edition 6000 and 7000 only require a single part number to purchase everything including the VMware licenses. Both servers are based on UCS TRC  models. Currently there are nine different UCS models that fit into this category from rack mount to blade servers.

UC on UCS Spec-based So what if you have UCS and it meets the minimum spec of your UC applications but doesn’t match the a TRC server build. CPU speed and or architecture is an example, this falls under UCS Spec-based guidelines. One thing to focus on when investigating whether your UCS box will support Cisco UC applications is the CPU architecture guidelines. If it doesn’t match the supported architectures than you may have to look at changing out your CPU or other hardware to meet the minimum specs.

UC on 3rd Party Spec-based The guidelines for support are  similar in certain aspect to UCS spec-based but of course Cisco does not validate, support or test the third party hardware. Also be aware that the customer must be responsible providing a licensed, supported version of VMware vCenter and vSphere ESXi.

So there are three major areas to watch for this category:

  • VMware version support. UC application version support for VMWare ESXi can vary but the version of ESXi also needs to be support by VMware for your hardware : http://www.vmware.com/resources/compatibility/search.php
  • CPU Architectures are specified and some CPU architectures my never be supported so this is a very important  to ensure you have correct architecture per your UC applications.
  • CPU speeds and total cores must match the minimum spec of your UC application.

This is really for customers that are comfortable self supporting their own hardware environment. As you can tell there are a few variables that affect the supportability of a platform so it will always be best to check with Cisco before you purchase or deploy on a third party spec box.

Third Party and UC VM Co-residency

Once you have picked your platform and decided what UC applications you want to deploy now you need to understand what can and can’t be deployed on the same VMware host.

There is a great document that goes into detail on what is and is not supported here. The basics are if a third party application is installed on your host and is deemed to be interfering with your UC applications it may need to be either removed, shut down or ported to another VM host so you can continue to troubleshoot with the TAC.

For some general guidelines here are some simple rules to follow:

  • Don’t over subscribe your applications, it’s a one to one mapping between your VM and your hardware.
  • Use OVA’s for your Cisco UC applications
  • CPU guidelines must be followed (speed, core mapping and architecture)
  • Don’t overload your network and ensure your looking at QoS design considerations for virtualization

VMware Feature Support

This has a few moving pieces but VMware features are well documented as to what is and isn't supported. Probably the most common features are vMotion, cloning or copying virtual machines and Snapshots. Depending on your applications it may or may not be supported but there is a good table located here to help you decide what feature support is available.

Replacing a CPU in a VMware host

I recently had a case where a company needed to change CPU speeds. So if for some reason you need to upgrade your CPU’s in your VMware host server here are a few things to consider:

    • According to VMware support guidelines ensure that the CPU remains the same manufacturing technology. If you are going to replace an Intel Xeon 5100 series CPU with a Xeon 5300 series CPU, even though the number of cores are different, but they are still under Intel Xeon 5000 series, there are no issues with replacing them. However, swapping CPUs between Intel Xeon 7000 series with 5000 series may cause ESX to function in an unexpected manner.
    • Ensure the same CPU architecture per the UC application guidelines
    • Ensure the minimum speed and core amounts are meet for your UC application for the amount of users you wish to support.

UC Placement Tool -http://tools.cisco.com/ucs

The virtual machine placement tools is very helpful in understanding how to map your virtual machines to the hardware.

The Cisco Collaboration Virtual Machine Placement tool (VMPT) is to be used AFTER design guides and sizing tools, and BEFORE creating a bill of materials, quote or configuration in Cisco Commerce Workspace.

It helps you visualize a deployment of virtualized Cisco Collaboration to simplify specifying the required physical servers and virtualization software. It is not intended to be used as a "design tool", "sizing tool" or "quote tool" that substitutes existing processes.

image

VoIPNorm

Cisco Contact Center Videos

Here are some great videos that are good intros to Cisco Contact Center and also a Finesse CCE/CCX 10.5 update. For those that don’t know Finesse is the new Web 2.0 agent/supervisor desktop.

This is a great update on Finesse CCE/CCX  10.5 from Cisco Live 2014.

VoIPNorm

Cisco Unified Attendant Console Standard

I have had a few different companies recently that have been asking for more information around the Attendant Console Standard. Typically these types of applications require separate servers to run into an existing call control platform. A lot of the time it requires a third party even for simple attendee console requirements.

Cisco Unified Attendant Console Standard changes that considerably. It runs against CUCM without any more infrastructure and has the same look and feel as other Cisco UC apps. It does a nice job of integrating into Jabber presence and also busy lamp field in the directory. For Lync presence integration the Advanced client is required but that comes with its own infrastructure and is also aimed at heavy call environment.

Standard is aimed at more of a department reception role or branch operations but could also fill the requirement for smaller companies . There is a limit of 5000 imported contacts. Dedicated operators with higher call volumes are better served with the Advanced console.

Below is the architecture used with CUACS, its really pretty basic. CUCM and pick your presence engine either CUPS or WebEx Messenger. CUACS also supports using Jabber as the voice endpoint even though from my experience most people working in reception/operator roles prefer hard endpoints:
image

Below is a screenshot of the Console running on my Windows machine using a 7841 as the voice endpoint. It’s a drag and drop application so I can take current calls in progress and drag and drop them into the parked area. Makes this operation pretty simple.

image

I could not get a way to load up my machine with calls but the stock shot below shows it pretty well managing multiple lines.

image

Time for a virtual demo:




Attendant console isn't going to change the world and it is a standard voice application but CUACS goes a long way to simplifying it. By limiting the amount of licensing and servers its going to make lives of many easier when faced by a busy Exec Admin or reception area.

Resources

Training Videos
https://www.youtube.com/channel/UC3jC1gmgsRWPR4PLR2VWBhA?feature=CCQQwRs

Cisco Unified Attendant Consoles Hub
http://www.cisco.com/go/cuac

Product Documentation
http://www.cisco.com/en/US/products/ps7282/tsd_products_support_series_home.html

How to videos
https://communities.cisco.com/message/152963

VoIPNorm