Unprovisioned emergency call tips and tricks

An unprovisioned emergency call occurs when we don’t have sufficient information to route a call to the local Public Safety Answering Point (PSAP). The following tips and tricks address the most common causes of unprovisioned calls, but they may not include every possible scenario.

If you made a 911 call and it was routed to the National Emergency Call Center (ECC) with incomplete caller data, we suggest replicating the call to 933 in order to obtain the reference code (for the list of reference codes, see The 933 service). A 933 call will also help indicate the type of account that’s being used:

• Reference codes starting with a 1 are for Standard 911 (E911 for VoIP & UC)
• Reference codes starting with a 2 are for Dynamic Location Routing (DLR)
• Reference codes starting with a 3 are for DLR for Microsoft Teams 

Note: Depending on the product you’re using, you may need to send your emergency calls to a different IP than your normal voice calls. To verify the correct 911 Routing IP Addresses, please open a support ticket.

933 Call SIP invite details 

For additional 933 call details, there is an advanced troubleshooting technique where you can get details of the SIP invite, the address used, the expected PSAP, and the 933 reference code emailed to you as a notification. With 933 calls that have notifications enabled, the Bandwidth system automatically puts a copy of the SIP invite details into a notification email sent when a 933 call is made. This way you can test and get the SIP invite details immediately without having to request them via a support ticket. This is especially useful for Dynamic E911 for Microsoft Teams deployments on DLR as you may want to know the specifics of the SIP invite (such as the method parameter or Geolocation info) that Microsoft Teams generated. You can also verify the exact PIDF-LO received on a DLR call to make sure it matches our standardized address.

For information about creating notifications in the 911 Access Portal (Standard 911), see How do I provision emergency notifications in the 911 Access Portal?

For information about creating notifications in the Bandwidth App (DLR and Microsoft Teams), see How do I provision emergency notifications in the Bandwidth App?

Example 933 notification for Standard 911

Example 933 notification for DLR and Microsoft Teams

Multiple products/accounts

Unless IP Traffic Consolidation is enabled for your accounts, you need to verify that you’re sending the call from an IP that’s whitelisted for the account you wish to use. If you need to see which IPs are registered to which accounts, please open a support ticket.

Standard 911

Depending on your SIP peer configuration, you need to:

• Verify that the caller’s number is provided fully in the “From” header or supported privacy types (Reference Code 1A).  
• Verify that the phone number provided in the SIP invite is registered on your account in the 911 Access Portal or the Bandwidth App (Reference code 1A). 

Note: For 911, there’s no check for the telephone number (TN) ownership as we assign call ownership based on the IP the call originated from or the PSTN number the call was sent to.

Dynamic Location Routing (DLR)

Remember that the Endpoint ID is not considered a phone number in itself (even if you’re using phone numbers as Endpoint IDs) but rather a unique identifier referencing the callback number. Therefore, you need to verify that the Endpoint ID provided in the appropriate caller ID header in the SIP invite exactly matches the Endpoint ID registered on your account (Reference codes 2A and 2B). For more information on how to update your endpoints, see this support article.

In addition, Geolocation information is required for every DLR call and can be provided using any of the following methods (for additional information on each method, see our E911 DLR integration and testing guide).

Location by Reference

Verify that the Geolocation ID you’re sending in the Geolocation header is registered (Reference Codes 2B, 2C, 2E). For more information, see this support article.

Location by Value

Verify that the address sent in PIDF-LO exactly matches the standardized address registered as a Geolocation (Reference codes 2B, 2C, 2E). For more information, see this support article or this API guide.

If you’re sending Address Line 2 in PIDF-LO, verify that either it exactly matches the existing Geolocation or the matching Geolocation does not have Address Line 2 registered (Reference Codes 2B, 2C, 2E).

Location with a lat-lon in the Geolocation header

Latitude and Longitude must be within the boundaries of the USA, Canada, territories, and territorial waters (Reference Code 2F).

Note: If the 933 call advises that the latitude-longitude can’t be converted to an address, the call will still route to the appropriate local PSAP as a provisioned call.

Location with a lat-lon in a PIDF-LO attachment

Latitude and Longitude must be within the boundaries of the USA, Canada, territories, and territorial waters (Reference Code 2F).

Note: If the 933 call advises that the latitude-longitude can’t be converted to an address, the call will still route to the appropriate local PSAP as a provisioned call.

Dynamic Location Routing for Microsoft Teams

Remember that the Endpoint ID is not considered a phone number in itself (even if you’re using phone numbers as Endpoint IDs) but rather a unique identifier referencing the callback number. Therefore, it has to exactly match the Endpoint ID registered on your account (Reference Codes 3A, 3F).

Per Microsoft Teams specifications, some calls will be routed to the National Emergency Call Center (ECC) by design to be screened for accurate location ahead of transferring to the local PSAP. Any calls that are screened and transferred to the PSAP will receive code 3G on a 933 call (Reference Code 3G). For more information, see Microsoft’s instructions.

If you’re still having trouble, please open a ticket with your Bandwidth 911 Support Team.