Supported configurations for Emergency Calling

Sean Gaston

Updated

This article describes supported integrations, methods, and configurations for placing emergency calls over the Bandwidth network. 

IPs and ports

You may use static /32 IP addresses or subnets to send traffic to Bandwidth. FQDNs and DNS hosts are not supported. If your source address has not been configured with Bandwidth, your call may be rejected with a SIP 500 error. IPs cannot be shared across accounts and are unique to the account they are provisioned for. 

Bandwidth only accepts traffic over port 5060; however, by default, your traffic may originate from any port. You also have the option to provide a specific port if you wish to lock your traffic down to only originate from it. If you choose a specific port for your traffic, INVITE requests sourced from other ports will be rejected.

Audio codecs

G711 uLaw/aLaw (codec 0) is the primary supported codec for 911. We recommend sending only this voice codec to avoid any transcoding issues with other codecs. Fax protocols like UDPTL should not be included. Similarly, we also recommend using payload 101 if sending RTP-Events for DTMF inputs.

ANI (calling number) formats

ANI should be formatted as an E.164 number ({+}{country_code}{number}) unless the calling number is provisioned as an AEUI (Alternate End User Identifier), as the AEUI is an alphanumeric value even when it contains only numbers. 

Note: When an AEUI contains only numbers, it may still be prefixed with a “+” in the SIP header as an E.164 number and still be accepted.

Supported SIP header identity and privacy

Supported identity headers:

  • P_ASSERTED (default option)
  • REMOTE_PARTY_ID
  • P_CHARGE_INFO

Bandwidth will pull the address information associated with the TN populated in either P-Asserted-Identity, Remote-Party-ID, or P-Charge-Info headers, based on what you select during your E911 onboarding. To change it, please open a ticket with the Bandwidth Support Team and provide the preferred identity header to prioritize for your calls. In the event your preferred identity header is not present or unreadable, the call will “fail over” to the next available option in the following order of precedence:

P_ASSERTED

  1. If P_ASSERTED is the selected privacy type, Bandwidth will pull the TN from the P-Asserted-Identity field only.
  2. If there's no TN information populated in P-Asserted-Identity, the value in the Remote-Party-ID field will then be used.
  3. If no TN information is populated in Remote-Party-ID, the TN in the From header will be used.

REMOTE_PARTY_ID

  1. If REMOTE_PARTY_ID is the privacy type, the value in the Remote-Party-ID header will then be used as the ANI.
  2. If the Remote-Party-ID header is empty, the TN populated in the From header will be used.

P_CHARGE_INFO

  1. If P_CHARGE_INFO is the privacy type, the value in the P-Charge-Info header will be used as the ANI.
  2. If there's no TN information populated in P-Charge-Info, the value in the Remote-Party-ID header will then be used.
  3. If no TN information is populated in Remote-Party-ID, the TN populated in the P-Asserted-Identity header will be used.
  4. Finally, if there's no value in P-Asserted-Identity, the TN in the From header will be used.

If no information is populated in any of the above fields or the call is delivered anonymously, the call will receive a generic ANI and will be passed to the Emergency Call Center (ECC) for processing for North American countries and territories. Alternatively, you may request that calls from unprovisioned or unknown endpoints are to be rejected. 

Note: Usage of multiple privacy headers (P-Asserted-Identity, Remote-Party-ID, and P-Charge-Info) is not supported. It is recommended to only use the privacy headers you have configured in the Bandwidth App.

Supported methods

  • SIP REFER is not supported. Please use SIP reINVITE instead.
  • SIP REGISTRATION should be turned off.
  • USERNAME/PASSWORD or SIP Authentication should be turned off, as they're not required and may hinder functionality. 
  • SIP OPTIONS are supported but shouldn't be sent more than once in a 60-second period.

Article is closed for comments.