# Setting up a Bandwidth SIP trunk

For voice engineers and telephony administrators configuring a Bandwidth SIP trunk behind a session border controller.

Canonical: https://warmtransfer.net/guides/bandwidth-sip-trunk-setup

Last verified: 2026-09-30

Bandwidth delivers SIP trunking and emergency routing over a mated pair of signaling proxies[^40]. This guide walks through configuring account hierarchy, host peering, media controls, and emergency routing across Cisco CUBE, AudioCodes Mediant, and other SIP entities[^35][^9][^3][^31].

## Before you start

- Bandwidth does not publish its trunk proxy IP addresses in integration guides, so you must request the primary and secondary trunk proxy IP addresses directly from your Bandwidth Implementation Specialist or Bandwidth Support[^37][^40].
- Obtain the IP addresses for Bandwidth's two geographically redundant SBCs for 911 calls[^31].
- Confirm your SBC uses public static IP addresses, because Bandwidth UC trunking does not support SIP registration[^45].
- WarmTransfer's reading of the sources is that static E911 suits numbers used at one fixed location because it binds one address per number, whereas Dynamic Location Routing suits roaming endpoints because it passes location in the SIP INVITE[^21].

## What changes by situation

- Which SBC fronts the trunk? Cisco Unified Border Element (CUBE); AudioCodes Mediant SBC; Another SBC or PBX.
- Which Bandwidth platform is your account on? Legacy North American Platform; Universal Platform.
- How are emergency addresses provisioned? Static E911; Dynamic Location Routing (DLR).

## Step 1: Collect Bandwidth proxy and SBC peering parameters

### Do
Ask your Bandwidth Implementation Specialist or Bandwidth Support for the trunk proxy IP addresses, and obtain the two geographically redundant SBCs for 911 calls[^37][^31]. Verify that your own SBC has a static public IP address assigned, as Bandwidth UC trunking does not support SIP registration[^45]. Prepare to accept and route traffic across a mated pair of signaling proxies[^40].

### Verify
Confirm you have received two trunk proxy IP addresses and two geographically redundant SBCs for 911 calls[^40][^31].

### Rollback
Suggested rollback: No configuration changes have been made; archive or discard the collected IP address details.

## Step 2: Create the Sub-account

### Do
In the Bandwidth App, navigate to Account > Sub-Accounts, fill in the required fields, and click Create Sub-Account[^51]. Every account requires at least one Sub-account, and Bandwidth recommends establishing separate Sub-accounts for development and production environments[^53]. A Sub-account corresponds to the entity known as a Site in the Bandwidth API[^35].

### Verify
Verify that the newly created Sub-account appears in the list under Account > Sub-Accounts[^51].

### Rollback
Delete the Sub-account using Delete Sub-Account under Account > Sub-Accounts after confirming that all Locations have first been removed from it[^52].

## Step 3: Create the Location (SIP Peer)

### Do
Navigate to Account > Locations > Add Location, provide a Name, select the Sub-account created in the previous step, optionally check Default Location, and click Create Location[^38]. In the Bandwidth API hierarchy, a Location is termed a SIP Peer[^35]. Because each phone number inherits the properties and settings of its assigned Location, configure separate Locations for each distinct SBC destination or configuration profile[^46].

### Verify
Verify that the new Location appears listed under the designated Sub-account[^38].

### Rollback
Delete the Location from the Bandwidth App after ensuring all phone numbers have been removed or disconnected[^39].

## Step 4: Configure inbound call origination routing

### Do
Open the Location's Voice settings in the Bandwidth App and enter your SBC public IP address or DNS host in the Voice IP addresses / DNS hosts field[^49]. Set the Traffic Distribution Mechanism to None if using a single IP, Random for distributing across up to 10 IPs, or Sequential failover to attempt up to 10 IPs in the listed order[^56]. Optionally, populate the Failover URI with a backup SIP address or phone number[^34].

### Verify
Confirm that the Voice settings display your public SBC host address and the intended Traffic Distribution Mechanism selection[^56].

### Rollback
Remove the configured IP addresses or hostnames from the Voice IP addresses / DNS hosts field[^49].

## Step 5: Authorise outbound calling IP authentication

### Do
If your organization is contracted for the Unified Communications (UC) product, add your SBC public egress IP addresses into the Location's Termination hosts field in the Bandwidth App; otherwise, submit a support ticket requesting Bandwidth Support to whitelist the source IPs[^55].

### Verify
Verify that all SBC egress IP addresses are visible under Termination hosts or that Bandwidth Support has confirmed closure of the whitelisting request[^55].

### Rollback
Remove the entries from Termination hosts, or open a ticket with Bandwidth Support to remove the IP whitelist entries[^55].

## Step 6: Open firewall ports for signaling and media

### Do
Configure external firewall rules to allow UDP port 5060 for SIP signaling and UDP ports 1024 to 65534 for RTP audio between your SBC and both Bandwidth trunk proxy IP addresses[^58][^40]. Restrict trunk signaling and media to UDP with packet sizes kept within 1350 bytes, as TCP is unsupported[^59]. For the emergency routing SBCs, allow UDP ports 1024 to 64000 for RTP media[^24].

