Site Code Collides with Legacy PBX 5-Digit Dialing
Acme runs a two-site Cisco Unified Communications Manager 14 cluster. San Jose extensions are 1000–1999 with DIDs +1 408 555 1XXX; Austin extensions are 2000–2999 with DIDs +1 512 555 2XXX. Internal calls are 4-digit. To reach Austin from San Jose, users dial site code 8 plus the 4-digit extension (8-2000). To reach San Jose from Austin, they dial 7 plus the extension (7-1000). External calls are 9 plus 10 digits, and CUCM globalizes all PSTN numbers to +E.164 before sending them to the CUBE. A legacy PBX at San Jose still uses 5-digit dialing: San Jose users dial 8 plus a 4-digit PBX extension (8-3XXX), handled by a route pattern 8.XXXX in the PSTN-LEGACY partition pointing to a San Jose gateway. The San Jose line CSS order is INTERNAL, PSTN-LEGACY, INTERSITE, PSTN-LOCAL, PSTN-LD. Since a recent change, San Jose users dialing 8-2000 hear reorder, but dialing the full Austin DID +1 512 555 2000 works. No trunk or translation-pattern changes were made.
1. Explain why 8-2000 fails while +1 512 555 2000 succeeds, and identify what the recent change most likely was.
Read the worked answer
Digit analysis compares all candidate patterns that the calling line's CSS can reach. For 8-2000, two patterns can match with equal length: the translation pattern 8.2XXX in INTERSITE (which normalizes to +1 512 555 2XXX) and the route pattern 8.XXXX in PSTN-LEGACY (which sends the call to the legacy PBX gateway). When length ties, CUCM applies the first matching partition in the CSS; PSTN-LEGACY precedes INTERSITE, so the route pattern wins. The PBX gateway receives digits for extension 2000, does not have that extension, and returns a cause that CUCM presents as reorder. The full DID does not match 8.XXXX, so it is handled by a different PSTN route pattern and succeeds. The likely recent change is that the 8.XXXX route pattern and PSTN-LEGACY partition were added or moved above INTERSITE in the San Jose CSS, for example when the legacy PBX was connected.
2. An engineer proposes moving INTERSITE above PSTN-LEGACY in the San Jose CSS. Evaluate that proposal and state whether it fully solves the problem.
Read the worked answer
Moving INTERSITE above PSTN-LEGACY makes the 8.2XXX translation pattern win for 8-2000, so Austin calls work. It does not break 8-3XXX, because 8-3XXX does not match 8.2XXX; it falls through to 8.XXXX and still reaches the PBX. So the proposal fixes the immediate symptom. It is not a complete design fix, though. The broad 8.XXXX route pattern remains a catch-all for any future 8-XXXX number, so a new Austin range such as 3000–3999 would silently be sent to the PBX. The partition order is also replicated in every CSS, and a CSS with a different order will behave differently. A safer change is to narrow PSTN-LEGACY to 8.3XXX and keep INTERSITE as 8.2XXX, or to move the legacy PBX to a site code that does not overlap the inter-site code space. Verify the CSS on every line, not just San Jose lines.
3. The 8.2XXX translation pattern is intended to produce +1 512 555 2XXX. What exact digit manipulation and line settings must be verified for the Austin DID to present correctly on outbound PSTN calls?
Read the worked answer
The translation pattern must add the prefix +1512555 to the four-digit extension. For 2000, that yields +15125552000, which is +1 512 555 2000. A common error is to use +15125552, which produces +151255522000, an invalid 11-digit national number. Verify the called-party transformation and the SIP From/PAI that CUBE sends to the ITSP. On the Austin line, the external phone number mask must produce the same DID, and the line's alerting name/number should be correct for internal calls. Internal calls show the extension because CUCM uses the directory number and alerting name inside the cluster; the PSTN sees the globalized number and the external mask. If the mask or translation pattern is wrong, the call can still complete but present the wrong calling party or be rejected by the carrier.