NG911 Call Handling and ESInet Software: Why Text, Location and Transfers Still Break Between Neighbouring PSAPs

The call that has to move, and the data that does not

A 911 text conversation is running in one window. The caller's device location is refining in a second. The caller is describing a location that turns out to be across a boundary, so the call has to go to the neighbouring PSAP. In a properly deployed i3 environment that transfer carries the call and its associated data. In the environment most centers actually run, the neighbour is on a different vendor's platform, one side is still bridged to legacy trunks, and what arrives on the other end is a voice path and a verbal summary. The text thread stays behind. The location stays behind. The telecommunicator on the receiving side starts over with a caller who has already explained it twice.

That is the gap. The standard describes an interoperable world. The deployed reality in most states is a mixed estate: some PSAPs migrated, some on legacy customer premises equipment, some on a shared ESInet and some not yet, all inside one mutual aid region where calls have moved between centers for forty years.

What the standard gives you and what it does not

The NENA i3 architecture defines how an emergency call is routed and delivered on an IP network, how location is resolved, and how additional data is referenced. It is a genuine achievement and it is the right target. What it does not do is deliver a working regional program, for three reasons that are entirely local.

First, routing depends on your GIS. In the i3 model, the routing function resolves a location against authoritative geospatial data, which means road centerlines, address points and PSAP boundary polygons maintained by counties that have never had to make them agree with each other. Boundary gaps and overlaps that were invisible under legacy routing become routing failures. Provisioning that data, validating it continuously and reconciling it between jurisdictions is a real, permanent piece of software work, and it is nobody's product.

Second, additional data. The standard says a call can reference more information. It does not decide which sources your state trusts, how a medical alert subscription, a building floor plan, a school layout or a telematics feed should be presented, or what a telecommunicator is allowed to see for how long. Those are policy decisions that turn into an interface someone has to build.

Third, the mixed estate. Interoperability between two different vendors' platforms across a state boundary during a hurricane is not a specification problem, it is an integration problem with two commercial companies and two authorities attached.

Where the platforms genuinely stop

• Cross vendor transfer fidelity. Each platform handles a transfer well inside its own estate. Between estates, and particularly where one side is still partly legacy, the data that accompanies the call is the first thing to be lost. Nobody owns that seam because it sits between two contracts.
• GIS lifecycle. Platforms consume routing data. They do not fix your counties' data, do not tell an addressing authority which of its 4,000 address points fail validation, and do not maintain the correction workflow that keeps a boundary clean over years.
• Regional visibility. A state or regional authority funding many PSAPs from surcharge revenue needs comparable operational data across all of them. Getting that from several vendors' platforms, in one shape, on a schedule, is not a feature any of them sells.
• Local policy on data. What a telecommunicator sees, what is retained, what is disclosed and what is redacted are set by state law and local policy, and the platform is not where those decisions live.
• Care for the mixed period. Migration takes years. The interim, where half the region is next generation and half is not, is where the operational risk sits and it is not on anybody's roadmap because it is temporary by definition, which is cold comfort when it lasts five years.

What a custom build should actually cover

Start with the GIS pipeline, because routing accuracy is the foundation and it is measurable. Build continuous validation against the data model your state has adopted, with per county dashboards showing failure counts and a correction workflow that assigns errors to the addressing authority that owns them. Include boundary reconciliation between adjacent jurisdictions, since a gap between two counties is nobody's error until a call routes to the wrong center. This work is unglamorous and it is the highest value thing a 911 authority can commission.

Second, the transfer and awareness bridge. When a call has to move between centers on different platforms, capture the incident context, the text thread, the location history and the caller information in a shared record both sides can see, so the receiving telecommunicator opens a screen rather than starting a conversation. This is not a replacement for standards based transfer. It is the working layer for the years before every neighbour is on the same architecture.

Third, the additional data view. One pane that assembles what your authority has decided the telecommunicator may see for this call, with an access log, retention rules and a clean way to add a source without a platform release.

Fourth, regional reporting. Normalise operational data from every PSAP in the region into one model so the authority can answer questions about call volume, answer times, transfers and abandoned calls consistently, and so surcharge funded investment can be argued from evidence.

What it costs and how long it takes

In our delivery experience, the GIS validation and reconciliation pipeline alone runs $80,000 to $180,000 and ships in 3 to 5 months, and it is where we tell most authorities to start. The wider layer with cross PSAP transfer context, the additional data view and regional reporting runs $150,000 to $350,000 over 4 to 8 months. A full regional program adding shared logging access, deeper analytics, per PSAP configuration and multi state coordination runs $400,000 to $900,000 over 9 to 18 months.

Cost drivers here are unusual. The number of PSAPs and the number of distinct call handling vendors in the region, since each vendor integration is a separate commercial and technical negotiation. The state of county GIS data, which is the single largest unknown and occasionally requires funding remediation work at the counties themselves. Whether your ESInet provider will expose the interfaces you need, which is a contract question first. And security posture, since anything touching criminal justice information or call content carries authentication, audit and retention requirements as engineering scope.

What we do not quote is a custom call handling core, because we would not build one. If a vendor offers to, ask them who answers the phone at 3am on a Sunday when the position software will not launch and the center is taking calls on backup.

When buying is the right call

Buy the call handling platform, always. VESTA, Solacom Guardian, Carbyne and RapidDeploy operate under certification, redundancy and support obligations that took years to build. Choosing between them is a real procurement, and the questions worth asking are about transfer behaviour with your specific neighbours, how they expose data to you, and what their interim behaviour is while part of your region is still legacy.

Buy the ESInet as a service in most cases. Owning transport infrastructure is not where a 911 authority's advantage lies.

Build when you are a state or regional authority responsible for many PSAPs and you cannot get comparable operational data across them. Build when your counties' GIS is the reason calls route wrong and no product will fix it. Build when your busiest transfer relationship crosses a vendor boundary and telecommunicators are reading location coordinates over a phone line. Build when your authority has decided what additional data telecommunicators should see and no platform will assemble it on your terms.

How to choose a developer

Ask them to explain how a location is resolved to a PSAP in the i3 model. If they cannot describe the role of authoritative GIS data in routing without prompting, they will treat your geospatial work as a mapping exercise and you will fund a rewrite.

Ask what they have integrated on the telephony side, by product name, and what the integration method was. There is a large gap between a documented interface, a logging recorder feed and screen scraping, and only the first two belong in an emergency environment.

Ask how they handle a source that is unavailable. In an emergency system, a slow or dead additional data source must never delay the screen the telecommunicator is working. Timeouts, degradation and clear indication of what is missing are design decisions, not bug fixes.

Ask how they will test. The only credible answer involves telecommunicators in a lab with realistic call scenarios including transfers to a neighbour, not a demo to a director.

Ask who owns the code, the pipelines and the data, in writing before kickoff. At Digital Heroes it is yours from the first commit, which matters more than usual here because a regional authority's software outlives its vendors. Start by running a validation pass over one county's GIS data against your state's adopted model. The error count that comes back will tell you whether routing or transfers is your real first project.