Implementing Dynamic Emergency Routing for Remote Hybrid Agents

How-To-Articles
1

Implementing Dynamic Emergency Routing for Remote Hybrid Agents

What This Guide Covers

  • Configuring E911 and dynamic location tracking for a hybrid workforce using Genesys Cloud WebRTC and BYOC Cloud.
  • Automating the update of emergency dispatchable addresses based on network location or user-provided input.
  • Ensuring compliance with Kari’s Law and the RAY BAUM’S Act for remote contact center operations.

Prerequisites, Roles & Licensing

  • Licensing Tier: Genesys Cloud CX 1, 2, or 3.
  • Permissions: Telephony > Trunk > Edit, Directory > User > Edit, Telephony > Location > Add.
  • Hardware/Software: Genesys Cloud WebRTC softphones (browser-based) or Genesys Cloud desktop app.
  • Dependencies: A SIP trunk provider that supports dynamic ELIN (Emergency Location Identification Number) or PIDF-LO (Presence Information Data Format Location Object) pass-through.

The Implementation Deep-Dive

1. Establishing a Location Library and Site Mapping

Genesys Cloud requires a “Site” to be associated with every user. For office-based workers, this is static. For remote hybrid agents, the “Site” must be configured to allow dynamic updates.

  • The Process: Create a “Remote Workers” Site in Admin > Telephony > Sites. Under the Emergency Services tab, enable “Dynamic Location.”
  • Location Mapping: You must define “Locations” (addresses) in Admin > Directory > Locations.
  • The Trap: Using a single “Corporate HQ” location for all remote workers. If a remote agent in California dials 911 but is registered to a New York Site, the call may be routed to a New York PSAP (Public Safety Answering Point). This is a life-safety violation. You must configure the system to prompt the user or detect their network state to map them to the correct geographical location.

2. Configuring WebRTC Dynamic Location Prompts

For agents using the browser-based WebRTC phone, Genesys Cloud can prompt the user to confirm their location upon login or when a network change is detected.

  • Configuration: Within the WebRTC Phone settings, toggle “Prompt for Emergency Location.”
  • The Trap: The “Dismissal Loop.” If agents find the prompt annoying, they may habitually dismiss it or select “Corporate” by default. As an architect, you must implement a “Hard Stop” via a custom script or a policy that checks the user.location variable via the API. If the location is not “Remote-Verified,” you can prevent the agent from going into an “Available” status until they provide a dispatchable address.

3. Implementing ELIN/Callback Number Logic

When an emergency call is placed, the PSAP needs a way to call the agent back if the line drops.

  • BYOC Pattern: In your SIP Trunk configuration, you must define how the Emergency Calling ID is handled. If the agent is remote, you should ideally send their direct DID as the ELIN.
  • The Trap: “Shared Number Masking.” Many centers mask outbound caller ID to a general queue number. If this is applied to emergency calls, the PSAP cannot reach the specific agent who placed the call. You must configure Emergency Routing Rules that override standard caller ID masking to ensure the agent’s unique DID or the local ELIN for their specific “Location” is sent to the carrier.

Validation, Edge Cases & Troubleshooting

Edge Case 1: 933 Test Call Failures

  • The Failure Condition: A test call to 933 (the standard E911 test number) returns a “Number not found” or a generic recording.
  • The Root Cause: Your SIP trunk’s Number Plan in Genesys Cloud does not have a specific regex entry for 933, or the carrier does not support the 933 service for the specific ELIN being sent.
  • The Solution: Add a high-priority rule to your Number Plan for ^933$ with a classification of Emergency. Verify with your carrier (e.g., Bandwidth, Lumen, IntelePeer) that your SIP trunk is provisioned for E911 services.

Edge Case 2: ICE Candidate Failures for Remote WebRTC

  • The Failure Condition: An emergency call is placed, but there is no audio or the call drops after 10 seconds.
  • The Root Cause: A firewall at the agent’s home is blocking the STUN/TURN traffic required for WebRTC media established via the Genesys Cloud Edge.
  • The Solution: Implement Force TURN in the WebRTC phone settings for remote workers. This forces all media to be relayed through the Genesys Cloud Cloud Edge, bypassing local NAT/firewall issues that typically plague peer-to-peer WebRTC connections.

Official References