IP traffic consolidation integration guide

Sarah Krawiec

This guide explains how to route calls for multiple Emergency Services accounts via a single IP using Bandwidth’s IP Traffic Consolidation feature. With this feature, you can simplify certain aspects of interconnection by combining multiple accounts into a “family” that shares endpoint and address data.

Consolidated routing 

Currently, you must have a separate account for each type of 911 routing you use, Standard or Nomadic (DLR, DLR for TEAMS, EC API, etc). Each account also needs to have a source IP configured to send that traffic to Bandwidth. These source IPs can only be used one time, meaning each configured account would need at least one unique source IP. The IP Traffic Consolidation feature enablement on an account level removes this requirement by creating a singular pipeline to provide a routing path where historically individual pipelines were required. This means that a Standard VoIP E911 call with a static location (without PIDF-LO) can be sent along the same interconnect as a Nomadic VoIP 911 call with a non-static location (with a geolocation header or PIDF-LO), and Bandwidth will “parse the SIP invite” and automatically send the static calls to the Standard 911 account and the non-static calls to the Nomadic account for processing.

               

Endpoint management

When IP Traffic Consolidation is enabled, only one instance of each unique telephone number (TN) needs to be provisioned into one of the accounts as shown below.

The immediate benefit of this arrangement is that an emergency call can be made from each TN from either a static or non-static location. If a 911 call is made using a simple SIP INVITE with the user’s TN in the FROM or P-ASSERTED ID fields, then the static address that is registered for that TN will be used to process the call in the usual way. Alternatively, if the user’s TN is calling from a new non-static location, then the SIP INVITE would additionally contain the geolocation header (optionally with PIDF-LO), identifying the current location of the user. The non-static location will override the static location that is normally associated with the user’s TN. 

Account setup and configuration

Using a single endpoint record for both Nomadic DLR and Standard:

The endpoint is provisioned as a DLR endpoint:

  • The endpoint must be registered in 11-digit format and contain only numbers
  • Calls sent with PIDF-LO must send 11-digit numbers in the SIP URIs
  • Calls that would "failover" or be sent as a static location can be sent in either 10 or 11-digit format
  • If no PIDF-LO is present, the static location (tied to the endpoint) is used
  • If PIDF-LO is present and matches a registered location, the non-static location is used

Note: If the endpoint is provisioned in Microsoft Teams, it will ignore the requirement to match a registered location.

The endpoint is provisioned as a Standard endpoint:

  • This endpoint is a phone number, so the format of the SIP URI being 10 or 11-digit for PIDF-LO and legacy calls will match
  • If no PIDF-LO is present, the static location is used
  • If PIDF-LO is present and matches a registered location, the non-static location is used

Note: If the endpoint is provisioned in Microsoft Teams, it will ignore the requirement to match a registered location.

The specific arrangement depends on your goals and use cases (please request the 911 IP Traffic Consolidation Application Note from your account representative for full details). Bandwidth is pre-integrated for Metaswitch, Netsapiens, and Microsoft Teams, and has specific account-level recommendations to optimize your provisioning, routing, and resulting billing experience.

Metaswitch integration

The following is one method of how to use IP Traffic Consolidation to support a wholesaler’s Metaswitch implementation. Other configurations are possible and may be preferable if you have additional sophisticated use cases not considered here. Please see the references section of this document for more detailed descriptions of Bandwidth’s 911 products and request the full from your account representative.

Metaswitch has long been integrated with Bandwidth in support of static emergency calling using Bandwidth’s standard VoIP E911 product. In recent years, Metaswitch has additionally implemented non-static emergency calling using PIDF-LO to support its UC Max™ products and comply with new regulatory requirements. 

Integration with Bandwidth’s products 

  • Metaswitch's VoIP core will automatically identify nomadic devices on its network and will include appropriate PIDF-LO address data as part of a non-static 911 call. Standard calls don’t include PIDF-LO and continue to rely on the static location provisioned for a given TN.
  • Metaswitch doesn’t distinguish the "IP source" of a particular emergency call, and sends all emergency traffic, with and without PIDF-LO, from the same IP source address to the same IP destination on Bandwidth’s network-edge SBC 
    • This means that by using IP Traffic Consolidation, you will not need to make VoIP peer connection (SBC-to-SBC) configuration changes when turning on non-static PIDF-LO service on your Metaswitch. 

