Call Control and Dial Plan Design
Domain 3, Call Control and Dial Plan Design, tests whether you can build a dial plan that routes, transforms, and fails over predictably across Unified CM, UCM Cloud, Webex Calling, and CUBE. Expect questions on digit manipulation and on why a call matched the path it did.
Core rules
- Standardize on +E.164 for enterprise numbers; transform to carrier format only at the egress edge.
- Use partitions and calling search spaces to enforce class of service; the line CSS and the device CSS are evaluated separately.
- Translation patterns rewrite digits for internal short codes; route patterns select the egress path.
- On CUBE, inbound dial peers match the arriving URI or number and outbound dial peers match the destination pattern; preference and digit-strip/prefix do the rewrite.
Webex Calling specifics
The effective dial plan is assembled from the location, the PSTN connection, and the routing choice. Outbound rules use dial patterns; translation patterns handle internal normalization. A local gateway is selected per location when PSTN must break out locally.
Worked example
Site A uses 4-digit extensions 1000–1999 and must reach PSTN as +1 408 555 1xxx. Create a translation pattern 1XXX in a partition reachable from the site CSS, set prefix +1408555 and strip 0. A call to 1234 becomes +14085551234. A route pattern \+1408555XXXX with the PSTN route list then sends it to CUBE. On CUBE, the outbound dial peer matches \+1408555...., strips +1, and sends 4085551234 to the carrier.
Traps
- Assuming route patterns are evaluated in list order; Unified CM selects the most specific match.
- Putting the translation in a partition the calling device's CSS cannot see.
- Stripping too many digits so the carrier receives a truncated number.
- Forgetting that CUBE dial-peer matching is independent of Unified CM and needs its own rewrite.
- Ignoring tail-end hop-off and AAR, which change which gateway actually carries the call.