IntelePeer Dynamic 911 Location Routing

To effectively use this document, we assume a general, high-level understanding of:

• HTTPS – Secure Hyper Text Transfer Protocol

• HTML and XML – Hyper Text Markup Language

• Web services API programming interfaces such as SOAP, RESTful

• VoIP and SIP – Voice over IP and Session Initiation Protocol

Traditional VoIP 911 call routing solutions are based on a pre-provisioned relationship between a telephone number (TN), a customer’s name, and the static location in the form of an address of the phone itself. At the time of a 911 call, this information is used to route the call to public safety and is displayed on the 911 call taker’s screen in the public safety answering point (PSAP). This solution works well for enterprises with fixed or static users who are likely to call 911 from their desk phone or other fixed location, such as a phone in a conference room.

Our service departs from the fixed provisioning model and allows for real-time steering of the emergency call based on location identified at the time of the 911 call. Further, previously stored and static information, such as customer name and Dynamic911CallbackNumber can also be modified prior to display to the 911 call taker’s screen. Caller location information is treated flexibly at call time including identifying where the caller is at the moment of the call as well as specifying the type of location information to be displayed, such as address or latitude-longitude.

Note: Address validation is required prior to use for a 911 call. New, unknown, and unvalidated address cannot be dynamically inserted into the SIP INVITE at call time. All potential locations where an end user could be present must be pre-validated and stored as part of the service.

This service uses emergency calling techniques described in the North American Emergency Number Association’s (NENA) i3 Next Generation 911 (NG911) specification. Ingress of emergency calls is provided using the SIP Presence Information Data Object Location Object (PIDF-LO) (RFC 5139) standard.

It is compliant with NENA i3 STA-010.2-2016 (formerly NENA 008.003) and is comprised of a SIP INVITE enabled with a PIDF-LO location object. The location object supported will be a pre-validated address passed by value or by reference or a latitude-longitude pair passed by value in a PIDF-LO attachment or in the Geolocation SIP header.

The service:

1. Determines the correct routing path for the call by using a provided location object and comparing it to a national database of public safety answering point (PSAP) GIS boundaries.

2. Delivers the voice call via RTP upon IntelePeer’s SIP interconnected network.

3. Converts the location object into NENA-compliant format for delivery and display at the PSAP.

4. Provides the PSAP with a call back number of the subscriber who initiated a 911 call. The call back number is a telephone number (TN) used to identify the subscriber or is another telephone number provided by the OSP during provisioning.

IntelePeer’s service is primarily intended for companies who develop, own, and manage their own VoIP call server infrastructure (physically or in the cloud) and who need to build advanced 911 services for complex use cases.

Typical users of this service include businesses that manage their own voice equipment with VoIP call processing capabilities who are interested in providing nomadic and mobile VoIP 911 capabilities to their end users. The service allows the customer’s development or IT team to design and implement 911 use cases that were not possible before now.

Important Concepts and Terminology

The definition and provisioning of both endpoints and location objects are two important concepts to understand within our service.

Endpoint

An endpoint is a data representation of the calling party. Each endpoint contains:

• [Required] Dynamic911Identifier

This is the PRIMARY identifier used to refer to each unique endpoint record. It is comprised of a unique alpha-numeric string of no more than 30 characters. The alpha-numeric string can contain only letters and numbers and no special characters. The Dynamic911Identifier can be used to match this endpoint record by including it in the “From” or “P-Asserted-Identity” fields of the SIP INVITE.

Note:This Dynamic911Identifier will later be embedded in HTML and XML code and the presence of special characters, such as backslash, period or angle brackets (“/”, “.” or “<>”) would disrupt the parsing of these code expressions.

• [Optional] Dynamic911Language

This can be set to English (en) or French (fr). If not provisioned, the default is English.

Note: This field is primarily used for endpoints pertaining to Canadian service where there is a regulatory requirement for use of one of the two official languages.

• [Required] Dynamic911CallerName

This is the business name or caller name that will be delivered to the PSAP and displayed on the screen. While this is a required field, at call time the caller name can be dynamically changed by use of a contact header optionally included in the SIP INVITE. Note that while the API can provision up to 75 characters, in the majority legacy PSAPs (utilizing the “PAM spill”) only the first 32 characters will be displayed.

• [Required] Dynamic911CallbackNumber

The Dynamic911CallbackNumber is the valid North American Numbering Plan phone number at which the 911 caller can be reached. The Dynamic911CallbackNumber number will be delivered to the PSAP at emergency call and displayed on the call taker’s screen. If the call drops for any reason), the call taker can use the Dynamic911CallbackNumber to call back to the user. While this is a required field, at call time the Dynamic911CallbackNumber can be dynamically changed by use of a contact header optionally included in the SIP INVITE.

• [Required] Dynamic911TaxationLocationID

Because the VoIP caller can move around, a taxation location is required to be designated for the endpoint. This taxation location is not the precise dynamic location of the caller and is not used for call routing as a default location. Rather, a tax endpoint should be established for a primary place of use or the principal location for the provisioning of the voice services. For example, businesses may need to use their business address for this field, rather than trying to determine dynamic use information specifically for taxing purposes. The format of this field is a location ID, which is described next.

Location Object

A location object is a data representation of an address where a 911 call could potentially be made. Each location object contains:

