This is the lab and design-partner track. The 911 profile is not certified for live 911 use, and it has not yet run against a live ESInet or a real PSAP CAD; it is tested against NENA sample data, recorded captures and stand-ins. It stays off the menu until Public-safety profiles (lab) is switched on in Settings, and its screens carry that notice. BioDream LLC is looking for design partners (a PSAP or a 911 authority) willing to run it in a lab or in shadow mode beside their current equipment. Emergency calls from an office's own phones are not part of this track; those work on every BitVoice system.
What NG911 call handling is
When you dial 911, the call reaches a public safety answering point (a PSAP), where a call-taker answers, finds out where you are and what is happening, and passes the incident to dispatch. The equipment that answers and presents the call is call-handling equipment, sometimes called customer premises equipment (CPE). The older generation of this equipment was built for analogue trunks and a separate database lookup for the caller's address; the new generation, Next Generation 911, is built on internet protocols and a dedicated emergency services IP network, the ESInet.
The modern design is set out by NENA, the National Emergency Number Association, in a standard called i3. In i3, a 911 call arrives as a SIP call over the ESInet, and the caller's location travels with it as a small XML document called PIDF-LO (Presence Information Data Format, Location Object), either as a civic address (street, city) or as geographic coordinates with a radius of uncertainty. Sometimes the location is not in the call itself but referenced, and the PSAP fetches it with a protocol called HELD. Alongside location comes additional data (RFC 7852): the service provider, the kind of service, the device, the subscriber. When the call-taker answers, the incident is handed to the computer-aided dispatch system (CAD); the newer way to do that is an EIDO, an Emergency Incident Data Object (NENA-STA-024), and the older way is an "ALI spill," a block of text the carrier's address database used to send that legacy CAD systems still read.
A concrete example: a wireless 911 call arrives with coordinates and an uncertainty of 40 metres; the call-taker sees the point and its circle on a map, the caller is moving, so the call-taker rebids for a fresher fix, and when it comes back more precise the map updates. On answer, CAD receives both the ALI spill and the EIDO.
Where it usually goes wrong
The point of failure that matters most in 911 is a lost call. A routing mistake that would send an office call to voicemail must never drop a 911 call; a transfer to another PSAP that fails to connect must not leave the caller in silence; a phone that hangs up the instant after a blind transfer must not end the whole call. Location is the second hazard: a rebid that replaces a good GPS fix with a rough cell-tower estimate can send responders to the wrong place, so the system has to reason about which location to trust rather than blindly take the newest.
Integration is the third. Legacy CAD reads a plain-text ALI spill over TCP or a serial cable and cannot be forced to encrypt it; a modern CAD takes an EIDO over HTTPS, and sending a caller's location and a bearer token over plain HTTP across a network would be a serious leak. ALI database layouts differ by state and vendor, so a fixed parser reads one state's format and garbles another's. And a call that brings only a callback number and no location needs a lookup against the right database before the location appears.
How BitVoice does it
BitVoice answers 911 calls as a PSAP's call-handling system. Add the trunk from your ESInet provider or the core's ESRP on Trunks and switch on From the ESInet; send its calls to your call-takers on Call routing; and on 911 calls enter your agency ID and what CAD takes (the ALI listener's address and port, and the EIDO address). When a 911 call rings, 911 calls shows the civic address the network sent, the position with its uncertainty drawn on a map, the provider, the kind of service, the device and subscriber when the call brought them, and anything that went wrong reading it. A call whose location is a reference has Rebid location, which asks again for a caller who is moving.
When a rebid changes the location, the location check says which to show first and why: the new one as a rule, but the first one when it was a precise device fix (GPS, within 100 m) less than two minutes old and the new one is rougher, and both when two disagree by more than their uncertainty allows, so the call-taker asks the caller. The first location always stays on the call.
A 911 call is never refused. A voice call from the ESInet whose route would turn it away (because the route hangs up, rings an empty group, or does not exist) or that nobody answers rings every call-taker instead, until someone answers or the caller hangs up; a text call waits the same way; and Health warns about such a route so it can be fixed. Nor is a call dropped by a transfer: when a transfer cannot connect, the call goes back to that call-taker while they are still on, and if they have already hung up (most desk phones do after a blind transfer), every call-taker rings. A 911 call is never sent to voicemail or a no-answer destination. A caller who vanishes (one side stops sending audio for a minute while the other still sends) ends the call with the reason recorded, and silence still sends packets, so a caller who cannot speak keeps the call up.
When a call-taker answers, CAD gets, each on its own so a down CAD never holds up the call, the ALI spill over TCP (callback number, class of service, address, position and uncertainty, provider) and the EIDO of NENA-STA-024 by HTTPS POST with a bearer token if set. The EIDO address must be https, or plain http only to a CAD on this same computer: an EIDO carries the caller's location and token, so it never crosses a network unencrypted, and saving any other plain http is refused, with Health showing an old unsafe one in red. The ALI spill itself is plain TCP, as legacy listeners take it, so when it goes to another computer Health warns and the chapter advises a direct serial link or a private circuit. BitVoice's EIDOs are checked against NENA's published EIDO schema, and the agency ID (a domain such as psap.county.example.gov) names the agency in EIDOs and the i3 log.
For legacy 911, CAMA trunks on telephony cards are supported (an E&M start set to "CAMA (911 trunk)", with the caller's number read in MF and area codes listed for traditional CAMA's numbering-plan digits). A call that brings only a callback number can be looked up by Location lookup (ALI) over HELD (RFC 5985, by telephone number as RFC 6155 has it), asked as the call arrives without holding it up. Where there is no HELD server, the legacy ALI link is spoken the old way, a request sent and a text record read back over the network or a serial port, and because ALI layouts differ by provider and state you place each field by line, column and length from a printout, with a sample record read on screen to check it. Protocols that are not a request-and-text answer, such as PAM and E2, need a gateway.
A map of the caller's position comes from your own tiles: an .mbtiles file for a map that works offline, or a tile server, with the call-takers' browsers fetching tiles from BitVoice only. The i3 log keeps each call's NENA i3 events, one file a day. Answer times shows how many calls were answered within your goal (NENA asks 90% within 15 seconds, 95% within 20), the abandoned ones and each call-taker's average, and because every state has its own form you lay yours out under Report layouts and run it as a table, a spreadsheet or a page to print. Test calls (urn:service:test.sos) are answered by themselves, as NENA i3 section 9 asks.
Why BitVoice fits
The 911 profile runs on the same one Go program as the phone system, with no Asterisk underneath, so the reliability rules (no call lost, scripts time-limited with a fixed fallback) are the same ones the office side is held to. Everything is in the web interface: the ESInet trunk, the CAD addresses, the ALI field layout read from a sample record, the map tiles, the report layouts. It is Apache-2.0 and free. And it is honest about safety in the engineering: a 911 call is never refused or dropped, the location check reasons about which fix to trust and keeps both when they disagree, EIDOs are refused over unencrypted network paths, and the EIDOs themselves are validated against NENA's own schema. Live 911 transcripts can be written on the server with whisper so the audio stays in the building.
What has been tested, and what has not
The maturity table rates the whole 911 profile Lab: never on a live ESInet or a real PSAP CAD, and not certified. It is tested against NENA's published schemas and sample data, stand-ins for the ESInet, ESRP and CAD, Wireshark for the message formats, and the supporting tools listed for the other public-safety parts. EIDOs are checked against NENA's EIDO schema; the i3 interactions are checked against NENA sample data. CAMA, HELD lookup, the legacy ALI link and the map are built and tested in the lab, not against a live selective router, a real ALI database or a production map service. Nothing here should be read as a claim of certification or of use at any PSAP; the invitation is to design partners to help prove it against real systems.