Using Remote MTP Resources for OCS Interoperability with CUCM

Sometimes in life, things are a fine art to get just right. Media Termination Points are kind of like that along with other resources in the Cisco VoIP infrastructure. Knowing where to place them and what resources to use can be a little confusing to those new to Cisco VoIP or those trying to do interoperability to Microsoft Office Communications Server for the first time. This post builds upon a much earlier post I did on configuring MTP’s for interoperability with OCS.

The number one rule to remember when doing interop Between CUCM and OCS is if you want to avoid having VoIP trombone across your WAN links is you’re going to need to place some MTP’s at the same site as a mediation server. Although the SIP traffic is not going to be routed to your MTP’s from the mediation server, RTP traffic certainly will. So how is this accomplished?

First off, for every mediation server you are going to allocate a SIP trunk in CUCM (doesn’t matter what version it’s all the same). Secondly, you’re going to need to build the MTP, a Media Resource Group and a Media Resource Group List. Of course the media resource group and the media resource group list can contain more than just MTP’s but to keep things simple I like to have specifically defined groups and lists just for the SIP trunk to which you want to control the flow of RTP traffic. Example below:



In this example I have shown a workflow of what the MTP design would look like within CUCM. At your main site if your CUCM servers aren’t terribly taxed you could actually host your MTP’s on the CUCM subscriber servers themselves but at the remote site you would need a local MTP resource to avoid the trombone effect I described earlier with RTP.

This next diagram shows a simplistic picture of the signaling and RTP traffic that is happening between a Cisco IP Phone and Microsoft Communicator endpoint. I have removed the endpoint signaling traffic just to simplify the example a little. But as you can see the RTP local to the site stays local when you have the right resources in place.



In this example I have used the design of configuring the MTP resources on the ISR devices utilizing either DSP hardware or router software. Using DSP’s might be a good idea if your router is multitasked and its CPU utilization is already seeing regular usage beyond 50-60%.

The idea behind this post comes from some recent questions from customers in regards to remote site configuration. This type of design is for the current version of OCS 2007 R2 when doing interoperability to a CUCM environment, how this will change in the future is yet to be seen.

Comments welcomed
VoIPNorm

CUCM handling of REFERs for Exchange 2010/2007 UM Dial Plans

CUCM handling of REFERs for Ex2010UM/Ex2007UM Dial Plans

Below is an interesting situation that may occur as you head down your migration path from Exchange Unified Messaging 2007 to 2010. In case you didn’t already know a Exchange 2007 and 2010 UM server can be part of the same dial plan for the purposes of mailbox migration. When a call from CUCM hits the Exchange 2010 UM server it uses a REFFER to transfer the call to the Exchange 2007 server if the user hasn’t been migrated yet. This is a pretty simplistic description but I think you get the idea. This link fully describes the migration process from Exchange 2007 to 2010.

Thanks to Dave Howe for providing the following information.

ProblemCisco Unified Communications Manager (CUCM) does not handle REFER properly for Ex2010UM/Ex2007UM Dial Plans

Configuration
(UM) Dial Plan is associated both Ex2010UM and Ex2007UM servers
(Cisco) SIP Trunk configured between CUCM and Ex2010UM server
(Cisco) Route Pattern for SA Pilot (70000) configured to use SIP Trunk

Behavior
Caller dials 70000 (SA Pilot Number)
-Call is placed from an unrecognized number (PSTN, conference room, etc)
-Caller has Exchange 2007 mailbox and is enabled for Unified Messaging
Ex2010UM server does not recognize caller, answers and prompts for extension
Caller enters extension, mailbox resolves to Exchange 2007 server
Ex2010UM server sends REFER to CUCM to transfer the caller to Ex2007UM server
CUCM responds with 202 Accepted, followed by two NOTIFY packets with 404 Not Found (transfer fails)
Ex2010UM cannot handle call, disconnects after telling caller that mailbox version is unsupported

