SIP trunk 911 address or callback is wrong: location-to-call-path diagnosis

Freeze the evidence and stop uncoordinated testing

Preserve the timestamp and timezone, site, floor or zone, endpoint, extension, dialed digits, selected outbound route and trunk, originating number, intended callback number, emergency-service record state, notification result and provider case. Redact personal and security-sensitive values in shared evidence.

Do not place or repeat a live 911 call merely to diagnose the configuration. Use the provider's validation workflow or a test explicitly coordinated with the provider and appropriate public-safety authority. Maintain the documented alternative way to reach emergency services while the defect remains open.

Prove direct dialing and emergency-route ownership

Trace the digits from the endpoint through any device dial plan, PBX normalization, class of service and emergency route to the selected trunk. For US multi-line telephone systems in scope, FCC materials address direct 911 dialing without an access prefix and contemporaneous notification; applicability and local duties require competent review.

A successful ordinary outbound call does not prove the emergency route. A dialed 911 attempt sent to the wrong trunk is a routing defect even if that trunk returns a recognizable response.

Reconcile registered or dispatchable location with the calling place

Compare the endpoint's actual calling place with the provider's accepted registered address or dispatchable-location record and the PBX mapping that selects it. Keep account address, billing address, service address, civic validation result and dispatchable location distinct.

FCC materials distinguish fixed and non-fixed interconnected VoIP and require supported location-update methods in covered cases. Nomadic endpoint prompts, network-derived location and administrator updates are service-specific; do not assume that a softphone, VPN or moved desk inherited the correct record.

Reconcile callback identity and internal notification

Identify the number the provider expects to present to emergency services and the number a public-safety callback should reach. Compare it with the PBX emergency caller-ID rule, trunk authorization, provider record and live route inventory without exposing it publicly. A valid-looking caller ID is not proof of an accepted callback mapping.

For covered US MLTS deployments, retain the configured notification recipients, delivery path, timestamp and location content separately from the emergency call route. A notification can succeed while the call or address is wrong, and a correct call does not prove notification.

Separate provider validation from PBX signaling and network health

Ask the provider to confirm the selected number's emergency entitlement, accepted location, validation state, callback mapping and documented test process. Then correlate the PBX route, SIP transaction and provider disposition. Keep a local rejection, provider rejection, national call-center routing and public-safety routing as different outcomes.

Power, broadband, access-circuit, SBC and provider outages can affect interconnected VoIP. Do not treat registration, OPTIONS reachability or a completed ordinary call as proof that the emergency workflow and its location data are ready.

Correct one boundary and conduct coordinated acceptance

Change only the demonstrated owner: endpoint dialing, class of service, emergency route, originating identity, provider number mapping, registered or dispatchable location, notification target or documented location-update workflow. Record who approved the change, provider acceptance, effective time and rollback.

Complete only the coordinated validation process authorized for the selected service and jurisdiction. Preserve the approved method and result, callback and notification evidence when applicable, and outage alternatives. This guide is operational evidence guidance, not legal advice; no site, address, emergency record, PSAP, PBX, endpoint, trunk, call, callback, notification, network path or failover was tested.

Apply the Bulk Solutions provider-specific verification path

For a Bulk Solutions trunk, the 911 and 922 diagnostic uses the provider-documented caller-number formats, 922@sip.bulkvs.com readback and scheduled live-test warning while retaining an independent calling method.