### Verify
Confirm that active firewall policies permit UDP 5060 and UDP 1024 to 65534 to and from both Bandwidth proxy IP addresses, and UDP 1024 to 64000 for emergency RTP[^58][^40][^24].

### Rollback
Suggested rollback: Remove the firewall rules permitting signaling and audio toward the Bandwidth proxy addresses.

## Step 7: Configure SBC trunk peering

**Cisco Unified Border Element (CUBE)**

### Do
Configure dial-peers on Cisco CUBE pointing to both Bandwidth proxy IP addresses as session targets or via a voice class server-group, configuring UDP transport[^40][^59]. Inbound signaling from addresses defined as dial-peer session targets or in voice class server-groups is trusted by default, but any additional signaling addresses must be configured with `ip address trusted list` under `voice service voip`[^9]. Maintain the default CUBE behavior that silently discards untrusted callers[^8]. Restrict dial-peer destinations to explicit phone number ranges or URIs rather than using catch-all patterns such as `destination-pattern.T`[^7].

### Verify
Confirm that inbound INVITE requests from both Bandwidth proxies are accepted, while requests from unlisted IPs are dropped silently without returning SIP responses[^8].

### Rollback
Remove the configured Bandwidth dial-peers and delete any manual entries added to the IP address trusted list under `voice service voip`[^9].

**AudioCodes Mediant SBC**

### Do
On the AudioCodes Mediant SBC, create a Proxy Set containing both Bandwidth proxy IP addresses with UDP configured as the transport type for each, and assign this Proxy Set to the IP Group representing Bandwidth[^3][^59]. Enable Proxy Keep-Alive using SIP OPTIONS so the SBC can detect when a proxy goes offline[^2]. Set the Redundancy Mode to either Parking (staying on the active proxy until failure) or Homing (returning to the highest-priority online proxy)[^4]. Enable Proxy Hot Swap on the Proxy Set to automatically retry failed messages on the alternate proxy to fulfill Bandwidth's requirement for error failover[^1][^33].

### Verify
Check that both proxy entries in the Proxy Set report an online status under the Proxy Keep-Alive monitor[^2].

### Rollback
Unbind the Proxy Set from the IP Group and delete the Proxy Set entry[^3].

**Another SBC or PBX**

### Do
Configure both Bandwidth proxy addresses as outbound targets and permit inbound SIP signaling from both IP addresses[^40]. Disable SIP registration toward Bandwidth[^45]. Use UDP transport and maintain SIP packet sizes under 1350 bytes[^59]. Configure failure routing so the device fails over to the secondary proxy upon encountering SIP error codes[^33]. In the field, common practice involves creating one peer entry per Bandwidth IP, running SIP OPTIONS heartbeats against both, setting priority failover, and dropping traffic from non-Bandwidth IPs[^50].

### Verify
Simulate an outage on the primary Bandwidth proxy and confirm outbound calls fail over to the secondary proxy[^40][^33].

### Rollback
Suggested rollback: Remove the two SIP peer target entries and disable outbound routes directed to Bandwidth.

## Step 8: Normalise headers, codecs, and DTMF parameters

### Do
Format all dialed called party numbers in full E.164 format including the leading plus sign, such as +19192971100[^19]. Format outbound caller ID as E.164 in the From header; if provided, Remote-Party-ID takes precedence, and P-Asserted-Identity and Privacy headers are supported[^5]. Configure codec negotiation to offer G.711 u-law or G.729a (iLBC is supported for inbound calls only)[^57]. Configure DTMF transport using RFC 2833 out-of-band or in-band signaling[^18].

### Verify
Capture an outbound SIP INVITE leaving the SBC and confirm the request URI and caller ID are formatted with a leading plus sign in E.164, with the SDP offer restricted to G.711 u-law or G.729a[^19][^57].

### Rollback
Suggested rollback: Remove the SIP header translation rules and codec restriction profiles from the carrier-facing SBC leg.

## Step 9: Order and assign phone numbers

**Legacy North American Platform**

### Do
In the Bandwidth App, navigate to Numbers > Buy Numbers, select Regular or Toll-free, search for inventory, and choose your numbers[^47]. On the Place & Purchase page, choose the Sub-account and Location, and click Purchase[^47].

### Verify
Verify that the purchased phone numbers appear under the target Location and inherit its origination voice settings[^47][^46].

### Rollback
Move purchased numbers to another Location under Numbers > My Numbers > Actions (supporting batches of up to 5000 NANP numbers with the Configuration or Line Features role), deciding whether existing E911 configuration is migrated or deleted[^43][^44].

**Universal Platform**

### Do
In the Bandwidth App, navigate to Numbers > Buy Numbers, select the contracted country and number type, search for inventory, and choose the desired numbers[^48]. On the Place & Purchase page, assign the Sub-account and Location, optionally select a Voice Configuration Package and Requirements Package, and click Purchase followed by Confirm Purchase[^48].

### Verify
Verify that the ordered numbers appear assigned to the target Location and reflect its inherited settings[^48][^46].

### Rollback
Suggested rollback: Move ordered numbers to another Location if needed.

## Step 10: Provision emergency addresses

**Static E911**