Issue #1
DNS resolution failure
REFER-TO header sent from Ex2010UM contains FQDN of Ex2007UM server
REFER-TO:
CUCM must be able to resolve FQDN of Ex2007UM server to routable IP address

Issue #2
FQDN of Ex2007UM server sent in REFER-TO header is not defined as a routing target within CUCM
Route Pattern is used to route calls placed to extension 70000 to the IP address of Ex2010UM server
SIP Route Pattern containing FQDN of Ex2007UM server is required
In CUCM Administration UI:
1. Go to Call Routing > SIP Route Pattern > Add New
2. Select Domain Routing, enter the FQDN of the Ex2007UM server, then select the Ex2010UM trunk
3. Select the correct Route Partition, then click Save

Issue #3
INVITE from referred calls handled by CUCM do not contain REFERRED-BY information
Extension entered by caller is provided by Ex2010UM server in REFERRED-BY header
REFERRED-BY:
CUCM fails to use the REFERRED-BY extension in the INVITE that is sent to the Ex2007UM server
Caller hears, “Welcome, you are connected ….” and is prompted to enter their extension a second time
No workaround, contact Cisco (UM Product Group has a ticket open with them)

Support for Direct SIP for CUCM 7.1.3 and OCS 2007 R2

In case you haven’t visited the OCS OIP page recently there has been an update to include Cisco UCM 7.1.3. With that Cisco have also released a Direct SIP interoperability document for that version. Cisco has done a good job of documenting the configuration with what information was probably available at the time. There are a few things that have been released since this document was written that will help with this interoperability further that I have outlined below. I think Cisco have done a good job at collecting current issues that can occur with this interoperability. They call out some now resolved Microsoft issues as well as a lot of their own current issues. Also interesting, whether intentional or not is some questionable material in the last limitation section which is surprising to have in a configuration document. Maybe Cisco are just trying to clearly (not sure clearly is the right word) outline what Cisco are supporting but they seem more like blanket compete statements to me.

The first section covers the tools and testing procedures used. They also make mention that E.164 is used throughout the document which is also a plus. E.164 seems to be the direction Cisco is now heading with the release of IME which requires E.164. There is also a plug for CUCiMOC in this first section. For those of you that have read my blog for some time, you will already know how I feel about a plugin versus native features in Communicator but for those that haven’t please feel free to check it out.

The limitations section has a few points that have changed due to newly available updates that have resolved the issues noted. The first one is –

“OCS 2007 R2 does not support calling and connected name. Cisco UCM sends its calling name and number to mediation server/OCS, but the OC only displays the calling number. Name is not sent by Mediation Server.”

This has been available for some time with the update mentioned here.

Next is a recent topic here on VoIPNorm with the RTCP incompatibilities. –

“During a three-way conference initiated by an OC user the OC user is unable to “mute” any participant that is connected to the conference using a Cisco Unified IP phone. The issue is caused by the incompatibility between Microsoft OCS R2 media keepalive mechanism against Cisco Unified Communications solutions.”

This has been resolved with update mentioned here.

I understand that these things would appear in a Cisco document since they may not be tracking every update of OCS or the document was released after the fact.

The last section on known limitations has a couple of interesting lines that are in no way related to Direct SIP interoperability but I thought it would be good to mention them anyway. They are really generalized statements that had they been given some direction may have made sense in relation to the content but they were just sort of flopped out there. Some of these statements are correct and Microsoft are resolving them with Communication Server “14” and some are a little misleading.

“The Microsoft Mediation Server does not support video transcoding, thus video is not possible between OCS and UCM endpoints.”

This first comment is correct in that the mediation server cannot transcode video. But in saying that there are solutions out there today from Cisco (this is the funny part), that allow an OCS client to talk video with other video endpoints including Cisco endpoints. Here is the one from Cisco that describes using a Cisco MCU to do video interoperability with OCS and Communicator. Furthermore with the acquisition of Tandberg there are a couple of different ways to do video interoperability with what are soon to be Cisco endpoints to OCS through the VCS and Tandberg’s soon to be released UC gateway.

