E911 Dynamic Location Routing

VI Communications services allows registered 911 ANIs to overwrite their registered address information using an implementation of PIDF-LO. This can be used with nomadic users who may be working at different locations (but uses the same DID) or for Kari’s Law compliance, allowing you to send Room/Office/Suite information dynamically depending on the extension making the 911 call.

The dynamic location implementation requires the telephone number to be registered with a default address (for when PIDF-LO information is not sent). Also, it is required that you pre-validate any addresses that are going to be sent through the API or Back Office under 911 → Validated Addresses. Address Line 2 information does not need to be pre-validated (e.g. “Floor”, “Suite”, “Room”, “Apartment”, etc). If a call contains a PIDF-LO object with an address that has not been pre-validated, the contents will be ignored and the call will by treated as an unregistered call including any possible fees associated with unregistered calls.

At the time of writing this document, not many PBX’s/Devices/Softphones currently inherently support PIDF-LO. Check with your PBX, SBC, Phone, or Softphone provider to find out how to properly implement this. In most cases, you may need to create scripts in order to insert the object into the call. Unfortunately, VI Support is unable to assist with this process.

Sangoma PBX’s are currently working on implementation and will hopefully be available soon.

Validating Addresses

To validate new addresses for E911 or review addresses that you have validated on your account, you can go to the Back Office and browse to E911 → Address Validation.

This page will list any addresses that have been previously validated on your account which are available to send using the PIDF-LO object.

There are a few different ways to pre-validate addresses that are going to be sent for dynamic location routing:

1. Registering the Address on a Phone number - Registering a phone number to an address will automatically validate the address and have it available to send using PIDF-LO

2. validate911 API Call - Our validate911 API call allows you to validate address information. If the address is successfully validated it will be available to send using PIDF-LO. There is a “Custom Validation URL” listed on your Address Validation page.

Sample: https://backoffice.voipinnovations.com/restapi/XXXXXXXXXXXXX/e911validate?address=123 Test St&city=Testville&state=NY&zipCode=15555

Simply replace the “XXXXXXXXXXXXX” with the unique string from your Custom Validation URL.

3. Back Office E911->Address Validation. Whenever reviewing your validated addresses on this page, a form is available to validate additional addresses.

Open

Call Flow

In order to update the address being used for routing 911 calls, VI will need to receive the address as a PIDF-LO object within the SIP INVITE. SIP Messages sent this way must contain a GeoLocation header with CID reference to the message body containing PIDF-LO. Any SIP Messages also must include a GeoLocation-Routing header containing the word “yes”, which indicates that the call should be routed using the information supplied. Any calls received with a GeoLocation-Routing header containing “no”, or without a GeoLocation-Routing header, will be routed based off the address used whenever provisioning the phone number originally, regardless of what is populated in the GeoLocation header.

Calls with GeoLocation-Routing “yes” will be routed based off of the information contained in the PIDF-LO object and NOT the address provided at the time of provisioning, regardless of whether the PIDF-LO object is valid or present. Any calls sent with GeoLocation-Routing “yes” with unvalidated, invalid, or empty PIDF-LO information will be treated as an unregistered call and routed to a national emergency call center. Any fees associated with unregistered calls will apply.

Please note, while the PIDF-LO technology supports GPS coordinates, these are currently being ignored. Only full addresses are being supported at this time.

Call Back Number Priority

A priority exists whenever determining the callback number for an emergency call and whenever linking it with a registered number. The preference order is:

1. P-Asserted-ID

2. P-Preferred-ID

3. Remote-Party-ID

4. From

VI suggests sending callback numbers in E.164 format.

INVITE Example and PIDF-LO Requirements

The body type present in the SIP INVITE when sending a PIDF-LO object must be “application/pidf+xml”. The following is an example of a SIP INVITE with the required format:

Notable fields within the XML are as follows:

• Country: Required field; VI only supports US and CA at this time

• A1: Required field; Must be populated with the state (US) or province (CA) using the appropriate 2 character abbreviation

• A3: Required Field; Must be populated with the city.

• Rd: Required Field; Must be populated with the street name (e.g. “Main”, “Pennsylvania”, “5th”)

• Prd: Optional Field; prefix directional will be populated here if applicable (e.g. “North” in “North Main Street”)

• Pod: Optional Field; post directional will be populated here if applicable (e.g. “South” in “Main Street South”)

• Sts: Optional Field; street name suffix will be populated here if applicable (e.g. “Street” in “Main Street”)

• Hno: Required Field; Must be populated with the numerical portion of the address (e.g. “140” in “140 Main Street”)

• Hns: Optional Field; house number suffix will be populated here if applicable (e.g. “A” in “140A Main Street”)

• Loc: Optional Field; additional location information (e.g. Address Line 2) will be populated here if applicable (e.g. “Suite 100” in “140 Main Street Suite 100”

• Nam: Optional Field; subscriber or entity name will be populated here if applicable (e.g. “John Smith”, “ ABC LLC”, etc)

• Pc: Required Field; Must be populated with the zip or postal code (e.g. “90210” or “M3C 0C3”)

• Retransmission-allowed: Required Field; Must be “yes”

• Method: Required Field; Must be “manual”