Public safety on the same engine

Not certified, not yet live. These profiles have not run against a live ESInet, P25 RFSS or PSAP CAD, and are not certified for live 911 or radio dispatch. They are tested against a real ISSI capture, NENA sample data and stand-ins. Office 911 (Kari's Law, RAY BAUM'S Act locations) is part of the phone system, not this track.

We are looking for design partners: a PSAP, a 911 authority or a radio shop willing to run BitVoice in a lab or in shadow mode beside their current equipment. Open an issue titled "Design partner" and we will get in touch.

911 profile

NG911 call handling for a PSAP

• NENA i3 calls from the ESInet with the caller's PIDF-LO location and the network's additional data, shown to the call-taker as the call rings
• ALI spill over TCP and EIDO over HTTPS to any CAD when a call is answered
• Location rebids and transfers between PSAPs with the data kept
• The NENA i3 log, and answer-time reports by call-taker and hour against your goal, as CSV too
• TTY (deaf callers' text telephones) decoded and answered on every 911 call, real-time text (RFC 4103) and text to 911 from a text control centre (MSRP, over TLS too), in one conversation on the call
• Caller video and photos by a link, no app: live camera (WHIP), photos, clips and recordings of the live video kept with their SHA-256, time and GPS, and named in the EIDO to CAD; opened blurred until revealed, with an exposure report for the wellness programme; CAD and units watch by link (WHEP)
• A map of the caller's position and its uncertainty, from your own tiles (works offline)
• Legacy 911: CAMA trunks on telephony cards, and location looked up by callback number for calls that bring none, by HELD or the old ALI link (network or serial port, read by your provider's layout); ALI spill to CAD over the network or a serial port
• Report layouts: lay out your state's form (rows by day, week, month, hour or call-taker; your columns and headings) and run it as a table, a spreadsheet or a page to print
• Test calls (urn:service:test.sos) answered by themselves, as NENA i3 section 9 asks

Radio console

Radio dispatch on the same headset as the phones

• Radio-over-IP channels through gateways (JPS, Omnitronics, Cisco, Telex and others): hold to talk, monitoring, patches
• P25 talkgroups over the ISSI: the console joins a talkgroup's home RFSS, asks for the floor, shows the talking unit and its emergency flag
• Encrypted talkgroups (TIA-102.AAAD): AES-256, DES-OFB and triple DES. Keys are never shown again once saved; without a key the audio is muted, never noise
• Private calls: a dispatcher calls a radio by unit ID, and radios call the console
• Alert tones: steady, warble, pulsed and beep
• Every transmission recorded in a radio log with unit, dispatcher, tone, emergency and encryption, played back from the log
• Emergencies stay raised until a dispatcher acknowledges them; simulselect; radio names (Engine 5, not 1205); radio positions from your radio data gateway on a map
• Radio data to CAD: who is talking where, emergencies and each transmission, as JSON

NG911 core

NG911 Core Services for a 911 authority

• An ESRP with policy rules by service, PSAP, schedule and missing or suspicious location, with overflow and a default PSAP
• An ECRF answering LoST (RFC 5222) from your service boundaries
• An LVF validating civic addresses against NENA address points and road centrelines
• A BCF at the ESInet edge: calls per minute and at once per source, deny lists, STIR/SHAKEN checks, suspicious calls marked for the policy rules
• A LIS answering HELD by telephone number, a forest guide for places outside your areas, and an i3 logging service that takes signed log events, checked against the PSAP Credentialing Agency
• The NENA i3 web services: a Policy Store whose signed routing policies the ESRP runs, discrepancy reports, bad actors, geocode and MSAG conversion, an ADR, the service/agency locator, dequeue registration and a test call generator, each checked against NENA's published definitions