Architecting Emergency Services (E911) Routing Configuration for Multi-Site Deployments

How-To-Articles
1

Architecting Emergency Services (E911) Routing Configuration for Multi-Site Deployments

What This Guide Covers

This guide details the architectural implementation of location-aware emergency routing within Genesys Cloud CX for distributed enterprise environments. You will configure a deterministic routing strategy that maps agent or user locations to specific Public Safety Answering Points (PSAPs) using physical address data, ensuring compliance with FCC regulations for multi-site deployments. The end result is a fail-safe system that routes 911 calls to the correct jurisdiction based on the caller’s physical location, regardless of their network path or device type.

Prerequisites, Roles & Licensing

Licensing and Capabilities

  • Genesys Cloud CX 3 or CX 3.5: Required for advanced Architect capabilities and full emergency services integration.
  • Emergency Services Add-on: Mandatory for accessing the Emergency Services application and location management features.
  • Telephony Trunk: A SIP trunk provisioned with E911 support from a certified emergency services provider (e.g., Bandwidth, Twilio, Telnyx). The trunk must support out-of-band location data transmission (SIP INFO or SDP geolocation attributes) or in-band signaling as required by your local PSAP.

Permissions and Roles

  • Admin: Telephony > Trunk > Edit, Admin > Emergency Services > Edit
  • Architect: Architect > Flow > Edit, Architect > Flow > Deploy
  • User Management: Admin > Users > Edit (to assign locations to users)

External Dependencies

  • Emergency Services Provider (ESP): Confirmation that your SIP trunk provider supports the specific E911 standard required by your local PSAP (e.g., ANSI-41, NENA i3, or local equivalents).
  • Location Data: A verified list of physical addresses for all sites, including floor numbers and suite details, mapped to specific PSAP jurisdictions.

The Implementation Deep-Dive

1. Configuring Physical Locations and PSAP Mappings

The foundation of E911 compliance is the accurate mapping of physical space to emergency services. Genesys Cloud uses the concept of “Locations” to store this data. This is not merely an administrative exercise; it is the primary data source for routing decisions.

Step 1.1: Define Locations
Navigate to Admin > Emergency Services > Locations. Create a distinct location for every physical site that requires emergency routing. This includes branch offices, remote workspaces, and even specific floors within a large building if the PSAP requires granular data.

For each location, you must enter:

  • Address: The exact physical address.
  • City, State, Zip: Verified against the ESP’s database.
  • PSAP Identifier: The specific identifier for the Public Safety Answering Point that serves this address. This is often provided by your ESP.

The Trap: Ambiguous Address Data
A common misconfiguration is entering generic address data such as “123 Main St” without a suite or unit number, or using a PO Box. PSAPs require precise physical locations. If the address is ambiguous, the ESP may reject the call, or worse, route it to a default PSAP that cannot assist the caller. Always validate addresses directly with your ESP before entering them into Genesys Cloud.

Architectural Reasoning
We store location data centrally in Genesys Cloud rather than relying on the endpoint device (SIP phone or softphone) to determine location. This ensures consistency. If an agent moves from Site A to Site B, updating their location in Genesys Cloud immediately changes their E911 routing without requiring hardware reconfiguration. This decouples the user from the physical infrastructure, enabling flexibility while maintaining compliance.

2. Integrating the Emergency Services Provider (ESP)

Genesys Cloud acts as the intermediary between the caller and the PSAP. It must communicate location data to the ESP in a format the ESP understands.

Step 2.1: Configure the ESP Connector
Navigate to Admin > Emergency Services > Providers. Add your ESP as a provider. You will need to provide:

  • Provider Name: A descriptive name for internal reference.
  • Endpoint URL: The SIP URI or API endpoint provided by your ESP for emergency calls.
  • Authentication Credentials: If required by the ESP (e.g., API keys or SIP credentials).

Step 2.2: Map Locations to Provider Jurisdictions
Not all ESPs cover all jurisdictions. You must map each Location created in Step 1 to the correct Provider and Jurisdiction ID. This mapping tells Genesys Cloud which ESP endpoint to use for a given location.

The Trap: Single Provider Assumption
Many organizations assume their primary SIP trunk provider covers all their locations. This is rarely true for multi-national or even multi-state deployments. If you route a call from a location in California to an ESP endpoint configured for New York, the call will fail or be routed incorrectly. Always verify the geographic coverage of each ESP endpoint and map locations accordingly.

Architectural Reasoning
By mapping locations to specific provider endpoints, we enable multi-homing for emergency services. If one ESP experiences an outage, you can failover to a secondary ESP by updating the location mapping. This provides redundancy that is critical for emergency services.

3. Designing the Emergency Routing Flow in Architect

The core logic for E911 routing resides in Genesys Cloud Architect. You will create a dedicated flow that handles incoming emergency calls. This flow must be deterministic and fast, with minimal branching to reduce latency.

