Single Cluster, Seven Sites, 10 Mbps Spokes: Validating a Centralized Call-Control Design
A Dutch customer runs one Cisco Unified CM cluster on three servers (one publisher, two subscribers) in the Amsterdam data center, serving 3,360 endpoints across seven sites: HQ with 1,800 phones, three regional offices with 400 each, and three small offices with 120 each. The WAN is hub-and-spoke MPLS with 10 Mbps at every spoke, 110 ms round-trip to the farthest office, and 1% packet loss during peak hours. Each site keeps a local PSTN gateway with 30 DID channels, and the carrier will not reroute calls between regions. The CIO demands 99.99% call-control availability, local PSTN breakout during WAN outages, and no loss of internal dialing at any branch when its WAN link drops. The incumbent design places all three servers in Amsterdam, uses G.711 on every link with no regions or locations configured, and has no SRST. The network team insists 10 Mbps is plenty and refuses upgrades. You must validate or reject the design and produce a defensible counter-proposal.
1. The customer asks you to stretch the cluster across Amsterdam and the two largest regional offices to 'improve availability'. Evaluate that request and state where the three servers should sit.
Read the worked answer
Reject the stretch. Intra-cluster traffic (database replication, TFTP, inter-server signaling) is the tight constraint, not phone registration: Cisco's design guidance keeps cluster nodes within roughly 80 ms round-trip of each other, and 110 ms to the farthest office already exceeds that budget before you add 1% loss. Putting a subscriber in a regional office would create replication retries and slow directory/configuration convergence, and any WAN event would look like a cluster failure rather than a site failure.
Endpoint-to-CUCM latency is the looser constraint: 110 ms round-trip is inside the ~200 ms guideline for phone-to-cluster signaling, so centralizing call control is sound. The real problem is the availability promise. 99.99% is about 52 minutes of downtime per year; three VMs in one data center on shared hosts, one WAN, and one power domain cannot credibly deliver that no matter how the servers are placed.
Recommended position: keep publisher and both subscribers in Amsterdam, but on separate ESXi hosts and separate power feeds, dedicate the publisher to no call processing (or at most a standby role), run TFTP on a subscriber as well, and ship DRF backups offsite on a schedule you can actually restore from. Then tell the CIO the truth: this design supports 99.9%, and 99.99% requires either a second low-latency data center (dark fibre or metro Ethernet under about 5 ms) or an explicit, signed risk acceptance. Do not let the topology change substitute for the availability conversation.
2. Decide the codec and call admission control policy. Show the bandwidth arithmetic for a 400-phone office and explain whether G.711 everywhere is acceptable.
Read the worked answer
G.711 everywhere is not acceptable on a 10 Mbps spoke, and the arithmetic shows why. Take the 400-phone regional office at a busy-hour load of roughly 0.15 Erlang per phone: about 60 concurrent calls. G.711 with 20 ms sampling is approximately 80 kbps on the wire per call once IP/RTP/UDP overhead is included, so 60 calls need about 4.8 Mbps. That is nearly half the spoke for voice alone, before business data, before any video, and on a link that is already dropping 1% of packets at peak. Add HQ-to-spoke and spoke-to-spoke hairpinning through Amsterdam and the link becomes the first thing to fail under stress.
Design regions as follows: G.722 for intra-HQ calls (LAN, abundant bandwidth), G.729 across every WAN path at roughly 26 kbps per call, which puts the same 60 calls at about 1.6 Mbps, and G.711 toward each site's local gateway. That last point matters more than people expect: because PSTN calls egress locally, they never consume WAN bandwidth at all, so the WAN only carries site-to-site internal calls.
Configure locations to match physical circuits and set CAC per location rather than trusting regions alone: cap each spoke's audio bandwidth at about 3 Mbps, leave headroom for data, and let CAC reroute or reject rather than let the MPLS link degrade. Enable a region relationship matrix so HQ-to-spoke and spoke-to-spoke both use G.729. Also verify the 1% loss with the carrier before signing off; 1% steady-state loss on voice paths is a quality problem regardless of codec choice, and it will show up as MOS complaints the design cannot fix.
3. Design branch survivability so a WAN failure costs neither internal dialing nor PSTN access, and state the SRST sizing rule you would apply.
Read the worked answer
Put an SRST/MGCP fallback gateway at every site, sized by registered phones, not by concurrent calls. Cisco SRST licensing is per fallback phone, so the 400-phone offices need 400 SRST licenses each and the 120-phone offices need 120; undersizing to 'peak concurrent calls' is a classic failure that only appears during an outage. Use an ISR with DSP resources if you need MTP, conferencing, or transcoding in fallback mode.
In CUCM, assign an SRST reference in each device pool, set MGCP (or SIP) gateway fallback so the local gateway re-registers to the router, and give the fallback config a realistic dial plan: max-ephones and max-dn at or above the site's phone count, ip source-address pointing at the router's LAN interface, and a default-destination to the local PSTN gateway so off-net calls still work.
The subtle requirement is 'no loss of internal dialing'. During fallback, intra-site extension calls work because the router serves them locally, but calls to other sites die. Fix that with an SRST translation rule and dial peers that prepend the destination site code and route the call out the local PSTN gateway. You must confirm with the carrier that inter-site calls over PSTN are permitted and that the DID ranges are reachable from each region, because that is the clause the carrier has already refused once. Finally, test it: pull the WAN link at one 120-phone site and one 400-phone site during business hours and verify registration count, PSTN inbound, PSTN outbound, and cross-site dialing before you sign the acceptance document. SRST that has never been failed over is not a survivability design, it is an assumption.