Post-Merger 4-Digit Collisions, Carrier SIP Formatting, and Site-Correct 911

The collision is a namespace problem, so the fix must create a unique global identity for every extension while leaving the local experience alone. Globalize first: assign every line a unique +E.164 number built from its DID, and make that the only canonical form inside the cluster. Everything else is presentation.

Three options. Option one, partitions per site with each site's 3xxx and 4xxx in a site-specific partition and a device CSS that searches only the home site's partition plus the global partition. Intra-site four-digit dialing keeps working untouched, but cross-site four-digit dialing is impossible forever, and any user who moves desk inherits silence. Option two, close the partition with translation patterns in a global partition so 3XXX resolves to +1212... at the Acme sites and +1718... at the Bolt sites. This fixes the reorder only for calls originating inside the matching site; a Bolt user dialing an Acme 3xxx still has no deterministic answer. Option three, a site access code: keep four digits locally and require a two-digit site prefix plus four digits for cross-site dialing (71-3xxx for Acme, 82-3xxx for Bolt), implemented with translation patterns to +E.164 and a global dial-rule announcement.

Recommend option three layered on option one: the home-site partition keeps four-digit dialing exactly as today, and the site prefixes give operators a deterministic cross-site path. Migrate the translation patterns first and verify with test calls in both directions before you touch any device CSS, because CSS ordering is where this kind of change goes wrong. Publish the prefix map internally; users tolerate a new cross-site pattern far better than a busy signal.

Two separate problems wearing one costume. The carrier's formatting requirement is a transformation problem, and the redirecting identity is a header problem.

For the calling number: because globalized +E.164 is the internal form, every outbound call must be converted at the boundary. Do it on the trunk, not on 10,000 devices, using a calling party transformation pattern on the SIP trunk to strip '+' and render 10-digit national format. Set device-level external phone number masks only where a device must present a specific DID that differs from its line, and be aware the mask affects the calling line only, not translation. Test with all four DID shapes you own: 212 and 718, plus the two block sizes, because a single greedy pattern that looks correct for 212 will silently mangle 718.

For the forwarded call showing the HQ main number: the carrier is receiving the last diverting hop rather than the original redirecting party. Check that the SIP profile used by the trunk has outbound redirecting diversion header delivery enabled, that the forwarding CSS does not rewrite the calling party at the forwarder, and that any mid-call transformation is not applied to the diversion identity. Then confirm with the carrier what they expect in the Diversion header: the original redirecting number and the reason, not the final destination. Get a packet capture at the CUBE and a carrier-side trace for the same call; guessing which side drops the header is how these tickets live for weeks.

For emergency-adjacent calls later, keep in mind that the same transformation machinery can rewrite 911 caller identity and break ALI lookups, so build the emergency path to bypass these transformations entirely.

The failure tells you the 911 pattern is being matched by a device CSS that is not site-scoped, so every caller inherits the HQ route. Fix it at the level that cannot be overridden by the line: the device CSS on each phone, which governs emergency patterns, plus a site-specific partition.

Design: create a partition per site, for example PT_EMERG_ACME_A and PT_EMERG_BOLT_B, each holding a route pattern for 911 and 9911 pointing at that site's local gateway. Add the site's emergency partition to the phone device CSS only, never to a shared line CSS that a user's login or extension mobility could swap out. Keep the emergency gateways in partitions that no ordinary route pattern can reach, so a misconfigured CSS cannot send an emergency call across the WAN.

Then make the ALI data true. Register a site-specific ELIN for each gateway with the PSAP that serves that street address, and arrange for the 911 call to present the ELIN rather than the caller's DID, because DIDs in this estate are not tied to physical locations. That means the 911 path must bypass the trunk calling-party transformation you built for normal calls; put the emergency route in its own partition with no transformation applied, or the ALI record will not match and the dispatcher gets the wrong address.

Finally, validate rather than assume: test calls with the PSAP on a scheduled, non-emergency line for both Bolt sites, confirm the address the dispatcher sees, and record the ELIN, gateway, and PSAP mapping in the runbook. Do the street-address check with facilities, not with the phone inventory, because the inventory is wrong more often than anyone expects.