Step 3.1: Create the Emergency Flow
Create a new Architect flow named Emergency Services Routing. Set the trigger to Incoming Call.

Step 3.2: Determine Caller Location
The first step in the flow is to determine the location of the caller. This differs for internal agents versus external callers.

  • For Internal Agents: Use the Get User block to retrieve the user making the call. Then, use a Set Variable block to extract the user.location.id from the user object.
  • For External Callers: If your ESP supports ANI/ALI (Automatic Number Identification/Automatic Location Information), the location data may arrive in the SIP headers. Parse the SIP header using a Parse JSON or Set Variable block to extract the location identifier. If the ESP does not provide location data for external callers, you may need to use a geographic IP lookup or a separate database service, which adds complexity and latency.

Step 3.3: Route to the Correct PSAP
Use a Switch block based on the location.id. For each case in the switch:

  • Case: location.id equals Site_A_Location_ID
  • Action: Use a Transfer Call block to route the call to the SIP URI of the PSAP endpoint mapped to Site A.

The Trap: Hardcoding SIP URIs
Hardcoding SIP URIs in the Architect flow is a maintenance nightmare. If your ESP changes the endpoint for a PSAP, you must update every flow case. Instead, use a Look Up block to query a Data Source (e.g., a JSON file or database) that maps location.id to psap_sip_uri. This centralizes the routing logic and makes updates safer and faster.

Architectural Reasoning
We use a Data Source lookup instead of hardcoding URIs to separate configuration from logic. This allows non-technical administrators to update PSAP endpoints without modifying the flow. It also enables dynamic updates if the ESP provides an API for real-time endpoint resolution.

4. Assigning Locations to Users and Devices

Once the flow is built, you must ensure that every user and device is associated with a location.

Step 4.1: Assign Locations to Users
Navigate to Admin > Users. For each user, assign the appropriate Location from the dropdown. This location is used when the user initiates an emergency call from their Genesys Cloud softphone or desktop app.

Step 4.2: Configure Device-Specific Locations (If Applicable)
For SIP phones or other hardware endpoints, the location may be configured at the device level rather than the user level. Navigate to Admin > Telephony > Devices. For each device, assign the Location. This ensures that if a device is moved to a different site, its emergency routing updates automatically.

The Trap: Location Mismatch Between User and Device
If a user is assigned to Site A but logs into a device configured for Site B, the system may use the device’s location for E911 routing. This can result in the call being routed to the wrong PSAP. Always audit user and device locations regularly to ensure they match the physical reality.

Architectural Reasoning
We prioritize device-level location for hardware endpoints because the physical phone is stationary. For softphones, we prioritize user-level location because the user is mobile. This dual-layer approach ensures that the most accurate location data is used regardless of the endpoint type.

Validation, Edge Cases & Troubleshooting

Edge Case 1: Call Failover on ESP Timeout

The Failure Condition
The ESP endpoint for a specific PSAP is unreachable due to a network outage or provider failure. The call times out, and the emergency caller is left hanging.

The Root Cause
Single-point-of-failure in the ESP routing path. The Architect flow does not have a fallback mechanism for failed transfers.

The Solution
Implement a fallback path in the Architect flow. After the Transfer Call block, add a Failure branch. In the failure branch, use a Set Variable block to log the error, then attempt to transfer the call to a secondary ESP endpoint or a backup PSAP. You can also implement a retry mechanism with exponential backoff.

Edge Case 2: Remote Worker Location Accuracy

The Failure Condition
A remote worker moves from their home address to a coffee shop or another city but does not update their location in Genesys Cloud. They make an emergency call, and it is routed to their home PSAP, which is miles away.

The Root Cause
Static location data cannot track dynamic user movement. Genesys Cloud does not have built-in GPS tracking for softphones due to privacy and technical constraints.

The Solution
Educate users on the importance of updating their location. Implement a self-service portal where users can easily update their location. Additionally, consider integrating with a location-aware service (such as a mobile app with GPS capabilities) that can update the user’s location in Genesys Cloud via the API when a significant change is detected. This requires custom development but provides a more robust solution for mobile workers.

Edge Case 3: SIP Header Stripping by Intermediate Networks

The Failure Condition
External callers’ location data is lost because an intermediate SIP proxy or firewall strips the SIP INFO or SDP geolocation headers. The call arrives at Genesys Cloud without location context.

The Root Cause
Network infrastructure between the caller and Genesys Cloud does not support or is configured to block E911 signaling headers.

The Solution
Work with your network provider and ESP to ensure that all intermediate nodes preserve E911 headers. If this is not possible, use ANI/ALI data if available. If neither location headers nor ANI/ALI are available, you must implement a fallback mechanism that routes the call to a default PSAP or prompts the caller to enter their location manually (though this is not ideal for emergency situations).

Official References