Sizing three sites onto one cluster with a frozen WAN
Your company is consolidating onto one CUCM 14 cluster on the HQ campus. HQ has 1,500 endpoints and is the only PSTN egress: a CUBE with a 300-channel SIP trunk to the ITSP that offers G.711 only. Branch A has 450 endpoints on a 20 Mbps MPLS circuit with a 3 Mbps EF queue; Branch B has 220 endpoints on an 8 Mbps circuit with a 1.5 Mbps EF queue. Planning assumes 6% of endpoints are on a call in the busy hour and that 60% of those calls cross the WAN. WAN upgrades are frozen for twelve months. Branch B has no local PSTN circuit. Branch B also has 25 users who join an HQ-hosted Meet-Me conference at 09:00 every morning, all staying for the full bridge.
1. Size the busy-hour WAN voice load for each branch using G.729, and state whether the EF queues hold. Which CUCM objects enforce the limit, and what does a user experience when the limit is reached?
Read the worked answer
Branch A: 450 × 6% = 27 busy-hour calls; 60% cross the WAN = 16 calls. At ~24 kbps per G.729 call (20 ms payload, no cRTP): 16 × 24 = 384 kbps, about 13% of the 3 Mbps EF queue.
Branch B: 220 × 6% = 13.2 → 14 calls; 60% = 8.4 → 9 calls. 9 × 24 = 216 kbps, about 14% of 1.5 Mbps.
The model is misleading for Branch B. Add the 09:00 bridge: 25 simultaneous conference legs × 24 kbps = 600 kbps, so Branch B peaks at roughly 816 kbps - about 54% of EF and the real sizing driver, not the 6% model. Note that each conference leg to a hardware bridge is a separate stream; if the bridge is at HQ, none of it is saved by local conferencing.
Enforcement: Regions choose the codec (max audio bit rate); Locations hold the bandwidth budget and perform call admission control. When a Location is exhausted the call is rejected - the caller gets reorder/fast busy. Automated Alternate Routing only rescues the call if an alternate path (e.g. a PSTN route) exists in the device's AAR group and CSS, which Branch B does not have. Also remember that a G.711 call on Branch B's link (80 kbps) would consume the queue about 3.3× faster than G.729.
2. CUBE offers G.711 only while the branch regions force G.729. Describe what happens on a Branch A extension calling the PSTN, and design the least-cost fix. How many DSP sessions must you plan for?
Read the worked answer
The CUCM region between Branch A and the CUBE device pool permits G.729; the trunk offers only G.711. CUCM cannot negotiate a common codec, so it allocates a transcoder from the calling device's MRGL. If no transcoder is registered, the call fails before ringing (reorder / cause 'no resource').
Fix, cheapest first:
- Enable G.729 on the SIP trunk's allowed codecs so the branch leg stays compressed end-to-end to CUBE. CUBE then does G.729↔G.711 conversion only if the ITSP will not accept G.729; if it will, this is pure passthrough and costs no DSP at all.
- If CUBE must transcode, put the DSP capacity on the CUBE (PVDM on the ISR) rather than buying CUCM software transcoders, and add the hardware resource to the CUBE's device pool MRGL.
- Never set HQ's region to G.711 to 'solve' it - that pushes 80 kbps per branch call onto the WAN.
Sizing: every branch-to-PSTN call crosses the WAN and needs conversion = 60% of Branch A's 27 (16) + 60% of Branch B's 14 (8) = 24 concurrent sessions. Provision at least 32 to cover busy-hour peaks plus the conference bridge legs, and confirm the G.729 conversion factor against the DSP calculator rather than assuming one session per channel.
3. What happens at Branch B when the WAN fails, and what should you configure and tell the business given that Branch B has no PSTN circuit?
Read the worked answer
On WAN loss the branch phones lose their CUCM keepalives, fall back to the SRST reference in their device pool, and register to the branch router. Configure call-manager-fallback with max-ephones 220 (plus headroom), max-dn to match, the 4-digit internal dial peers, and the SRST reference in the device pool. Phones need an SRST-compatible load and the router needs an SRST-capable IOS and license.
The hard limit: with no PSTN circuit, SRST can only deliver station-to-station calls inside Branch B. No PSTN, no voicemail (Unity is at HQ), no conferencing, no hunt groups, and - critically - no emergency calling. Do not let the business believe SRST equals survivability.
Options to present:
- Order a small local SIP trunk or a single FXO/FXS line at Branch B dedicated to emergency and a handful of PSTN calls; SRST then gets a fallback dial peer and a
dial-peerfor the emergency number pointing at that circuit. - Accept internal-only survivability and document the emergency-call gap as a risk the business signs off on.
- Do not propose a second cluster or a remote CUCM node as a quick fix - the WAN freeze also blocks the cluster-interconnect traffic that would need.