PSAP Phone Number Allocation & DID Routing

Overview#

A multi-agency deployment might have one tenant operating a PSAP with dedicated 911 lines, a non-emergency administrative line, and a utility reporting service, all from the same platform. Getting calls to the right subsystem, with the right greeting, and with no cross-tenant leakage, requires more than simple forwarding rules. The Phone Number Allocation module manages that lifecycle end-to-end.

The module handles the allocation, routing, remapping, and release of Direct Inward Dialling (DID) phone numbers across the platform's telephony subsystems. A centralised inventory of available numbers is maintained per region and country, with each number allocated to a specific tenant and subsystem. Routing configuration determines how inbound calls are handled, which dashboard displays them, and which greeting plays. Cross-tenant number access is prevented at the database level, not just the application layer.

Key Features#

DID Inventory Management: Maintain a pool of available phone numbers with metadata including provider, region, country code, status (available, allocated, reserved), monthly cost, and reservation details. Query available numbers by region and country code for provisioning.
Tenant-Scoped Allocation: Allocate phone numbers to specific tenants and subsystems (PSAP, utilities, document telephony, mDOC) with customer labels, dashboard identifiers, and organisation scoping. Allocation records include auto-provisioning flags and timestamps for operational tracking.
Subsystem Routing: Each allocated number carries routing configuration that determines which subsystem handles inbound calls, which dashboard displays the call, and what customer label is used in greetings. The routing table supports multiple subsystems per tenant with independent number pools.
Number Remapping: Remap an allocated number from one subsystem to another within the same tenant without releasing and re-allocating. This enables operational flexibility when reorganising call routing or migrating between subsystems.
Number Release: Release allocated numbers back to the available pool when they are no longer needed, clearing routing configuration and tenant association while preserving the number in inventory.
Cross-Tenant Protection: Database-level constraints ensure that number allocation, remapping, and release operations can only affect numbers belonging to the requesting tenant. Cross-tenant number access is structurally prevented.
Subsystem-Aware Greetings: The routing configuration drives greeting selection for inbound calls. PSAP lines use country-specific emergency number greetings (911, 112, 119), while non-PSAP lines use the customer label from the DID routing record.

Use Cases#

PSAP Line Provisioning: Allocate emergency phone numbers to a PSAP tenant, configure routing to the PSAP subsystem, and associate numbers with specific dispatch dashboards for call display.
Multi-Subsystem Tenants: Organisations operating both PSAP and non-emergency telephony allocate separate number pools for each subsystem, with independent routing and greeting configuration.
Number Migration: Remap phone numbers between subsystems during operational reorganisation without disrupting the number's external-facing identity or requiring new number provisioning.
Regional Deployment: Query available numbers by region and country code to provision locally appropriate phone numbers for geographically distributed operations, including island and remote emergency services.

Integration#

The Phone Number Allocation module connects to the IVR routing system for inbound call handling, the voice AI session manager for provider selection and greeting injection, and the tenant administration interface for number management. Allocation and routing records are used by the session prewarming system to determine provider configuration before calls connect.

Open Standards#

ITU-T E.164: All DID numbers are stored, queried, and routed using the international public telecommunications numbering plan, with phone numbers represented in full E.164 format (e.g. +15551234567) throughout the allocation and routing tables.
ISO 3166-1 alpha-2: Two-character country codes are used in the DID pool inventory to scope available-number queries by country and to drive subsystem-aware greeting selection for nationally distinct emergency numbers (911, 112, 119).
NENA i3 (NENA-STA-010): The DID routing table is the entry point for NG9-1-1 conformance; each allocated number carries a target_subsystem value that determines which NENA i3 call-handling surface receives the inbound call and which EIDO incident record is created.
ITU-T E.112 / ETSI TS 102 180: Country-specific public emergency call numbers (911, 112, 119) are recognised at the routing layer to trigger dedicated PSAP subsystem handling and country-appropriate voice greetings, implementing carrier-independent emergency-access obligations.
NENA-STA-021 (EIDO) / RFC 7852: PSAP lines provisioned via DID allocation feed the Emergency Incident Data Object pipeline; the subsystem routing configuration determines which EIDO CallComponent and AdditionalData blocks are populated for each inbound call session.
EN 17128 (Advanced Mobile Location): The AML SMS receiver ingests caller location tied to inbound DID numbers; the DID routing lookup resolves tenant and subsystem context required to associate an AML location reading with the correct PSAP session.
GraphQL (June 2018 specification): Allocation, remapping, release, and routing-configuration queries are all exposed through the platform's GraphQL API, with Strawberry-typed schemas for the phone and PSAP domains.

Last Reviewed: 2026-04-02 Last Updated: 2026-04-14