Denver Branch: Shared Deductive Bandwidth After Video Enablement
A retailer runs one CUCM cluster at headquarters and a branch in Denver with 300 phones, joined by a 1536 kbps MPLS circuit. The two locations are linked with 1536 kbps of deductive bandwidth, and the region shared by HQ and Denver allows G.729 audio at 24 kbps and video at 384 kbps. The voice-only design was validated against a busy-hour peak of 55 concurrent audio calls. Last quarter the team enabled ad-hoc video and deployed four 8845s with cameras in Denver. Since then, between 10:00 and 11:00 the Denver help desk logs roughly eight outbound branch calls a day hitting fast busy, and users on active video calls complain about pixelation. No transcoders exist, RSVP is not enabled, and the Denver device pool has no AAR group.
1. Show the bandwidth arithmetic for the Denver location and explain why enabling video produced fast busy on audio calls that used to complete.
Read the worked answer
Locations are a shared, deductive pool: every admitted call removes its per-call bit rate from the link.
- Audio-only ceiling: 1536 kbps / 24 kbps per G.729 call = 64 concurrent audio calls. The measured peak of 55 fits with headroom.
- A 384 kbps video call consumes 384 / 24 = 16 audio-call-equivalents.
Admission is greedy and happens at call setup, not at the busy hour. Suppose a Denver user starts a video call at 10:15 when only 30 audio calls are up (720 kbps). The video call is admitted, leaving 1536 - 720 - 384 = 432 kbps, or 18 more audio calls. Audio demand later climbs to 55, so the 49th call onward is rejected with CAC fast busy for as long as that video call stays up. The daily count of ~8 rejections matches this overlap window exactly; it is not a trunk or dial-plan fault.
The pixelation is a separate problem: location CAC only decides admit/deny. Once admitted, the 384 kbps video stream still needs LLQ/priority queuing on the MPLS circuit, or it degrades under the same congestion that made the design feel broken.
2. The business will not give up video, but voice must never be blocked by a video call. List the configuration changes you would make, in order, and justify each.
Read the worked answer
- Shrink or disable the video budget between HQ and Denver. In the region, lower Maximum Session Bit Rate for Video Calls (for example to 256 kbps) or set it to 0 to ban video between those sites. This is the cheapest fix because the region, not the location, decides what a video call will try to consume; the location only counts it.
- Add survivability for audio that CAC rejects. Create an AAR group on the Denver device pool and an AAR region that permits only G.729. When the location pool cannot admit the call, CUCM reroutes the audio through the PSTN instead of returning fast busy to the user. This is the reason an AAR group is worth having even on a healthy link.
- Protect what is admitted. Trust/priority queuing for voice, EF marking, and a video class with a ceiling below the circuit size, so video degrades before voice does.
- Only then add capacity. If video quality is a real requirement, raise the location link bandwidth to match the measured peak plus one or two video sessions, rather than adding transcoders (which do nothing for CAC). Avoid the temptation to add hardware resources: MTPs and transcoders change media handling, not admission.
3. A third site (Boise) is added, connected to HQ by its own 1024 kbps MPLS circuit; Denver and Boise have no direct path. How should the locations be modelled, and what goes wrong if the engineer creates a full mesh of location links?
Read the worked answer
Model the topology as a hub-and-spoke: HQ is the hub location, and Denver and Boise are linked to HQ with their real circuit sizes (1536 and 1024 kbps). Do not link Denver to Boise.
CUCM deducts bandwidth on every location link a call traverses. With the hub model, a Denver-to-Boise call deducts on the Denver-HQ link and the HQ-Boise link, which is exactly what happens on the wire because the RTP has to transit HQ. If you linked Denver to Boise directly with, say, 2048 kbps, CUCM would deduct only on that fictitious link and would admit calls the real hub-and-spoke WAN cannot carry - the CAC would lie to you and you would get one-way audio or drops at the WAN edge instead of a clean fast busy.
The mirror case matters too: if the carrier later upgrades to any-to-any MPLS where Denver and Boise can talk directly, keeping the hub model is merely conservative (calls are over-counted on both spokes), but it will block calls the network could actually support. Re-verify the location topology whenever the WAN topology changes; it is a design decision, not a one-time setup.