VoIP.info Troubleshooting

Bulk Solutions 911 or 922 is rejected or reports the wrong address

Trace one Bulk Solutions emergency-calling attempt from provisioned number and address through caller identity, trunk authentication, Request-URI, provider response, 922 readback and approved live-test procedure.

Reviewed 2026-10-18Current Bulk Solutions E911 FAQ, testing, country, address-change, outbound-IP, webhook and SMS guidance reviewed October 14, 2026; the provider recommends 922@sip.bulkvs.com to verify the caller number and database address, documents 911@sip.bulkvs.com for emergency calls and warns that some localities require advance scheduling or can penalize unscheduled live 911 tests; no account, portal, DID, address, caller identity, route, PBX, SIP transaction, notification, operator, emergency centre or live call was inspected or testedAdvancedDocumentation based · not lab tested

Protect emergency access before collecting evidence

If emergency calling is unavailable or the location is wrong, treat that as a service-impacting safety condition. Keep an accessible independent calling method at the affected site, notify the responsible service owner and do not use a live 911 call merely as a connectivity test. Record the site, user population, affected callback number, intended civic address, timezone, test authorization and restoration owner without publishing private location or credential data.

Bulk Solutions recommends 922@sip.bulkvs.com for database verification. Its live-test instructions say some localities require advance scheduling and may impose penalties for unscheduled calls. Follow the provider and local authority procedure before any live operator test.

Bind the number to one current emergency record

Confirm that the exact calling number is present in the selected account and associated with the intended current emergency address. Bulk Solutions documents E911 service for the United States and Canada and permits an address associated with an E911 number to be changed; those statements do not prove that one DID is active, validated or propagated.

Preserve the number, normalized address, last change time, responsible account and provider-visible state. A correct PBX extension label, outbound caller-name value or ordinary PSTN caller-ID display is not proof of the emergency database record or callback identity.

Trace the emergency call on the authorized trunk path

For the documented IP-authenticated path, verify the public source address is authorized and that the PBX uses the provider hostname rather than treating one published SBC address as the service. For a credentialed trunk, preserve the INVITE challenge and authenticated retry separately from any REGISTER state.

Record the exact Request-URI, From and asserted identity fields, Call-ID, source and destination tuples, first provider response and the route or trunk selected by the PBX. Bulk Solutions documents 911@sip.bulkvs.com for emergency calls and 922@sip.bulkvs.com for database verification. A successful ordinary call does not prove either emergency destination uses the same caller identity or policy.

Use one of the documented caller-number formats

The outbound IP-authentication guide says the E911 caller ID must be the provisioned number in 10-digit, 11-digit or +1 E.164 form and that other formats are rejected. Compare the actual transmitted identity with the account number instead of changing several caller-ID layers at once.

Keep channel caller ID, P-Asserted-Identity or other network identity, provider authorization, emergency database key, ANI, ALI and operator callback number as separate observations. Correct the earliest mismatch, then repeat the 922 verification before considering a live 911 test.

Interpret 922 and notification evidence narrowly

Record the complete 922 announcement: number recognized, address read back, rejection or other result. A correct readback is evidence for that provider verification attempt; it is not proof that a live emergency operator received properly ordered ANI and ALI fields, that every PBX route works or that the endpoint can complete two-way audio.

Bulk Solutions documents optional webhook and per-number SMS notifications for 911 or 922 attempts. Preserve the provider payload, timestamp, calling number, result, receiving endpoint and acknowledgement separately. A sent notification is not proof that a server accepted it, that an SMS arrived or that a person acted on it.

Run an authorized live test and restoration review only when required

If policy requires a live operator test, schedule or authorize it with the relevant local authority and follow the provider script. Confirm the received ANI, displayed address, callback number and field ordering, then end the call promptly. Do not place repeated or unscheduled emergency calls to diagnose SIP routing.

Afterward, verify the normal outbound route, keep the independent emergency method available, document future address-change ownership and repeat the provider-approved verification after DID, site, trunk, caller-identity or routing changes. No Bulk Solutions account, DID, address, PBX, 922 call, 911 call, notification or emergency centre was tested for this diagnostic.

Do not use emergency calls to test a missing inbound DID

Repair and accept the ordinary inbound path with the Bulk Solutions DID diagnostic, then retain 922 and any authorized live emergency test as separate evidence.

Sources & applicability

Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.

Examples require adaptation to your topology. No live PBX or hardware testing is claimed.