Note: The VoIP peer connection does need to support TCP.

  • IP Traffic Consolidation associates your two 911 accounts together into a “family” so that the Metaswitch treatment of static and non-static emergency traffic can be processed correctly depending on the type of call received by Bandwidth (with PIDF-LO or without PIDF-LO). The task of creating the “family” is performed by your Bandwidth Implementation Specialist.
  • Your two accounts should be set up: (1) a Standard VoIP E911 account and (2) a DLR account using Location-by-Value (PIDF-LO).
    • Often, existing customers using the Metaswitch platform already have a Standard VoIP E911 account set up, including the IP address routing arrangements — none of this needs to change (except for ensuring support of TCP).
    • Metaswitch has an existing integration with the Bandwidth API for automated “add/change/delete” of endpoint records — all of this functionality remains intact.
  • DLR account configuration details:
    • The DLR account will be provisioned with the new address data (PIDF-LO) coming in from the soft-phone instances from Metaswitch's cloud services offering.
    • Provided the Standard VoIP E911 parent account has a complete set of TN endpoint records for all the users on the Metaswitch, there is no need to provision extra DLR endpoint records. 

Note: If DLR endpoint records are needed, the AEUI endpoint identifiers will be provisioned in 11-digit format (example: +19195551001). 

  • When providing Metaswitch SIP Trunking service to an enterprise PBX (for example), each DID on the SIP trunk becomes a Standard VoIP E911 endpoint record. Metaswitch cannot extend PIDF-LO through a Metaswitch SIP Trunk at this time.
  • Testing can now proceed using the digits "9-3-3".

Netsapiens integration

The following is one method of how to use IP Traffic Consolidation to support a wholesaler’s Netsapiens implementation. Other configurations are possible and may be preferable if you have additional sophisticated use cases not considered here. Please see the references section of this document for more detailed descriptions of Bandwidth’s 911 products and request the full 911 IP Traffic Consolidation Application Note from your account representative.

Netsapiens has integrated with both Bandwidth’s Standard VoIP E911 and DLR. A Netsapiens administrator can provision API credentials for both a Standard account and a DLR account within Netsapiens. As endpoints and users are provisioned in the Netsapiens platform, the type of 911 endpoint can be designated with the Netsapiens platform, automatically provisioning the endpoint and location data in the appropriate Bandwidth account.

Integration with Bandwidth’s Products

  • The Netsapiens platform will automatically identify the endpoint 911 type and include appropriate PIDF-LO address data as part of a non-static 911 call. Standard calls don’t include PIDF-LO and rely on the static location provisioned for a given endpoint TN.
  • Netsapiens doesn’t distinguish the "IP source" of a particular emergency call, and sends all emergency traffic, with and without PIDF-LO, from the same IP source address to the same IP destination on Bandwidth’s dedicated 911 network-edge SBCs. 
    • This means that, by using IP Traffic Consolidation, you will not need to make VoIP peer connection (SBC-to-SBC) configuration changes when turning on non-static PIDF-LO service on your Netsapiens platform. 

Note: The VoIP peer connection does need to support TCP.

  • IP Traffic Consolidation associates your two accounts together into a “family” so that the treatment of static and non-static emergency traffic can be processed correctly depending on the type of call received by Bandwidth (with PIDF-LO or without PIDF-LO). The task of creating the “family” is performed by your Bandwidth Implementation Specialist.
  • Your two accounts should be set up: (1) a Standard VoIP E911 account and (2) a DLR account using Location-by-Value (PIDF-LO).
    • Often, existing customers using the Netsapiens platform already have a Standard VoIP e911 account set up, including the IP address routing arrangements – none of this needs to change (except for ensuring support of TCP).
  • DLR account configuration details:
    • The DLR account will be provisioned with the new non-static endpoint and non-static location data via the provisioning API.

Note: DLR non-static endpoint records are automatically provisioned via the API such that the AEUI endpoint identifiers are in 11-digit format (example: +19195551001).

  • Testing can now proceed using the digits "9-3-3".

Microsoft Teams integration

The following is the method of how to use IP Traffic Consolidation to support an enterprise Microsoft Teams implementation in conjunction with one or more "standard" PBX (MLTS) products. 

Integration with Bandwidth’s products

  • Many PBX/MLTS products (such as Avaya, Cisco UCM, MiTel/ShoreTel) can make direct use of Bandwidth's Standard VoIP E911 service.
    • If you have an existing Standard VoIP E911 account supporting your PBX, no changes are needed. 

