Using MTP’s for interop for CUCM to OCS

I have been on the path of interop for Office communications Server and Cisco Unified Communication Manager for some time. Lots of experimenting, successes and some failures. Microsoft even used some of the documentation I have written to pass on to some of their customers. But one thing that never really gets talked about is the best way to use and deploy Media termination points in the Cisco environment for this interop story. With this post I am going to try and shed some light on some of the best ways to make best use of MTP’s for interop.

What are MTP’s, how do I configure them and what’s the best combination to ensure I get the best bang for my buck?

Media Termination Point (MTP)

MTP’s are a required option on the CUCM (h323 or SIP) trunk/gateway that connects to your OCS environment whether you are doing direct connect or through a gateway with H323 as the trunking protocol. They form an important part of the interop environment for different reasons depending on what protocols you are using. In the case of H323 its required for extended services (hold, transfer etc) and SIP its for compliance with RFC 2833. As an example of the first with H323, nearly all functions will work without MTP’s except ad-hoc conferencing from a Cisco IP Phone that has a Communicator user as the first participant. The communicator user is dropped due to the conference going on hold as the first step in the process.

Depending on the version of CUCM you are using it can make a difference as to your choices whether you are using some intermediate gateway to interop between the two environments. If you’re like a lot of companies and are stalled on CUCM 4.X you may have chosen not to do direct trunking between the two environments.

Cisco link to more information on MTP configuration and use:

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/admin/6_1_1/ccmsys/a05mtp.html#wp1030050

Software MTP’s CUCM Server

One thing I haven’t mentioned so far is locating MTPS on the CUCM subscribers. This is a great idea for a single site with limited users, low traffic volumes and the easiest option. MTP’s are much less resource intensive than other CUCM services like transcoding and conferencing. This can have its limitations though such as not being able to locate the MTP’s locally and if your subscriber is heavily loaded it may cause some issues with call quality as the RTP stream will pass through the server.

CUCM 4.x Enhanced MTP’s (on a Cisco ISR)

CUCM 4.x can have some limitations with SIP, so H323 is a safe option and with the IP-IP GW it works pretty well (depending on IOS on your gateway version of course). I have settled on the IOS version 12.4.22yb4 currently while running MTPS onboard the router in software(this uses the router CPU). You can run MTP’s in DSP hardware on an ISR but I believe this to be a waste of resources unless your router is under significant load. DSP’s are very costly and can significantly increase the cost of router hardware. My advice is save these resources for transcoding or conferencing for which DSP’s are a requirement in your Cisco environment. The MTP configuration is below for an IOS router. Take note that although you can name your MTP anything you want there is a 15 character limit. In my case I have called it MTPOCSRouter1. The name must be unique for registration in CUCM. Whats also important is that you have the priority of the of your CUCM subscribers that same as the preference of you dial peers. I have seen one way audio occurrence because this wasn’t set correctly.

sccp local FastEthernet0/0
sccp ccm XX.XX.XX.XX identifier 1 version 4.1
sccp ccm XX.XX.XX.XX identifier 2 version 4.1
sccp
!
sccp ccm group 1
description SCCP CCM group
bind interface FastEthernet0/0
associate ccm 1 priority 1
associate ccm 2 priority 2
associate profile 101 register MTPOCSRouter1
!
!
dspfarm profile 101 mtp
codec g711ulaw
maximum sessions software 200
associate application SCCP

Below is a diagram to show the full configuration. MTP’s located on the ISR router as well as traffic to the OCS environment passing through the ISR working as an IP-IP GW. This is for a single site like a datacenter where call volumes may be high and you need redundancy. You can also apply the same logic to a branch where you may also have a ISR located for local PSTN access for your Cisco deployment. Placing a mediation server and MTP local will stop tromboning calls across the WAN which is what would happen is both the mediation server and MTP’s where located in a central site and a OC user at a remote site calling a Cisco user at the same remote site. So not much point having one without the other.

In the diagram it shows the MTP as separate entities bound to just one trunk. You could have pooled the MTP resources in to one media resource group but what this could lead to is media traffic having to flow through two device before reaching the medaiton server. Not a desired behaviour and has no benefit. Best bet is to only allow the MTP’s on each gateway only be used for that gateway. One to one if you would like to consider that way.

Although not shown in the first diagram the MTP’s are controlled using Skinny similar to the Cisco IP phone. Skinny is a Cisco propritiory protocol.



CUCM 5.x,6.x and 7.x

The use of MTPs looks somewhat different as you do not have RTP flows having to transition through the ISR for any other reason than the MTP’s themselves. The ISR is now removed from the call signaling flow and the MTP’s are pooled together as a single resource rather than for just one connection.



MTP’s are an unfortunate evil in the interop story between these two infrastructures. If for instance your entire infrastructure was SIP on the Cisco side MTP’s would be much less of a problem but since most Cisco deployments have a mix of control protocols (SCCP, H323 and MGCP) they are a requirement.