Infrastructure and Design
Start with the cluster
Every design question resolves back to the CUCM cluster: one publisher, one or more subscribers, database replication, and Cisco Unified Communications Manager groups that give each device an ordered list of call-processing nodes. A CUCM group is failover, not load balancing - a registered device stays on its first node until that node becomes unavailable. Devices inherit the group from a device pool, alongside region, location, date/time group, and SRST reference, so questions about "where does this setting come from" usually end at the device pool.
Pick the deployment model deliberately
- Single site: one cluster, LAN-quality everything.
- Multisite centralized call processing: one cluster, remote sites over the WAN, survivability via SRST, bandwidth controlled by locations-based CAC.
- Distributed: clusters at each site, stitched with intercluster trunks, ILS, or SAF.
- Cluster over WAN: supported only within documented latency and node limits - never design it for high-latency or low-bandwidth links.
Common traps
Questions conflate 1:1 redundancy (two nodes backing each other up) with 1:N (one standby for several primaries), assume a cluster over WAN is fine "because the WAN is MPLS," and hide a bandwidth problem behind the word QoS. QoS prioritizes; it does not create bandwidth. Watch codec math too: G.711 is roughly 80 kbps per call at Layer 3, G.729 roughly 26 kbps, and CAC counts calls, not megabytes.
Rule of thumb
Before sizing anything, write down four answers: how many sites, how many concurrent calls per site, what happens to calls if the WAN dies, and which emergency/recording rules apply. Those answers select the model.