• [System-generated] Location Identifier (or locationID)

This is the PRIMARY identifier used to refer to each unique location object. It is comprised of a unique alpha-numeric string of no more than 32 characters. The alpha-numeric string can contain only letters and numbers and no special characters. The locationID can be used at call time to match this location object by including it in the geolocation field of the SIP INVITE.

Upon successful location order completion, a locationID is generated for that location.

Note: These locationIDs will later be embedded in HTML and XML code and the presence of special characters, such as backslash, period or angle brackets (“/”, “.” or “<>”) would disrupt the parsing of these code expressions.

• [Mandatory] Address_Line_1

Address_Line_1 is a civic street address (example: “900 Main Campus Drive, Raleigh, NC, 27606”). This data is not required to be unique. Many different location objects may have the same Address_Line_1 content.

[Optional] Address_Line_2

Address_Line_2 is a free-form field providing extra specificity as to the location being identified by this location object. (example: “3rd Floor” or “Unit 101”). This data is not required to be unique.

Once the location object is created, it can be utilized at call time using several different mechanics within the SIP INVITE:

1. Location by Value in PIDF-LO: This is where the XML field-by-field exact contents of Address_Line_1 (and optionally Address_Line_2 are) are directly included in the PIDF-LO header.

2. Location by Reference using Geolocation Header: This is where the Location ID (not the full address) is included in the Geolocation SIP header. This is a recommended technique due to its efficiency.

3. Latitude-Longitude in PIDF-LO: This is also referred to as “XY” routing. The coordinates are directly carried by the PIDF-LO.

4. Latitude-Longitude using Geolocation Header: This is also referred to as “XY” routing. The coordinates are carried in the Geolocation SIP header. Some customers find it convenient to exclusively use the Geolocation Header technique because their application switches between use cases needing XY-based location one moment and address-based location the next.

Lastly, because public safety generally prefers to receive address-based location information, effort is made to convert any received XY routing data into an address at call time. The latitude-longitude pair will be reverse geocoded into an address and converted in real-time into the correct local Master Street Address Guide (MSAG) format desired by the PSAP. This process is generally successful in urban areas and generally less successful in rural areas. If unsuccessful, the original XY coordinates are provided to the PSAP and appears as merely a dot on the map on the 911 call taker display.

The following diagrams provide an overview of the steps a dynamic 911 call takes when initiated by a caller. The flows include calls with:

• Pre-validated locations

• Latitude-longitude routing

• Failed location determination

1. The user places a 911 call from their device. The customer’s equipment determines the location based on the Wi-Fi router, access point, and other data.

2. The customer’s equipment routes the call to IntelePeer’s network, adding the caller’s location or location reference to the SIP INVITE (information already provisioned with IntelePeer).

3. IntelePeer’s network processes the call. The Location Information Server (LIS) is queried and compared (if the value is provided in the SIP INVITE), or if the reference is provided, the matching object is retrieved. The call is then routed out through an emergency services gateway to the emergency services infrastructure.

4. The location database communicates with IntelePeer’s network LIS to determine routing for the appropriate Public Safety Answering Point (PSAP) and provide the pre-validated Master Street Address Guide (MSAG) address and the user’s callback number.

5. The call is routed to PSAP with the pre-validated MSAG address and the user’s callback number (CBN).

1. The user places a 911 call from their device (which is a registered endpoint with IntelePeer). The device or customer’s equipment adds the caller’s latitude-longitude to the call as a Presence Information Data Format Location Object (PIDF-LO) mime attachment or in the geolocation header.

2. The customer’s equipment routes the call to the IntelePeer network.

3. IntelePeer’s network processes the call. Latitude-longitude information including callback number (CBN) is received, and reverse geocoding is attempted. The call is routed to the emergency services infrastructure.

4. The location database communicates with IntelePeer’s network Location Information Server (LIS), and IntelePeer sends the latitude-longitude information along with callback number and name. If reverse geocoding is successful and the address is determined, that address is provided to the Public Safety Answering Point (PSAP). Otherwise, the latitude-longitude appears as a dot on a map to the PSAP.

5. The call is routed to the PSAP with the information in Step 4.

1. The user places a 911 call from their device. The customer’s equipment determines the location based on the Wi-Fi router, access point, and other data.

2. The customer equipment routes the call to IntelePeer’s network, adding the caller’s location or location reference to the SIP INVITE (information already provisioned with IntelePeer).

3. IntelePeer’s network processes the call. The Location Information Server (LIS) is queried; however, the information received doesn’t match the pre-provisioned location information, is incorrectly formatted, or is missing. The call is then routed out to a third-party 24/7 Emergency Call Center (ECC).

4. The ECC queries the caller for their location, enters the address of the caller, and determines the correct Public Safety Answering Point (PSAP) and associated ten-digit administrative number for police, fire, and medical. The ECC call taker subsequently routes the call to the PSAP across the Public Switched Telephone Network (PSTN) using the administrative number. The call uses the callback number (CBN) as the Calling_Party_Number to facilitate any need for direct callback from the PSAP to the subscriber.

5. The PSAP receives the ECC redirected call on the administrative line.

Note: In this failsafe scenario where the original location object or routing information has some error and the PSAP doesn’t receive the validated address automatically as per the Dynamic 911 Call Routing – Pre-Validated Location example, the call is still delivered.