“ Call Admission Control (CAC) is available for UCM endpoints but not OCS endpoints”

This is a true statement, it’s also true if you substitute “OCS” for any other product or manufacturer besides Cisco. Further as some of the more frequent readers already know CAC has been announced in Communication Server “14” as a new feature. But this is a blanket statement from Cisco. Maybe they have had questions at the TAC over using Cisco CAC on OCS endpoints. If it had been defined better I think that would be more useful to customers.

“Survivable Remote Site Telephony (SRST) is available for UCM endpoints but not OCS endpoints”

Again another true statement. OCS users cannot use Cisco’s SRST. Again, feel free to play the ‘substitute your non-Cisco-product-here game – neither can Avaya, Siemens or Sametime clients. As announced at VoiceCon,with Communications Server “14” Microsoft will be Offering their own survivable branch solution called the Survivable Branch Appliance or SBA with Microsoft’s gateway partners. This is another blanket statement but again this may be something that has come up with the TAC.

“E.911 support is available for UCM endpoints but not OCS endpoints.”

This statement could have been correct had it been defined more clearly. Again, a blanket statement that doesn’t describe support by who. Certainly ambiguous. Had they said Cisco it would be correct. There are third party providers providing E.911 support for OCS 2007 R2 that I have talked about on my blog here. Had some due diligence been done they would have known that E911 Enable can in fact support OCS R2and CUCM endpoints on the same E911 Enable infrastructure. Its just so happens that E911 Enable (in addition to Intrado) have also announced support for Communications Server “14” in conjunction with native endpoint support being offer by Microsoft.

I do find it a little annoying that Cisco is calling out what another vendor supports in a configuration document, and as I have shown some of them are only partly correct statements anyway. So in the end it detracts from the intention of the document and hurts their credibility somewhat.. That being said, Call Admission Control, Branch Survivability and E911 are three key features coming in CS “14” – and Microsoft is super excited about being able to share them with everyone.

The bulk of the document is actually pretty standard for this style from Cisco. Even though it is mainly just screen shots they have done a good job at getting the configuration documented. In the end I think that people that have OCS and CUCM deployed already may find that this configuration is a little simpler than first thought. If you plan your OCS dial plan correctly it takes little to no management once implemented when used in conjunction with CUCM.

Finally, the following links are done by the Microsoft team to help with Direct SIP configuration for earlier versions of CUCM.

OCS to CUCM 4.x

OCS to CUCM 6.x

Hopefully this was a helpful post and some of the distracting things mentioned in Cisco’s documents get less attention than they really should.

Comments welcomed.

VoIPNorm

CS 14 Airlift Hangover

Last week some of you may have noticed that I didn’t post. Well, it was an especially busy week with having to attend the Communications Server 14 Airlift in Redmond. This was the first time that I have had the opportunity to attend an Airlift. It was a great week but after having to squeeze as much information into my brain at one time I seem to have a hangover feeling even though I drank no alcohol.

For me, even though I can’t go into any details, PowerShell is going to be a major component in CS 14. Adam mentions it use here. I think it’s a blessing if you're familiar with the constructs of PowerShell and somewhat scary if you’re not. To be honest I am no PowerShell expert, which means I am a little intimidated by it but I can certainly see the potential when combined with its scripting capabilities and anyone that has worked with a command line system before will adapt quickly. After spending 10 years working on Cisco IOS its only a matter of time before I become more comfortable I feel.

Hopefully the next few weeks ease up so I can go back to writing more content here on VoIPNorm. I got some great feedback from people at the Airlift (thanks Henry, Jason and Andrew). One thing people really seem to like is the steady flow of posts. Keeping a blog going with regular posts is a challenge which if you let it, it can fall by the wayside when other more important stuff arises. I am currently in the process of putting together some really interesting posts on some new and not so new interoperability information, so stay tuned over the following weeks.

Comments welcomed.

VoIPNorm