Media Resources: MTP Starvation and Missing Transcoders
A headquarters cluster serves 1200 phones. Its device pools all use MRGL "HQ-MRGL", which contains a single Media Resource Group "HQ-MRG" holding the MOH server and the CUCM software conference bridge. The SIP trunk to the ITSP now has MTP Required checked so that every call carries SDP in the first INVITE. Two ISR routers with PVDM4 DSPs are registered to the cluster as transcoders and MTPs, but the engineer placed them in a group called "ROUTER-MRG" that was never added to any MRGL. Symptoms during the 9:00 busy hour: about one in five external calls returns fast busy, ad-hoc conferences of four or more parties fail with "Maximum participants exceeded", and external callers placed on hold hear silence instead of music.
1. Explain the fast busy on external calls using the MTP allocation rules, and state precisely which objects must change.
Read the worked answer
With MTP Required on the SIP trunk, every call on that trunk must reserve an MTP before it can be extended. CUCM does not search the cluster for any free MTP; it searches only the MRGL in effect for the device. For a trunk-originated call, the relevant device is the trunk, so the MRGL comes from the SIP trunk's device pool (or a device-level MRGL if one is set, which overrides the device pool).
"HQ-MRGL" resolves to "HQ-MRG", which contains the MOH server and the conference bridge - no MTP at all. Allocation fails, so the call fails with fast busy. It is intermittent because a small number of software MTP sessions on the CUCM IPVMS service may be reached through other paths at quiet times, but nothing in the configured MRGL can supply one reliably at peak.
Changes required:
- Create or use a Media Resource Group that actually contains the MTP resources (the router MTPs, plus a CUCM software MTP as backup).
- Add that group to HQ-MRGL, ordered ahead of or behind the existing group according to capacity and hairpin preferences.
- Confirm the SIP trunk's device pool is the intended one - a one-field mistake here re-creates the outage even with a correct MRGL. Then re-test during the busy hour, not at 3 a.m.; MTP exhaustion is a concurrency problem.
2. The transcoders are registered and idle while the conference bridge and hold-music problems persist. What is the most likely reason, and what does that tell you about how CUCM picks a media resource?
Read the worked answer
The transcoders are registered but not reachable through any MRGL - ROUTER-MRG was never added to a Media Resource Group List. Registration only makes a resource a candidate; the MRGL is what makes it selectable for a given device. Idle-but-unused hardware is the signature of this mistake.
How CUCM actually selects:
- The MRGL in effect is determined by the device: device-level MRGL first, otherwise the device pool's MRGL. For a conference, that is the conference controller's phone (the initiator), not the other participants.
- Within the MRGL, Media Resource Groups are tried in list order; within an MRG, resources are tried in their own order. There is no proximity or location awareness in that search, which is why an HQ phone can grab a branch router's DSP.
This explains both remaining symptoms:
- Conferences of four or more fail because the only resource is the software conference bridge, which has a documented participant and per-node concurrency ceiling. A hardware conference resource must be in the MRGL to exceed it.
- Hold music is silent for external callers because the MOH stream is generated in G.711 while the trunk leg may be G.729; bridging those needs a transcoder. The MOH server is registered (it is in HQ-MRG), but without DSP reachable from the MRGL, there is nothing to convert the stream. Diagnose with "Media Resources > Media Resource Group/List" plus the device's effective MRGL, then check the resource's registration status and capacity - not just that it exists.
3. Branch phones on a 512 kbps WAN are added to HQ device pools. After the MTP/transcoder MRGs are fixed, branch conference calls and hold music work but consume WAN bandwidth and sound poor. What design change addresses this, and what capacity sizing must accompany it?
Read the worked answer
The cause is the flat MRGL: because HQ-MRGL is used by every device pool, branch phones' conferences and MOH hairpin to HQ DSPs and traverse the 512 kbps link, competing with the voice calls that link is sized for. Adding resources without a selection policy widens the failure surface instead of fixing it.
Design change:
- Build a branch MRGL whose first MRG contains resources local to the branch (the branch router's CFB/MTP/transcoder), with HQ resources second as a fallback. Assign it to the branch device pool. Conversely, keep HQ device pools off the branch resources so HQ conferences do not land on a 512 kbps link either.
- Keep the ordering deliberate: local-first is right for media quality, but only if the local DSP has the capacity - otherwise the "fallback" is the normal path.
Sizing that must accompany it:
- Count the concurrent resources the branch can genuinely generate: number of simultaneous ad-hoc conferences x participants beyond the bridge's capability, plus MTP sessions if any trunk or interop path requires them, plus transcoding for any codec boundary (for example G.729 WAN vs G.711 MOH).
- Compare that total against the branch router's DSP capacity, then against the 512 kbps link if any session must still hairpin.
- Re-verify the branch location bandwidth afterwards, since conference and MTP media consume the pool just like a call. If the branch cannot justify a DSP, the honest answer may be to deny rather than hairpin: a degraded conference over a saturated 512 kbps link is worse than a clear "resources unavailable".