### Do
In the Bandwidth App, navigate to Emergency > E911 Phone Numbers > Add[^26]. Enter the phone numbers manually or upload a CSV file, provide the caller name and geolocation address, and click Add Phone Numbers[^26]. Provision every number prior to placing live traffic, as test calls from unprovisioned numbers are not permitted without prior Bandwidth authorization and may incur fees[^32].

### Verify
Dialing 933 reaches a text-to-speech service that reads back the calling phone number and its provisioned address[^20].

### Rollback
Suggested rollback: Update or remove address assignments from the emergency configuration page.

**Dynamic Location Routing (DLR)**

### Do
Prevalidate each geolocation address and record it in the Bandwidth App before routing live calls[^14]. Create an endpoint record per user with PIDFLOEnabled set to true, an Identifier of 10 to 30 alphanumeric characters matching the INVITE value, a 10-digit NANPA callback number, and a caller name up to 50 characters[^13]. Ensure endpoint identifiers are globally unique across all Bandwidth App accounts to prevent collision errors[^15].

### Verify
Allow time for new or updated geolocations to propagate across Bandwidth call processing servers, which can take several seconds to several minutes, before initiating test calls[^17].

### Rollback
Suggested rollback: Remove or unbind prevalidated geolocations and endpoint records.

## Step 11: Configure the SBC emergency outbound route

**Static E911**

### Do
Configure the two geographically redundant SBCs for 911 calls as primary and secondary or as round-robin targets[^31]. Provide Bandwidth with up to 10 source IP addresses as individual entries without DNS names or subnet ranges[^25]. Restrict media on emergency routes exclusively to G.711 u-law[^28]. Disable SIP registration and authentication, refrain from using SIP REFER, and limit OPTIONS keep-alives to no more than once per 60 seconds[^30]. Ensure the calling number is passed in P-Asserted-Identity, Remote-Party-ID, or From, which Bandwidth evaluates in that priority order[^27]. Configure failover to the alternate 911 SBC upon receiving a SIP 410 response, but do not fail over on a SIP 487[^22].

### Verify
Dialing 933 reaches a service that reads back the calling phone number and its provisioned address[^20].

### Rollback
Suggested rollback: Remove the emergency dial-peer or route only if another working emergency gateway path remains available.

