Dial plan and number presentation for three countries
A manufacturer runs a CUCM 14 cluster in Frankfurt serving Germany (extensions 1XXX), France (2XXX) and the United States (3XXX). Germany and France egress through a CUBE to a German carrier that requires called numbers in national format - a leading 0 for domestic and 00 for international - and rejects anything else with a 404. The US site runs its own CUBE with a carrier that requires 10-digit national numbers and rejects a leading +. All sites must present +E.164 calling numbers on-net and toward each other, users must be able to dial local PSTN numbers exactly as they would from a home phone, and the corporate directory must show +E.164. Emergency calls must reach the correct local PSAP, including for staff visiting another country.
1. Design the on-net versus off-net dial plan so that 4-digit internal dialing never collides with variable-length PSTN dialing, and state where you normalize to E.164. What is the risk of the obvious '9.!' route pattern?
Read the worked answer
On-net lives in an internal partition reachable from every CSS: translation/route patterns 1XXX, 2XXX, 3XXX with Urgent Priority unchecked but no access code. Each site's DNs are DIDs in E.164 form, and the DN's external phone number mask (e.g. +49 69 1234 1XXX) gives the +E.164 display.
Off-net is forced behind a single access code (9) in a separate partition, so a 4-digit extension can never be mistaken for a PSTN number. Normalize at the edge of the dial plan, not at the trunk: translation pattern 9.! that strips 9 and prefixes the correct country code based on the calling site's CSS (a Frankfurt CSS prefixes +49, a Paris CSS +33), then route on a single \+.! route pattern in a route group per country. This gives you one place to change number policy and keeps CDRs and the directory in E.164.
The risk of 9. + the ! wildcard is the interdigit timeout: CUCM cannot know the number is complete, so every call waits for the interdigit T302 timer (default 15 s unless trimmed) before routing. Users perceive this as a broken dial tone. Mitigations: use the # end-of-dialing character in the pattern for trained users, drop the interdigit timer to 3–4 s in the clusterwide service parameters, and use 9.@ only where the NANP macro actually fits (the US site, 10/11 digits) - @ does not model German variable-length numbering.
Sequence matters: the 4-digit internal patterns must be unambiguous (they are, by digit count) so a 9-led number can never partially match an internal pattern.
2. The German carrier rejects '+' while the directory and on-net display must stay +E.164. Name each transformation point and what goes there.
Read the worked answer
Keep E.164 as the single internal truth and transform only at the point of mismatch. Three distinct points:
- Called party, at egress to the German carrier. A called-party transformation pattern pointing at the SIP trunk rewrites
+49XXXXXXXXX→0XXXXXXXXXand+CC...(non-German) →00CC.... Crucially this sits on the trunk/route pattern, not in the translation pattern, so the US trunk can apply its own rule (strip +, keep 10 digits) without touching the shared dial plan. Give the trunk a calling search space that can see the transformation partition. - Calling party, at egress. A calling-party transformation CSS on the same trunk rewrites the +49 main number to the national form the carrier bills against. Apply it on the trunk, not on the DN.
- Display, inside the enterprise. The DN's external phone number mask and the directory URI carry +E.164, and no transformation CSS is applied on the internal patterns, so internal calls always show +E.164 regardless of what the trunks send outward.
For the US CUBE, the equivalent rule strips the leading + and keeps the 10-digit NANP number; the calling-party transformation must also keep the NANP format the carrier expects.
Validate each one from the CUCM CDR and a SIP ladder on the CUBE: you want the INVITE leaving the cluster to already be in the carrier's required format, so you can prove the cluster did the work and the CUBE is only policing. If you find yourself putting digit manipulation on the gateway, you have split the policy across two systems and the next carrier change will break the dial plan.
3. How do you guarantee emergency calls reach the right PSAP for both local staff and a Frankfurt employee working in Paris for the week?
Read the worked answer
Emergency routing must follow the physical location of the phone, not the user's home site. Build one route pattern per emergency string per country (112 for DE/FR, 911 for US) in a partition that only the site's device CSS can reach, each pointing to that site's local gateway route group. A Frankfurt phone in Frankfurt resolves 112 to the Frankfurt route group.
For the traveler, the phone stays registered to the cluster over the WAN and its device CSS does not change, so it would still route to the Frankfurt gateway - the call would arrive at a Frankfurt PSAP for a caller in Paris, with no usable location data. Fix with Device Mobility: put the visiting phone's device pool in the Device Mobility Group for the visited site so that, based on its IP subnet (device mobility group / roaming device pool), CUCM swaps in the visited site's device pool, CSS and location for the duration of the visit. The emergency route then resolves to the Paris gateway.
Additional controls worth stating:
- Block access to the emergency patterns from any CSS that is not site-scoped, so a misconfigured device pool cannot send a Paris caller to a Frankfurt PSAP.
- In the US, pair the route with ELIN/ALI configuration so the PSAP receives a callbackable number tied to the building.
- Remove or transform conflicting digits at the trunk (e.g. the German carrier's handling of 112 vs. the local legacy emergency number) and test from a phone actively registered in each visited site.