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
Great ***** article.
ReplyDeleteFor a company with Cisco UCM core base services, it will be valuable for me to introduce OCS on customers
Great Article. Exactly I was looking to do. But in order to make sure traffic stays local, Cisco phones at remote site should also be configured to use SAME MTP's that remote site SIP trunk will use. Is that correct? If Cisco phone are not configured but SIP trunk at remote site is configured then it will defeat the purpose?
ReplyDeleteYou are kind of correct. The phone will pretty much only use the MTP assigned to phone if an event calls for it (transfer, hold) but it will always use the required MTP on the SIP trunk. The much better solution if you want to assign MTP resources outside the bounds of the trunk is using a device pool for the site so that you use local resources by assigning the MRGL to the device pool. This means that if you make the SIP Trunk part of the same device pool it will use the same MTP resources as the other devices in the device pool (to make it defualt to this leave the MRGL setting on the trunk blank or use the same MRGL as the device pool). This makes it much easier to control changes and in this case you would be using the same MTP resource for both phone devices and trunk at the same site in the same device pool.
ReplyDeleteA lot of companies do not have MTP's configured for phones but for trunks only so it does depend on your setup.
Chris, as always I appreciate your perspective and innovative approach. However as long as the letters "MTP" are involved in any design to integrate/inter-operate between OCS & CUCM, there will scalability issues. MTP's are typically minimal in deployment in a CUCM enviornment, they are generally not cheap, and MTP's in 'software' are never ever a good solution.
ReplyDeleteUltimately the goal should (and needs to be) elimination of MTP or any additional call processing agents and ideally integration/interoperability between OCS & CUCM should be no more difficult than interfacing with a 'cloud'. Now how that will happen is going to be interesting to watch. Not that we're naming names but the two large vendors in this space are clearly not interested in seeing that happen anytime soon.
So complete agree. At the moment this is seen as a issue in some deployments. Deploying MTP's in router software is less of an issue than on CUCM software if you have the router resources available to do so. I have successfully done it and seen it done in a number of deployments. I agree with you though that using DSP's to deploy MTP's can be costly.
ReplyDeleteMost of the interop issues seem to be coming with earlier ( I previously said later but I meant earlier, my bad) model Cisco IP phones but as they disappear from the Cisco ether things should actually become easier. Also as skinny disappears from CUCM deployments and move to SIP it will help also considerably. Hopefully in wave 14 there will be some positive changes in this space that will make it easier moving forward into future versions that may eventually lead to the removing the MTP requirements.
100% agree - especially the comment of SIP. And I should have clarified, MTP in IOS platform is fine, my comment was based on CUCM software MTP. Anyway, this continues to be the best forum for discussion and you do a great job of hitting right on topics that many enterprises are struggling with or exploring. Kudos!
ReplyDeleteChris,
ReplyDeleteIn regard to your comment about "A lot of companies do not have MTP's configured for phones but for trunks only so it does depend on your setup.". At our company, phones are not configured to use MTP's at remote sites but we do have device pool for remote site.
So how should my SIP trunk be configured for remote site?
Should I leave Device Pool at default and configure MRGL for remote MTP's ?
OR should I configure device pool for remote site and leave MRGL blank?
Hi,
ReplyDeleteGood question. You really only want the MTP’s to be used by your trunk to CUCM since it doesn’t sound like you need them anywhere else. I would configure a MRG and MRGL specifically for the trunk at your remote site. That way it removes confusion of what is using those resources and you can effectively configure your resources based on load. So if you have 20 MTP’s (so to speak, or DSP resources) and your peak call rate is 20 simultaneous calls you can assured that you have reserved your capacity.
So once you have MRG and MRGL configured you can apply them directly to your SIP trunk in CUCM.It removes confusion of device pools and everything else.
Cheers
Chris
Chris,
ReplyDeleteThanks for your input. Just for clarification so Device Pool should be left default in SIP trunk config correct?
Yes that should be fine.
ReplyDeleteChris, great post and still useful, possibly even more so with Lync media bypass around.
ReplyDeleteNow, I'm just trying to get it straight in my mind on how to ensure the RTP stream stays local to a site and uses the local ISR MTP resources. I believe you need a SIP trunk dedicated to that site? This is only required to ensure the MTP resources are allocated to that specific site (via MRG/MRGL). The only way to achieve this is stick a mediation server on that site (or maybe play clever with multiple SIP trunks to CUCM)? I'm trying to work out how I can best use ISR resources on a campus network with a centralised CUCM cluster and remote ISRs. I can't see a need for multiple mediation servers except for the SIP trunking/MTP resourcing ... which is not really sensible.
Jed
Hi Jed,
ReplyDeleteWith Lync you can centralise your mediation server resources because of media bypass and the fact that you can do a one to many gateways unlike OCS which was more one to one.
In saying that when you deploy either the SBA or the server version of the SBA the SBS there is a mediaiton server as part of that deployment. You can think of the SBS as a enhanced SIP regitrar and a mediaiton server in one box. So depending on your survivability requirements in the branch its really up to you if you choose to deploy mediation server resources locally at a branch, its no longer a requirement with Lync.
Hope this helps.
Thanks but sadly I'm still not clear on the best options :(
ReplyDeleteThe fact the mediation server is central means we have one central SIP trunk, so just one place to reference MTP resources, via the attached MRGL. If every audio stream has to traverse the MTP then that means the call comes back to a single MTP resource location. I don't beleive media bypass removes the requirement for MTP traversal, it just removes the mediation server doesn't it? How does that work for a multi site Cisco ISR deployment?
As for SBA/SBS, yes I can see that is good for greenfield remote sites, but when it's a legacy CUCM customers are keen to leverage their current investment ... hence trying to get a grip of these voice routing scenarios.
The fact that the mediation server is central in Lync doesnt mean just one SIP trunk. You can have multiple trunks going out to other gateways with local MTP's. Like I said the mediation server in Lync is one to many gateways. So you can have a centralized mediation server with a trunk out to many remote gateways and using media bypass the media doesnt route over the WAN any more.
ReplyDeleteHope this helps.