### See also
See also [Setting up CUBE for a carrier SIP trunk](https://warmtransfer.net/knowledge/cube-carrier-trunk-setup).

**Dynamic Location Routing (DLR)**

### Do
Configure the two geographically redundant SBCs for 911 calls as outbound targets[^31]. Include a Geolocation SIP header formatted using Location by Reference: `https://emergency.bandwidth.com/locations/` followed by your account number and location reference[^16]. Keep to Location by Reference unless your SBC can support TCP on emergency routes, because Location by Value requires TCP to handle larger packet sizes and requires an exact match to the validated address[^12]. Send the endpoint Identifier in the INVITE exactly as provisioned[^13]. Ensure the SBC retries against the alternate 911 SBC when receiving a 410 response, avoiding failover on 487[^22].

### Verify
Confirm that the INVITE carries a Geolocation header whose URL is `https://emergency.bandwidth.com/locations/` followed by the account number and the location reference[^16].

### Rollback
Suggested rollback: Remove the Dynamic Location Routing SIP route only if an alternate active emergency path is operational.

### See also
See also [Setting up an AudioCodes SBC for Teams Direct Routing](https://warmtransfer.net/knowledge/audiocodes-teams-direct-routing-setup).

## Step 12: Validate routing with 933 test calls

**Static E911**

### Do
Dialing 933 is limited to one call per minute[^20]. Fail over to the alternate SBC when receiving a 410 response[^22].

### Verify
Confirm that the automated voice reads back the calling phone number and provisioned address, and verify that failover routes to the alternate 911 SBC on a 410 response[^20][^22]. Treat the 933 service as a courtesy check rather than full verification[^20].

### Rollback
Suggested rollback: No configuration change is made during verification testing.

**Dynamic Location Routing (DLR)**

### Do
A Dynamic Location Routing 911 test call has the same parameters and flow as the 933 call except that the user part of the request URI is 911[^11]. If Bandwidth issues a 410 code during testing, verify that the SBC retries the request to the alternate 911 SBC[^22].

### Verify
Dialing 933 reads back the calling phone number and provisioned address[^20]. If an incorrect address is returned on a newly created location, allow several minutes for server propagation and retest[^17].

### Rollback
Suggested rollback: No configuration change is made during verification testing.

## Step 13: Execute live 911 test calling

**Static E911**

### Do
Contact the local Public Safety Answering Point (PSAP) via its non-emergency number in advance to schedule a test window[^23]. Schedule the test outside of lunch hours and avoid 4:00 to 6:00 p.m. local time[^23]. Place the test call only from an address-provisioned number, stating immediately upon connection that the call is a test and not an emergency[^23][^32].

### Verify
Confirm with the PSAP dispatcher that the callback number and physical address displayed match the provisioned record, evaluating caller ID from P-Asserted-Identity, then Remote-Party-ID, then From[^27].

### Rollback
Suggested rollback: No system configuration changes require rollback following a live test call.

**Dynamic Location Routing (DLR)**

### Do
Transmit a test call matching the 933 SIP INVITE parameters, changing the user part of the request URI to 911[^11]. While the account remains in test status, the call is rejected before reaching the PSAP, allowing Bandwidth to evaluate the formatting of the SIP request[^11].

### Verify
Obtain confirmation from Bandwidth that the SIP request was correct[^11].

### Rollback
Suggested rollback: No system configuration changes require rollback following a test call.

## Applicability

Applies to: AudioCodes Mediant Software SBC, Bandwidth UC Trunking, Cisco Unified Border Element (CUBE), Bandwidth E911 Dynamic Location Routing, Bandwidth E911 for Static VoIP, Bandwidth E911, Bandwidth App, Bandwidth SIP trunking (PBX integration), Bandwidth account, TelcoBridges ProSBC, and Bandwidth Dynamic E911 for Microsoft Teams. Deployments: cloud, on-premises, and virtual. Sources checked 2026-09-30. Inbound signaling trust defaults and silent discard behavior apply to Cisco CUBE on IOS XE[^9][^8]. AudioCodes Proxy Set configuration and hot swap behaviors apply to Mediant Software SBC[^3][^1]. Emergency calling claims and phone number movement operations are specific to North America[^31][^43]. Dynamic E911 for Microsoft Teams Direct Routing is not covered in this guide and is documented separately by Bandwidth with distinct transport requirements, including TCP on port 5060[^54].

## What remains uncertain

- Bandwidth's trunk proxy IP addresses are not published in integration guides and must be obtained directly from Bandwidth Support or an Implementation Specialist[^37].
- Removing or editing static E911 phone numbers within the Bandwidth App is not covered by the sources below.
- Deleting or modifying Dynamic Location Routing geolocations and endpoints is not covered by the sources below.
- Reversal procedures for moving non-NANP phone numbers on the Universal Platform are not covered by the sources below.
- Call testing plans for general non-emergency inbound and outbound voice traffic are not covered by the sources below.
- Number porting procedures, API automation, TLS, SRTP, fax, and STIR/SHAKEN configurations are not covered by the sources below.

## Sources

[^1]: With Proxy Hot Swap enabled on an AudioCodes Proxy Set, the device automatically retries a failed message against a redundant proxy in the set. Source: [Configuring Proxy Sets - Mediant Software SBC User's Manual Version 7.4](https://techdocs.audiocodes.com/session-border-controller-sbc/mediant-software-sbc/user-manual/version-740/content/um/Configuring%20Proxy%20Sets.htm), Configuring Proxy Sets, Proxy Hot Swap parameter. Checked 2026-09-30.
[^2]: An AudioCodes Proxy Set can run Proxy Keep-Alive using SIP OPTIONS sent at a user-defined interval, and up to three SIP response codes can be configured as keep-alive failure responses that mark the proxy offline. Source: [Configuring Proxy Sets - Mediant Software SBC User's Manual Version 7.4](https://techdocs.audiocodes.com/session-border-controller-sbc/mediant-software-sbc/user-manual/version-740/content/um/Configuring%20Proxy%20Sets.htm), Configuring Proxy Sets, Proxy Keep-Alive and Keep-Alive Failure Responses parameters. Checked 2026-09-30.
[^3]: On an AudioCodes Mediant SBC a Proxy Set defines the address (IP address or FQDN) and transport type of a SIP server, the transport is selectable per proxy address from UDP, TCP, TLS and SCTP, and the Proxy Set is the destination assigned to an IP Group. Source: [Configuring Proxy Sets - Mediant Software SBC User's Manual Version 7.4](https://techdocs.audiocodes.com/session-border-controller-sbc/mediant-software-sbc/user-manual/version-740/content/um/Configuring%20Proxy%20Sets.htm), Configuring Proxy Sets, introduction and Proxy Address table Transport Type. Checked 2026-09-30.
[^4]: An AudioCodes Proxy Set's redundancy mode is either Parking, where the device stays with a proxy until it fails, or Homing, where the device always tries to use the highest-priority proxy that is online. Source: [Configuring Proxy Sets - Mediant Software SBC User's Manual Version 7.4](https://techdocs.audiocodes.com/session-border-controller-sbc/mediant-software-sbc/user-manual/version-740/content/um/Configuring%20Proxy%20Sets.htm), Configuring Proxy Sets, Redundancy Mode parameter. Checked 2026-09-30.
[^5]: For outbound caller ID on the voice trunk Bandwidth reads the From field, a Remote-Party-ID header takes precedence when present, P-Asserted-Identity and Privacy headers are also supported, and the number must be in E.164 format. Source: [UC trunking integration guide](https://www.bandwidth.com/support/en/articles/12822954-uc-trunking-integration-guide), Features section, Caller ID In/Out. Checked 2026-09-30.
[^6]: A third-party SBC vendor article states that G.711 A-law is universally available on Bandwidth trunks, which Bandwidth's own UC trunking codec list does not include (disputed). Source: [Bandwidth.com SBC Integration](https://telcobridges.com/learning/sip-trunking/bandwidth-sbc-integration/), Codecs section. Checked 2026-09-30.
[^7]: Cisco advises against catch-all dial-peer patterns such as destination-pattern .T on CUBE and recommends routing only known phone number ranges or SIP URIs, because generic patterns raise the likelihood of routing a fraudulent call. Source: [Cisco Guide to Harden Cisco Unified Border Element (CUBE) Enterprise Devices](https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-border-element/220380-cisco-guide-to-harden-cisco-unified-bord.html), Toll-fraud prevention, dial-peer patterns. Checked 2026-09-30.
[^8]: By default CUBE silently discards an inbound call that fails the IP trusted list check; no silent-discard untrusted makes it return an error instead, which Cisco cautions can reveal that the device listens for SIP. Source: [Cisco Guide to Harden Cisco Unified Border Element (CUBE) Enterprise Devices](https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-border-element/220380-cisco-guide-to-harden-cisco-unified-bord.html), Toll-fraud prevention, silent-discard untrusted. Checked 2026-09-30.
[^9]: By default Cisco CUBE trusts inbound connections from the IPv4 and IPv6 addresses configured as dial-peer session targets and in voice class server-groups; further addresses are added with the ip address trusted list command under voice service voip. Source: [Cisco Guide to Harden Cisco Unified Border Element (CUBE) Enterprise Devices](https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-border-element/220380-cisco-guide-to-harden-cisco-unified-bord.html), Toll-fraud prevention, IP address trusted list. Checked 2026-09-30.
[^10]: Bandwidth documents a SIP Authentication (network bridge) option in which a realm and SIP credentials are created under Account > SIP Credentials, the first INVITE is challenged with a 407, and the INVITE is resent with a Proxy-Authorization header (disputed). Source: [SIP Authentication (network bridge) setup and configuration](https://www.bandwidth.com/support/en/articles/12823069-sip-authentication-network-bridge-setup-and-configuration), Realm Creation, SIP Credentials Creation and call-flow sections. Checked 2026-09-30.
[^11]: A Dynamic Location Routing 911 test call has the same parameters and flow as the 933 call except that the user part of the request URI is 911; while the account is in testing the call can be sent without connecting to the PSAP and is rejected, and Bandwidth can confirm the SIP request was correct. Source: [E911 Dynamic Location Routing integration and testing guide](https://www.bandwidth.com/support/en/articles/12822952-e911-dynamic-location-routing-integration-and-testing-guide), 911 test calls section. Checked 2026-09-30.
[^12]: Sending Dynamic Location Routing location by value (a PIDF-LO attachment in the INVITE) requires TCP, because the attachment is likely to make the INVITE too large for a UDP packet, and the address sent must exactly match the standardized address Bandwidth returned at validation. Source: [E911 Dynamic Location Routing integration and testing guide](https://www.bandwidth.com/support/en/articles/12822952-e911-dynamic-location-routing-integration-and-testing-guide), Location by Value section. Checked 2026-09-30.
[^13]: A Dynamic Location Routing endpoint requires PIDFLOEnabled set to true, an Identifier of 10 to 30 alphanumeric characters that matches the SIP INVITE exactly, a 10-digit NANPA-valid CallbackNumber, and a CallerName of at most 50 characters; PreferredLanguage is optional and defaults to English. Source: [E911 Dynamic Location Routing integration and testing guide](https://www.bandwidth.com/support/en/articles/12822952-e911-dynamic-location-routing-integration-and-testing-guide), Endpoints section, attribute table. Checked 2026-09-30.
[^14]: With E911 Dynamic Location Routing every geolocation must be prevalidated and added to the Bandwidth App before a call uses it. Source: [E911 Dynamic Location Routing integration and testing guide](https://www.bandwidth.com/support/en/articles/12822952-e911-dynamic-location-routing-integration-and-testing-guide), Geolocations section. Checked 2026-09-30.
[^15]: A Dynamic Location Routing endpoint identifier must be unique across Bandwidth; entering one already used on another Bandwidth App account returns an error. Source: [E911 Dynamic Location Routing integration and testing guide](https://www.bandwidth.com/support/en/articles/12822952-e911-dynamic-location-routing-integration-and-testing-guide), Endpoints section, uniqueness note. Checked 2026-09-30.
[^16]: Bandwidth recommends Location by Reference for Dynamic Location Routing: the INVITE carries a Geolocation header whose URL is https://emergency.bandwidth.com/locations/ followed by the account number and the location reference, which keeps the INVITE small enough for UDP. Source: [E911 Dynamic Location Routing integration and testing guide](https://www.bandwidth.com/support/en/articles/12822952-e911-dynamic-location-routing-integration-and-testing-guide), Location by Reference section. Checked 2026-09-30.
[^17]: A newly created or updated Dynamic Location Routing geolocation may take several seconds or several minutes to propagate to Bandwidth's 911 call processing servers. Source: [E911 Dynamic Location Routing integration and testing guide](https://www.bandwidth.com/support/en/articles/12822952-e911-dynamic-location-routing-integration-and-testing-guide), Geolocations section, propagation note. Checked 2026-09-30.
[^18]: Bandwidth supports both in-band DTMF and out-of-band DTMF as described in RFC 2833. Source: [PBX integration guide](https://www.bandwidth.com/support/en/articles/12822928-pbx-integration-guide), DTMF statement. Checked 2026-09-30.
[^19]: Bandwidth's UC trunking guide specifies E.164 number format with a leading plus sign, for example +19192971100. Source: [UC trunking integration guide](https://www.bandwidth.com/support/en/articles/12822954-uc-trunking-integration-guide), Attributes section, Dial Plans. Checked 2026-09-30.
[^20]: Dialing 933 reaches a Bandwidth text-to-speech service that reads back the calling phone number and its provisioned address; the static E911 guide limits it to one call per minute and describes it as a courtesy check rather than full verification. Source: [E911 for Static VoIP integration & testing guide](https://www.bandwidth.com/support/en/articles/12822950-e911-for-static-voip-integration-testing-guide), 933 testing service section. Checked 2026-09-30.
[^21]: Because static E911 binds one address to each phone number while Dynamic Location Routing supplies the location in the INVITE at call time, static provisioning suits numbers used at one fixed place and Dynamic Location Routing suits devices that move between places (inferred). Source: [E911 Dynamic Location Routing integration and testing guide](https://www.bandwidth.com/support/en/articles/12822952-e911-dynamic-location-routing-integration-and-testing-guide), Location method sections read together with the static E911 configuration article. Checked 2026-09-30.
[^22]: When a Bandwidth 911 SBC answers with SIP 410 the customer must resend the INVITE to the other 911 SBC, and must not fail over on a 487, which is the normal response to the customer's own CANCEL. Source: [E911 for Static VoIP integration & testing guide](https://www.bandwidth.com/support/en/articles/12822950-e911-for-static-voip-integration-testing-guide), Failover handling and response codes section. Checked 2026-09-30.
[^23]: For a live 911 test call Bandwidth tells customers to schedule it in advance through the PSAP's non-emergency number, to state at once that the call is a test and not an emergency, and to avoid lunch hours and 4:00 to 6:00 p.m. local time. Source: [E911 for Static VoIP integration & testing guide](https://www.bandwidth.com/support/en/articles/12822950-e911-for-static-voip-integration-testing-guide), 911 test call rules section. Checked 2026-09-30.
[^24]: For Bandwidth 911 calls UDP ports 1024 to 64000 should be open for RTP media. Source: [E911 for Static VoIP integration & testing guide](https://www.bandwidth.com/support/en/articles/12822950-e911-for-static-voip-integration-testing-guide), Media/audio section. Checked 2026-09-30.
[^25]: For 911 traffic Bandwidth supports up to 10 customer source IP addresses by default; ranges must be listed as individual addresses, DNS entries are not supported, and additional IPs need approval and incur extra charges. Source: [E911 for Static VoIP integration & testing guide](https://www.bandwidth.com/support/en/articles/12822950-e911-for-static-voip-integration-testing-guide), SIP peer IP configuration section. Checked 2026-09-30.
[^26]: Static E911 is configured in the Bandwidth App under Emergency > E911 Phone Numbers > Add by entering the phone numbers or uploading a CSV, a caller name, and a geolocation address, then clicking Add Phone Numbers. Source: [How do I configure E911 service for my phone numbers in the Bandwidth App?](https://www.bandwidth.com/support/en/articles/12823281-how-do-i-configure-e911-service-for-my-phone-numbers-in-the-bandwidth-app), Steps 1 to 6. Checked 2026-09-30.
[^27]: On a static E911 call Bandwidth looks for the calling number in P-Asserted-Identity (if enabled), then Remote-Party-ID, then From; if none carries one the call gets a generic callback number and is routed to the Emergency Call Center unless unprovisioned calls are denied. Source: [E911 for Static VoIP integration & testing guide](https://www.bandwidth.com/support/en/articles/12822950-e911-for-static-voip-integration-testing-guide), SIP headers and caller ID section. Checked 2026-09-30.
[^28]: For static E911 Bandwidth supports only the G.711 u-law codec, and 911 calls offered with other codecs may fail to establish. Source: [E911 for Static VoIP integration & testing guide](https://www.bandwidth.com/support/en/articles/12822950-e911-for-static-voip-integration-testing-guide), Supported codecs section. Checked 2026-09-30.
[^29]: The static E911 guide gives simulated-failover test calling numbers: 15555558888 when the primary 911 route is ATL and 15555559999 when the primary is DFW. Source: [E911 for Static VoIP integration & testing guide](https://www.bandwidth.com/support/en/articles/12822950-e911-for-static-voip-integration-testing-guide), Simulated failover testing section. Checked 2026-09-30.
[^30]: On the static E911 connection SIP REFER is not supported (re-INVITE is used instead), SIP registration and authentication must be disabled, and OPTIONS messages are supported but should be sent no more than once in a 60-second period. Source: [E911 for Static VoIP integration & testing guide](https://www.bandwidth.com/support/en/articles/12822950-e911-for-static-voip-integration-testing-guide), SIP configuration requirements. Checked 2026-09-30.
[^31]: Bandwidth provides two geographically redundant SBCs for 911 calls, and the customer configures them as primary and secondary or as round-robin targets. Source: [E911 for Static VoIP integration & testing guide](https://www.bandwidth.com/support/en/articles/12822950-e911-for-static-voip-integration-testing-guide), Session Border Controllers (SBCs) section. Checked 2026-09-30.
[^32]: Test calls from an unprovisioned phone number are not permitted unless Bandwidth Support allows them in advance, and they may be charged under the customer's contract. Source: [E911 for Static VoIP integration & testing guide](https://www.bandwidth.com/support/en/articles/12822950-e911-for-static-voip-integration-testing-guide), Unprovisioned call handling section. Checked 2026-09-30.
[^33]: Bandwidth asks customers to be able to fail over to its geo-redundant access point on a variety of SIP error codes when the primary access point is unavailable. Source: [PBX integration guide](https://www.bandwidth.com/support/en/articles/12822928-pbx-integration-guide), Failover statement. Checked 2026-09-30.
[^34]: A Location's Voice settings include a Failover URI field that accepts a SIP address or a phone number. Source: [Managing Locations in the Bandwidth App](https://bandwidth.com/support/en/articles/12823917-how-do-i-manage-locations-in-the-bandwidth-app), Origination Settings section, Failover URI. Checked 2026-09-30.
[^35]: A Bandwidth account is organised as Account, then Sub-account (called Site in the API), then Location (called SIP Peer in the API), with phone numbers assigned to a Location and Sub-account. Source: [Structure](https://dev.bandwidth.com/docs/account/structure/), Structure page, hierarchy and terminology sections. Checked 2026-09-30.
[^36]: Bandwidth's PBX integration guide states that Bandwidth does not use a username and password to authenticate trunk traffic and authenticates only by trusted IP (disputed). Source: [PBX integration guide](https://www.bandwidth.com/support/en/articles/12822928-pbx-integration-guide), Registration and authentication statement. Checked 2026-09-30.
[^37]: Bandwidth's integration guides do not publish the trunk proxy IP addresses; the customer obtains them from their Bandwidth Implementation Specialist or Bandwidth Support. Source: [UC trunking integration guide](https://www.bandwidth.com/support/en/articles/12822954-uc-trunking-integration-guide), IP Information section. Checked 2026-09-30.
[^38]: A Location is created under Account > Locations > Add Location by entering a Name, an optional Description, the Sub-Account it belongs to and an optional Default Location toggle, then clicking Create Location. Source: [Managing Locations in the Bandwidth App](https://bandwidth.com/support/en/articles/12823917-how-do-i-manage-locations-in-the-bandwidth-app), Creating a Location section. Checked 2026-09-30.
[^39]: A Location can be deleted only after every phone number has been removed from it, by moving the numbers elsewhere or disconnecting them. Source: [Managing Locations in the Bandwidth App](https://bandwidth.com/support/en/articles/12823917-how-do-i-manage-locations-in-the-bandwidth-app), Deleting a Location section. Checked 2026-09-30.
[^40]: Bandwidth presents a mated pair of signaling proxies: the customer must allow inbound signaling from both addresses, because a call may arrive from either, and must configure both as outbound targets so calls continue if one is offline. Source: [UC trunking integration guide](https://www.bandwidth.com/support/en/articles/12822954-uc-trunking-integration-guide), IP Information section. Checked 2026-09-30.
[^41]: 47 CFR 9.16 requires a multi-line telephone system to let a user directly initiate a call to 911 from any station without dialing any additional digit, code, prefix or post-fix, and requires a notification initiated contemporaneously with the 911 call that does not delay it. Source: [47 CFR § 9.16 - General obligations for MLTS (Cornell LII republication)](https://www.law.cornell.edu/cfr/text/47/9.16), 47 CFR 9.16(a) and (b)(1)-(2). Checked 2026-09-30.
[^42]: 47 CFR 9.16 requires automated dispatchable location for on-premises fixed MLTS telephones from 6 January 2021, and from 6 January 2022 requires it for non-fixed and off-premises devices when technically feasible, otherwise allowing end-user manual update or alternative or enhanced location information. Source: [47 CFR § 9.16 - General obligations for MLTS (Cornell LII republication)](https://www.law.cornell.edu/cfr/text/47/9.16), 47 CFR 9.16(b)(3). Checked 2026-09-30.
[^43]: Up to 5000 NANP phone numbers can be moved at once between accounts, Sub-accounts and Locations from Numbers > My Numbers > Actions, by a user holding the Configuration or Line Features role, provided the accounts share a Global Account Number. Source: [Moving phone numbers in the Bandwidth App](https://www.bandwidth.com/support/en/articles/12823924-moving-phone-numbers-in-the-bandwidth-app), Prerequisites and Option 1 and Option 2 steps. Checked 2026-09-30.
[^44]: When numbers are moved in the Bandwidth App the operator must choose whether the numbers' E911 configuration is migrated or deleted, and Bandwidth warns that moving numbers to another account may cause service disruption. Source: [Moving phone numbers in the Bandwidth App](https://www.bandwidth.com/support/en/articles/12823924-moving-phone-numbers-in-the-bandwidth-app), Move steps, E911 configuration step and warning. Checked 2026-09-30.
[^45]: Bandwidth UC trunking does not support SIP registration; the customer must present public static IP addresses. Source: [UC trunking integration guide](https://www.bandwidth.com/support/en/articles/12822954-uc-trunking-integration-guide), No Registration section. Checked 2026-09-30.
[^46]: A phone number added to a Location inherits the settings and properties of that Location. Source: [How do I set up my Bandwidth App account?](https://www.bandwidth.com/support/en/articles/12822978-how-do-i-set-up-my-bandwidth-app-account), Locations section. Checked 2026-09-30.
[^47]: On the Legacy North American Platform numbers are ordered under Numbers > Buy Numbers by choosing Regular or Toll-free, searching, selecting numbers, and on the Place & Purchase page choosing the required Sub-account and Location before clicking Purchase. Source: [Searching and ordering phone numbers on the Legacy North American Platform](https://www.bandwidth.com/support/en/articles/12823319-searching-and-ordering-phone-numbers-on-the-legacy-north-american-platform), Steps to begin your order and Selection and checkout sections. Checked 2026-09-30.
[^48]: On the Universal Platform numbers are ordered under Numbers > Buy Numbers by choosing a contracted country and number type, searching, selecting numbers, assigning a Sub-account and Location on the Place & Purchase page with an optional Voice Configuration Package and Requirements Package, then clicking Purchase and Confirm Purchase. Source: [Searching and ordering phone numbers on the Universal Platform](https://www.bandwidth.com/support/en/articles/12823405-searching-and-ordering-phone-numbers-on-the-universal-platform), Ordering steps 1 to 10. Checked 2026-09-30.
[^49]: Inbound (origination) delivery is configured on the Location's Voice tab in the field Voice IP addresses / DNS hosts, which takes the customer endpoint IP address or DNS host. Source: [Managing Locations in the Bandwidth App](https://bandwidth.com/support/en/articles/12823917-how-do-i-manage-locations-in-the-bandwidth-app), Origination Settings section. Checked 2026-09-30.
[^50]: One SBC vendor's Bandwidth integration article recommends defining one peer entry per Bandwidth proxy address, enabling SIP OPTIONS heartbeats toward both, ordering routes so traffic advances to the second address when the first stops responding, and dropping inbound SIP from every source other than the two Bandwidth addresses (field report). Source: [Bandwidth.com SBC Integration](https://telcobridges.com/learning/sip-trunking/bandwidth-sbc-integration/), NAP, SIP OPTIONS keepalive, failover and access-control sections. Checked 2026-09-30.
[^51]: A Sub-account is created in the Bandwidth App under Account > Sub-Accounts by completing the required fields and clicking Create Sub-Account. Source: [How do I manage Sub-accounts in the Bandwidth App?](https://www.bandwidth.com/support/en/articles/12823932-how-do-i-manage-sub-accounts-in-the-bandwidth-app), Creating a Sub-account section. Checked 2026-09-30.
[^52]: A Sub-account can be deleted only after all Locations have been removed from it; the control is Delete Sub-Account under Account > Sub-Accounts. Source: [How do I manage Sub-accounts in the Bandwidth App?](https://www.bandwidth.com/support/en/articles/12823932-how-do-i-manage-sub-accounts-in-the-bandwidth-app), Deleting a Sub-account section. Checked 2026-09-30.
[^53]: Every Bandwidth account must have at least one Sub-account, and Bandwidth recommends separate Sub-accounts for development and production. Source: [How do I set up my Bandwidth App account?](https://www.bandwidth.com/support/en/articles/12822978-how-do-i-set-up-my-bandwidth-app-account), Sub-accounts section. Checked 2026-09-30.
[^54]: Bandwidth publishes a separate Dynamic E911 for Microsoft Teams guide in which the SBC must support TCP on port 5060, emergency addresses are configured in Teams, and endpoints are provisioned in the Bandwidth App. Source: [Dynamic E911 for Microsoft Teams integration and testing guide](https://www.bandwidth.com/support/en/articles/12822946-dynamic-e911-for-microsoft-teams-integration-and-testing-guide), Overview and SBC requirements. Checked 2026-09-30.
[^55]: Customers contracted for the Unified Communications (UC) product enter the IPs that send outbound calls in the Location's Termination hosts field; other customers must open a support ticket to have their IPs whitelisted. Source: [Managing Locations in the Bandwidth App](https://bandwidth.com/support/en/articles/12823917-how-do-i-manage-locations-in-the-bandwidth-app), Termination Settings section. Checked 2026-09-30.
[^56]: A Location's Traffic Distribution Mechanism offers None (one IP), Random (up to 10 IPs) and Sequential failover (up to 10 IPs, tried in the order entered). Source: [Managing Locations in the Bandwidth App](https://bandwidth.com/support/en/articles/12823917-how-do-i-manage-locations-in-the-bandwidth-app), Origination Settings section, Traffic Distribution Mechanism. Checked 2026-09-30.
[^57]: Bandwidth's UC trunking guide lists G.711 u-law and G.729a as fully supported codecs and iLBC as supported inbound only. Source: [UC trunking integration guide](https://www.bandwidth.com/support/en/articles/12822954-uc-trunking-integration-guide), Attributes section, Supported Codecs. Checked 2026-09-30.
[^58]: For the voice trunk, UDP port 5060 must be open for SIP signaling and UDP ports 1024 to 65534 must be open, statically or dynamically through an ALG, for audio. Source: [UC trunking integration guide](https://www.bandwidth.com/support/en/articles/12822954-uc-trunking-integration-guide), Ports to be Opened section. Checked 2026-09-30.
[^59]: Bandwidth requires all SIP and audio on the trunk to be delivered over UDP in packets no larger than 1350 bytes; TCP is not supported. Source: [PBX integration guide](https://www.bandwidth.com/support/en/articles/12822928-pbx-integration-guide), Transport protocol statement. Checked 2026-09-30.