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.

19 comments:

  1. Great info as always, Chris.

    MTP act as demarcation points in the Cisco world the way the Mediation Server does in the OCS world. Both are annoyances, and in a perfect world neither should exist, but in a pragmatic world they do.

    While they are pains, they also make it much easier to protect, manage and troubleshoot each of the two worlds independently of the other. While many admins may have an initial interest in pure end point to end point communication between OCS and CUCM, once they factor in things such as version compatibility testing matrix, security requirements prohibiting Cisco IP-Phones and PCs in the same VLAN, media paths planning, etc, they generally find that it's not (yet) a desirable state. MTP and Mediation Servers are prices to pay, but they may be well worth it for now.

    ReplyDelete
  2. Great!

    Thank you for taking the time to write and draw this!

    ReplyDelete
  3. Any tricks for keeping the CPU utilization down? I am running pretty much the config described here on a 3845. At about 200 MTP sessions the CPU is at 70%.

    ReplyDelete
  4. The best way to lower CPU is to take some load off of the CPU by using DSP's and placing some of the load in hardware. Of course you may also have a bug in the IOS software that may or may not be related to MTP's also you may want to offload other functions that the router is running onto another device.

    Cheers
    Chris

    ReplyDelete
  5. How can I force the software MTP to use the DSP's for processing? I currently have two PDVM2-64 installed.

    Thanks

    ReplyDelete
  6. This should be pretty simple as long as you have already used all you DSP resources for either transcoding, conferencing or T1's.

    maximum sessions hardware XXX

    The router will only allow you to allocate resources you have available.

    Cheers
    Chris

    ReplyDelete
  7. Thanks for taking the time to put this together. I have a question regarding this statement:

    "If for instance your entire infrastructure was SIP on the Cisco side MTP’s would be much less of a problem..."

    This implies that if I had a scenario where one Cisco IP phone was running SIP and the other was running SCCP that I would require an MTP for the SCCP phone but not for the SIP phone.

    Could you possibly expand on this?

    ReplyDelete
  8. Thanks for the question. So the issue is mainly around going between inband and out of band DTMF when talk SIP and SCCP. So if the phones where SIP and all your other gateways where SIP MTP's would no longer be an issue. But since 99.99% of all Cisco deployment have a mix of SCCP, SIP, MGCP and H323 using MTP's becomes mandatory for SIP trunking.

    So in essence you are correct although I have never personally tested this theroy I do belive you can set a SIP phones DTMF setting so that MTP's would not be require but optional or not required at all on a SIP trunk.

    ReplyDelete
  9. Thanks for the quick response. My understanding was that MTPs become a requirement when you are either dealing with a SIP trunk where the remote end only supports Early Offer and/or you have devices that can't support RFC2833 for DTMF.

    In cucm 7x (at least) all SCCP phones support RFC2833. Which then means it comes down to Delayed Offer vs. Early Offer. Maybe that is over simplifying it. I need to come up with a test scenario to understand this better.

    ReplyDelete
  10. You are correct about early offer for outbound calls. Also I was only aware that certain phones supported RFC2833(Cisco refer to them as type B phones). The article I have below talks more about it. Type A phones do not support 2833 (so 7940 for instance). When I wrote this document the installation I was working on had mostly type A phones. In saying that I have not tested the type B phone that do support 2833 so you maybe right in that early offer will be your only issue. You can disable early offer under the SIP profile. So if the moons are aligned it maybe the case you wont need MTP's. Good discussion by the way and I will make an update to this post in the near future.

    http://www.networkworld.com/community/node/30207

    ReplyDelete
  11. Dear Chris,

    We have direct SIP from OCS R2 to CUCM 7.0. Sometimes we face DTMF issues when calling auto attendant systems or conference. OCS Sip trunk do have access to MRGL but resource is only Transcoding and no MTP. My question is what type of MTP should I add as an resource for Direct SIP?

    ReplyDelete
  12. This really depends on your load. You can use software CUCM resources but only if you are lightly loaded on the server side.If you have a router that is not to heavily loaded you can configure MTPS in IOS software. Or if the router is moderatly loaded you can use DSPs and run MTPs in hardware on the router. It really depends on your situation. If you have less than 500 users in my opinion the ISR with software MTP's would be your best bet.

    ReplyDelete
  13. Our environment has CUCM 7.1 at HQ site A and we have SRST from CUCM at site B.
    To my knowledge cisco team deploys there phone by creating different partition and search space for different site so that they can use local PRI circuit avoiding long distance call and local media traffic stays local. Signalling comes up to call manager

    we have integrated OCS R2 with direct SIP to CUCM at site A. we have DSP farm for MTP's. on OCS SIP trunk I have given access to MRGL which has MTP and transcoding as an resource.

    I am planning to add another Mediation server for site B (SRST site), will place mediation server physically at site B. How can I ensure that media traffic stays local when user 1 (OCS user) at site B talks to user 2 (Cisco user) at site B. Would accessing MTP's for OCS SIP trunk at site B help me?

    Thanks for your assistance.

    ReplyDelete
  14. Having MTP's locally will help with calls on that site as long as you configure the Cisco IP phone on that site to use those MTP ressources with the correct MRGL.
    Cheers
    Chris

    ReplyDelete
  15. Hi Chris,

    We are having DTMF issues with High Availability environment. Don't know if this is related to MTP or not but if you had ever experience this issue.

    Environment: - We have 2 Mediation (Med) Server for OCS 2007 R2 , Med 1 and Med 2 talking one to one (Direct SIP) with Call manager Subscriber 7.1 (S) S1 and S2. Med 1 is configured to talk to S1 and Med 2 is configured to talk to S2. We have one PRI line, Both Subscriber are connected to Same PRI line.
    We have Route list and Route Group in Call manager and 2 SIP trunks are been added to Route group. This way we have achieved HA for Mediation.
    We have software MTP’s registered to S1 and our both Sip trunks do have an access to MTP’s through MRGL. DTMF Prefrence is set to No Prefrence on both SIP trunks
    All the necessary services are started on both Subscribers. All the Cisco phones are registered with S1. S2 is ready if S1 fails.

    From OCS MOC Client I can make outbound call either through Med 1 talking to S1 OR Med 2 talking through S2. Making Call is not an issue.

    Issues:-
    When I make call from OCS and if it routes through Med 1 and S1 then I don’t get DTMF issue. However If I call from OCS to Med 2 and S2 then my DTMF fails. It fails most of the time, had worked for couple of times only.

    Any idea why calls going from Med 2 to S2, DTMF might not be working? What might be missing on S2? My Cisco team says everything is configured properly, both SIP trunks are identical, both Subscribers service are started. Again both trunks are configured to have access to MTP’s through MRGL. MTP is checked on both trunks.

    To isolate a problem is with Subscriber and not with Mediation; I configured Med 2 to talk to S1 and NOT to S2 and it started working fine. But we are not able to find where the issue can be in S2.
    Any help will be appreciated.

    ReplyDelete
  16. So this is really just a shot in the dark but it might be the way that the MTP's are registered to CUCM. I would try swaping the primary subscriber the MTP's register to and see if that makes a difference. I have seen this cause other issues with audio. so for instance

    associate ccm 1 priority 1
    associate ccm 2 priority 2

    change to
    associate ccm 1 priority 2
    associate ccm 2 priority 1

    If this does change the behaviour you will need to change the MTP configuration so that they are even split over the subscriber trunks using two dsp profiles. The have a MRG for each SIP trunk, so for instance

    SIP trunk A - MRG A -MRGL - A MTP-A
    SIP Trunk B - MRG B -MRGL - B MTP B

    A theory to test anyhow.

    Cheers
    Chris

    ReplyDelete
  17. Thanks Chris for your quick prompt. Will work with cisco team to see if this is easy to change in production world.
    One more question With OCS R2 and CUCM 7.1 Direct SIP connection is "MTP Required" Checkbox should be selected OR left out?

    Few articles says needed but with Cisco 5.x you don't need as CUCM can dynamically added MTP when needed. So any recommendation for this paramter for SIP trunk?

    Thanks.

    ReplyDelete
  18. It is still required for interop to OCS.

    ReplyDelete
  19. Hi Chris,

    I are using CUCM 8.6 and configured SIP gateway (SIP Trunk) .

    Conference Bridge and Transcoder are not registering with CUCM (Enhanced IOS).

    Any help will be appreciated.

    ReplyDelete

Note: Only a member of this blog may post a comment.