Post-Acquisition Dial Plan With Overlapping DIDs
A CUCM cluster serves headquarters, whose phones use DNs 2000-2999 and whose DIDs are 212-555-2000 through 212-555-2999. The company acquires West, a site whose PBX used DNs 2000-2499 and whose DIDs are 415-555-2000 through 415-555-2499. Both sites keep their existing carrier numbers; West is being migrated to the same cluster and is reached over an MPLS link through its own CUBE. Requirements: four-digit dialing within and between sites, correct calling-line identity on outbound PSTN calls from West, and no possibility of a West user misdialing into an HQ phone. Once the sites share one cluster, the West engineers discover they can register only the 2000-2499 range in one place, and the migration stalls.
1. Explain why the migration stalled and propose the numbering design that satisfies every stated requirement without changing either carrier's DID range.
Read the worked answer
A single CUCM cluster requires unique directory numbers - a DN is cluster-wide, not site-scoped. HQ already owns 2000-2999, so West's identical 2000-2499 range cannot simply be added; that is the stall.
The workable design is to separate the internal DN from the public number:
- Renumber West internally to 7000-7499 (or any free block outside 2000-2999). Users keep four-digit dialing, both sites are unique, and West's 500 users fit exactly.
- Point each West line's External Phone Number Mask at +1 415 555 2XXX so an outbound PSTN call presents the real West DID, not the internal DN. The mask is what preserves calling-line identity across the whole carrier range.
- For inbound calls, the carrier delivers 4155552XXX to the West CUBE and then to CUCM. Add a translation pattern 4155552XXX in a partition called PT-INBOUND-WEST that rewrites the called number to 7XXX, so the call lands on the correct West line.
- Directory URIs / +E.164 aliases should be set on the West lines as well, which gives a second, collision-free identity for Jabber and future intercompany routing.
Nothing in this design requires the carrier to renumber, and nothing changes HQ's 2000-2999 usage.
2. Where exactly do the inbound translation patterns live - partitions, CSS, and the pattern's own CSS - and what breaks if you put them in a partition every phone can reach?
Read the worked answer
Placement is the whole game here.
- Partition: create PT-INBOUND-WEST and put the 4155552XXX translation patterns in it only (and the equivalent for any other West ranges).
- Calling search space: the 4155552XXX patterns must be reachable from the incoming CSS applied to the West SIP trunk or gateway, and from nothing else. Typical practice is a dedicated CSS such as CSS-PSTN-INBOUND-WEST used as the trunk's inbound CSS.
- The pattern's own CSS must be able to reach the partition holding the West line DNs (7XXX), otherwise the translation succeeds but the resulting number is unreachable and the call still fails - a common and confusing half-fix.
Failure modes if you put the patterns in a partition that ordinary phones can reach:
- A user dials 9-1-415-555-2123. The internal translation matches first, so the call is pulled back into the cluster and terminated internally instead of going to the PSTN; the user believes they called the outside number, and the PSTN billing/CDR record disappears.
- Worse, if the pattern's CSS also contains the PSTN route pattern, the translated call can be routed back out and loop, burning trunk channels until the carrier blocks the number.
- Internal four-digit calls to 2XXX at HQ become ambiguous if any pattern overlaps a live DN range; do not create 415555 2XXX patterns that could match a dialed internal string. Rule: inbound translations are ingress-only objects. They never appear in a phone's CSS.
3. A West user dials 911 from a West desk phone. Trace where the call goes under a naive single-cluster configuration, and describe what you would configure so the PSAP sees a West-appropriate location and the call still completes if the MPLS link is down.
Read the worked answer
Under a naive configuration, 911 is one route pattern in a partition reachable by everyone, pointing at one route list and one gateway - typically the HQ gateway, because HQ was built first. A West 911 call then exits HQ, presents an HQ calling number (or no location at all), and dispatches emergency services to the wrong city. If the MPLS link is down, the call fails completely: the phone can reach neither the route pattern nor the gateway.
The fix has three parts:
- Per-site routing reachability. Build 911 in site-specific partitions and give each site's line CSS only its own copy: PT-EMERG-WEST routes to the West CUBE and its PSTN circuits; PT-EMERG-HQ routes to the HQ gateway. Same digits, different partitions, decided by the phone's CSS (which comes from the device pool).
- Correct location data. Apply calling-party transformation on the 911 route pattern/gateway to substitute a West ELIN, and keep the ELIN records current with the local PSAP. Do not rely on the desk phone's DID for location.
- Survivability. Enable SRST on the West gateway, register the West phones to it as a fallback, and configure a dial-peer pattern on the router so 911 still goes out the local circuit when the cluster is unreachable. Verify that the SRST config actually contains 911 and the local PSTN access, not just internal DNs. Test it: dial 911 from a West phone with the MPLS link administratively shut, and confirm both completion and the ANI the PSAP would receive.