Bandwidth 911 implementation guideFollow
Configuring your 911 services
Session Border Controllers (SBCs)
Bandwidth has two geographically redundant SBCs to send 911 calls to. Routing should be set up as primary/secondary or round-robin. Please reach out to your Implementation Specialist to obtain the specific IPs or open a support ticket in the Bandwidth Support Center.
Bandwidth supports the provisioning of IP addresses for 911 routing. Ranges must be separated out, and DNS entries are not supported. By default, Bandwidth allows up to 10 IPs for sending 911 traffic. Additional IPs beyond that are subject to approval and additional charges.
Note: To add new IPs, please reach out to your Implementation Specialist, if you are currently working with one. If not, please open a support ticket in the Bandwidth Support Center.
Bandwidth only supports the G.711 u-law codec for 911. While a call may still traverse the Bandwidth SBC with a different codec, there is no guarantee that a codec other than G.711 u-law will be established properly, potentially causing the call to fail.
Supported privacy types
SIP peers can be configured with the following privacy types:
Bandwidth will automatically search the Remote-Party-ID and From headers. If the P-Asserted-Identity option is set on the trunk group, Bandwidth will also search that header. Headers are preferred in this order:
- P-Asserted-Identity (if P-Asserted-Identity option is set on the trunk group)
Bandwidth only supports one P-Asserted-Identity header, which must have a sip URI, not a tel URI.
Bandwidth also supports P-Charge-Info as a caller-identifying header. You must notify your Implementation Specialist if want Bandwidth to use P-Charge-Info. If P-Charge-Info is enabled, the caller identifier will be pulled from SIP headers in the following order:
- P-Asserted-Identity (if P-Asserted-Identity option is set on the trunk group)
If no information is populated in any of the above fields, the call will receive a generic callback number and will be passed to the Emergency Call Center (ECC) for processing, unless you have requested that unprovisioned calls be denied.
Populating values in all privacy headers (P-Asserted-Identity, Remote-Party-ID, and P-Charge-Info) is not recommended.
Ports 1024-64000 UDP should be open for RTP Media. If you require the Media IPs, please reach out to your Implementation Specialist.
Other SIP configurations and supported methods
- SIP REFER is not supported; please use SIP REINVITE.
- SIP registration should be turned off.
- SIP authentication (username/password) should be disabled as it is not required
and may hinder functionality.
- OPTIONS messages are supported, but should not be sent more than once in a 60
Testing your Bandwidth 911 configuration
Once you’ve completed your Bandwidth 911 configuration, it’s time to test it. The steps below are all you need to properly test your setup and make sure you can successfully support 911 calls.
Interoperability testing steps
Once all the technical requirements and setup are completed, testing for 911 functionality is an easy 3-step process. Please review the 3-step process and sample invites below before moving forward with sending Bandwidth production traffic.
1. Provision a 911 Endpoint
Provision the endpoint with a valid address in the 911 Dashboard.
2. Make a 933 Call
Bandwidth provides a text-to-speech service for partial 911 testing. You may need to add 933 to your dial plan in order for the call to be made. This service, when called, will read back the telephone number and address that is provisioned in the 911 Dashboard.
The 933 test will perform the following validation checks:
- The endpoint is properly provisioned
- Basic interop to the Bandwidth SBC chosen
- One-way audio
To call the 933 service, just send the SIP INVITE to 933 instead of 911.
3. Complete Live 911 Testing
Before completing, please confirm that you’re able to do the following:
- Send a SIP INVITE to 933 and receive the automated recording that reads back the provisioned address.
- Initiate a 911 call from a specific ANI. This ANI should be set in the From or P-Asserted-Identity fields in the SIP INVITE.
- Failover to an alternate data center when you receive a SIP 410 response from a 911 SIP INVITE.
Simulated failover testing
This test will validate your system’s ability to successfully redirect failed calls to your secondary route.
During this test we will simulate a scenario in which your 911 call is sent to your primary route and will then fail with a SIP 410 response. When you receive a 410 response, you should send the SIP INVITE to the opposite data center.
To complete testing, simply make a call from the following ANIs:
- If ATL is the primary, 15555558888
- If DFW is the primary, 15555559999
Once you’re setup to do these things, you’re ready to migrate traffic. Please notify us if you require any assistance with the migration of services.
Note: if the 933 call isn't successful, please halt testing and open a ticket with your Bandwidth Support Team.
Handling SBC failures
- In the event of a live SBC failure, the Bandwidth SBC may respond with a 4xx, 5xx, or 6xx SIP status, or won't respond at all (in the case of a hard-down situation).
- The non-response or the error message must be handled appropriately on the customer side to fail over to the other functioning SBC.
- The one exception is a 487 response, which is a normal response to you sending a CANCEL for the call. If you receive a 487, do not fail over to the alternate SBC.
The sample invite is for a 911 call. A 933 INVITE is exactly the same, just replace “911” with “933”. See below for a description of 933 service.
INVITE sip:911@XXX.XX.XXX.XX.10:5060 SIP/2.0
CSeq: 8573 INVITE
Via: SIP/2.0/UDP X.X.X.X:5060;branch=z9hG4bK4E45.9098.A4198573
o=- 23714 23714 IN IP4 X.X.X.X
c=IN IP4 X.X.X.X
m=audio 29740 RTP/AVP 0 101
Tips for successful 911 test calls
The PSAP testing instructions listed below are helpful suggestions for placing test calls to a PSAP. Test calls from an unprovisioned phone number are not permitted, unless specifically permitted ahead of time by your Bandwidth support team and may be charged for at the rate specified in the customer contract.
Do's and don'ts when making 911 test calls
- It is a best practice to call the 10-digit non-emergency PSAP number that will be utilized in your testing and advise the 911 operator that you will be conducting 911 test calls in advance of any testing. Many larger PSAPs will request that you schedule testing with them during what are typically less busy hours. The non-emergency number of the PSAP can be obtained in the Bandwidth 911 Dashboard, while in the emergency endpoint. If you need assistance with this, please open a support ticket with us.
- When calling 911, IMMEDIATELY state, “This is NOT an emergency; this is a test. Do you have a few minutes to review my information with me?”
- If no, say “Thank you, goodbye” and immediately hang up. Try back at a less busy time, or schedule the test call as mentioned previously.
- If yes, ask your questions quickly, and end the call.
- Do expect the PSAP operators to be abrupt, as you could be blocking a life threatening call.
- Do not call during the busy hour of lunch, or between 4:00 p.m. - 6:00 p.m. in your local time zone or the location for which you are testing.
- Try to call during off-hours such as 6:00 a.m.
General information regarding a PSAP test call
- Ensuring that your 911 service testing is successful is extremely important. However, you should appreciate that Test Calls demand a 911 operator’s attention. So, please remember that an actual emergency situation must take precedence over test calls.
- PSAPs have limited trunking and stations.
- Generally, PSAP turnover is high, which could result in staffing and training not being adequate.
- Bandwidth has a comprehensive list of PSAP administrative contacts. If you have trouble with a specific PSAP, feel free to report it by opening a ticket with the support team. The support team will review the call recording, and clarify the situation with a supervisor or appropriate member of the PSAP team.
Additional information regarding 933 service
The 933 service is a courtesy text-to-speech service that Bandwidth offers as part of the 911 package. When an end user dials 933, it will play back the phone number and address provisioned in the dashboard. This service is used as part of the 911 testing performed during the onboarding process, prior to the live 911 calls, and is used primarily to test connectivity to the emergency IPs for 911 service. Secondarily, it tests to make sure the provisioned address is being broadcast.
As with any text-to-speech service, there may be parts that are not appropriately recognized and therefore skipped in the playback. The point to using the 933 service is to verify that:
- Calls are reaching the SBCs
- Some resemblance of the address provided in the Bandwidth 911 Dashboard is being represented
For example, if the 911 address entered is “123 N Main St, Ste 400, Denver Colorado 80205”, the 933 service would likely read back “123 Main, Denver Colorado 80205”. This would be considered a successful call. If it read back something entirely different, such as “2963 Stormy Ave, El Paso TX”, this would indicate a problem either with the 933 service or with the address in the Bandwidth 911 Dashboard.
The 933 service may be used any time (please limit calls to 1 call per minute). However it is a courtesy service and is not meant to be used as a fully functional address verification service. To verify a full address, it is best to check the provisioned address in the Bandwidth 911 Dashboard directly (or via an API call).
Was this article helpful?
3 out of 3 found this helpful