Note: The VoIP peer connection does need to support TCP in order to pass some of the larger PIDF-LO address data described below.

    • If you don’t have an existing account, a new Standard VoIP E911 account will be set up and should be configured with an endpoint record per TN that will be enabled for 911 calling on your PBX. The endpoint records should include all "ELIN/ERL" pairs (called "CSID" in ShoreTel/MiTel) or "pilot" or "Group Numbers" that support extension calling on the PBX.
    • Typically, for an enterprise PBX, the endpoint data is provisioned with the Bandwidth portal or via bulk upload.
  • Microsoft Teams will pass PIDF-LO address data as part of a non-static Teams 911 call. 
  • DLR account configuration details:
    • A new DLR account with the routing type set to “DLR-TeamsDirectRouting” will be set up by your Bandwidth Implementation Specialist. 
    • A DLR endpoint record should be created for each Microsoft Teams Tennant with a new unique DID that doesn’t have a static default address. For clarity, the new DLR endpoint records are not needed if there is already a matching TN in the existing Standard VoIP E911 account. If new DLR endpoint records are needed, the AEUI endpoint identifiers should be provisioned in 11-digit format (example: +1919555100).
    • An endpoint record should be created for each Microsoft Teams Tennant without a DID by using their username as the endpoint identifier. For example, a username such as "usenamer@yourcompanydomain.com" would populate the endpoint record with "username" and the SIP header would arrive from Teams as: FROM: <username@yourcompanydomain.com>
    • For Microsoft Teams, there is no need to create and pre-validate address data that is sent in the PIDF-LO of the 911 call. 

Note: A small number of location (address) records will be needed simply to identify the billing address of each DLR endpoint record. These locations are not used during 911 call processing and don’t define the destination PSAP. 

  • IP Traffic Consolidation associates your two accounts together into a “family” so that the treatment of static and non-static emergency traffic can be processed correctly depending on the type of call received by Bandwidth (with PIDF-LO or without PIDF-LO). The task of creating the “family” is performed by your Bandwidth Implementation Specialist.
    • When a 911 call is received by the account family, those SIP INVITES that contain PIDF-LO data will be directed to the Microsoft Teams DLR account for treatment. The location (address) data received in the PIDF-LO is processed in real-time and the call is routed to the appropriate destination PSAP.
    • Calls without PIDF-LO data will be processed by the Standard VoIP E911 account. The 911 call will search for a matching TN endpoint record and be processed according to the stored static address data.

Note: There is no need to place the same TN in both the Standard VoIP E911 account and the Teams DLR account. Provided the caller’s TN is found in the Standard VoIP E911 account, the call will be processed either with the designated static address or with the non-static PIDF-LO address (if present).

  • Testing can now proceed using the digits "9-3-3".

Frequently Asked Questions (FAQ)

Can we send both UDP and TCP traffic to the same IP address on Bandwidth’s 911 SBCs?

Yes. When using IP Traffic Consolidation, it’s common that an existing Standard VoIP E911 account and a Dynamic Location Routing (DLR) account receive blended traffic on the same SIP connection. The static calls (without PIDF-LO) are sent using UDP and the non-static calls (with PIDF-LO) are sent using TCP. Bandwidth uses Ribbon SBCs which support both UDP & TCP simultaneously. The Signaling Ports on all Bandwidth 911-only SBCs are configured to support blended UDP/TCP traffic (but this is not necessarily true on our normal Voice network edge).

Can I simply send a SIP PIDF-LO (address) to my Standard VoIP E911 account so that the PIDF-LO address is used for 911 call routing instead of the stored address?

No. However, this is possible by creating a new Dynamic Location Routing (DLR) account and then associating it with your existing Standard E911 VoIP account and using the IP Traffic Consolidation feature. The feature will route PIDF-LO traffic to the new account and non-PIDF-LO to the old account (where the stored address will be used for 911 processing).

Can I create a “default” address in my DLR account so that, if there is no PIDF-LO, the 911 call uses the default address to route the call?

No. However, this is possible by creating a Standard VoIP E911 account and then associating it with your existing DLR account and using the IP Traffic Consolidation feature. The feature will route PIDF-LO traffic to the existing DLR account and non-PIDF-LO to the new Standard VoIP E911 account (where the stored address will be used for 911 processing).

Does Bandwidth bill me for duplicate 911 endpoints?

Bandwidth doesn’t allow duplicate endpoints in your Standard VoIP E911 account(s). All your endpoints should be identified with unique TNs – even if you have multiple accounts.

Bandwidth also doesn’t allow duplicate endpoints in your DLR accounts. However, it’s possible that an endpoint record in your Standard VoIP E911 account “looks like” an endpoint in your DLR account. That is, the Standard VoIP E911 endpoint record is a literal TN stored in a 10-digit format. The DLR endpoint record identifier is not a TN but is instead an alpha-numeric string. It’s possible (and sometimes necessary) that a Standard endpoint (example: 9195551001) looks the same as a DLR AEUI record (example: 19195551001). You will be billed for both records. There are ways to reduce this “apparent” duplication using IP Traffic Consolidation.

What determines the taxation treatment for the DLR endpoint record?

The billing address provisioned to the endpoint record determines taxation on DLR-routed calls.

Article is closed for comments.