[Ng911sig] NG911 SIG kickoff and next steps

[Brian Rosen]

Here is some background material for those not familiar with 911

We are in the midst of deploying an entirely new 911 system called Next Generation 9–1-1, NG911.  Over half the US and all of Canada is now running on NG911 but most deployments have a lot of gateways to older technology on both the origination side (“Originating Service Provider” = OSP) and the "Public Safety Answering Point" = PSAP side.  There is a technical specification for NG9-1-1, NENA-STA-010, currently at Version 3.  That is colloquially known as “i3”.  The OSP signaling for i3 is different from what you are used to, and is based on RFC6881.  NG911 runs on a private "Emergency Services IP Network” = ESInet.

There are new FCC requirements on OSPs that compel them to upgrade to NG911 signaling, in two phases.  Phase 1 is basic SIP signaling, with backwards compatible location.  Phase 2 is i3 signaling with location included in the call either by value or by reference.  The most recent FCC updates include new requirements on “Multi-Line Telephone Systems” (MLTS), e.g, large PBX systems.   Basically, MLTS has to move to i3 along with the OSPs.

There is zero development on the older, E911 system.  Everything new is NG911 based. 

i3 is all SIP signaling from the OSP to the “Next Gen Core Services” = NGCS, and from the NGCS to the PSAP.   In addition to the RFC6991 based emergency call signaling, i3 also makes extensive use of “Additional Data”, RFC7852.  If you are sending a call to 911, you must include the “ServiceInfo” and “DataProvider” blocks.  If you have other data, the way you get it to the PSAP is via Additional Data.  This includes alarm data.  The key, critical part of this path is that the data gets to the PSAP that is actually handling the call,  even when calls are being diverted or handled differently than normal.  This is fundamentally different from older mechanisms that assumes a fixed relationship between a location and a PSAP.  The data can be passed to responders, and it gets to the actual responder for the incident.  There is a standardized data structure (EIDO) that encapsulates everything we know about an incident that is used to pass data between PSAPs and between PSAPS and responders, even tow trucks.  EIDOs aren’t used prior to the ESInet, we use Additional Data.

i3 is inherently multimedia: voice, video and two forms of text: Instant Message (MSRP) and Real Time Text (RTT), RFC4103.  Video and text implementation is spotty at present.  But don’t think about trying to get audio/video or text into 911 any way other than the standards based ways.  Yes, we know there are non-standard implementations, but we are working hard to get rid of them.

NG911 has its own PKI.  The root CA (PCA) is deployed.  Deployment down to all i3 elements is spotty but rapidly increasing.  This means you can reliably know you are talking to a PSAP or other NG911 entity.   OSPs are not expected to be within the i3 PKI.  Responders eventually will (we hope).   It would be excellent if this work can offer some way for NG911 entities to reliably know who they are talking to.

i3 has text on interacting wifi STIR/SHAKEN.  All incoming calls are validated, but we never reject calls to 911 - we just inform call takers that there may be issues.  Please remember that 911 may “call back”.  The i3 spec says that NG911 can sign calls, meaning it is part of the SHAKEN infrastructure. That has not been implemented yet.

A hole that we have at present is that we don’t sign location.  We should, and that is an opportunity for further work.  Of course, the form and transport protocols for location are specified and do have the appropriate security.

Happy to answer any questions about i3.  Many of you know me, I’m sure, but for those who don’t, I’m a co-chair of the i3 architecture working group in NENA, which is the source of the NENA-STA-010 spec.  I am co-chair of the sipcore (and vcon) working groups in IETF and have been working on this stuff for a VERY long time.

Brian


> On Oct 19, 2026, at 10:19 AM, Marc Robins via NG911sig <ng911sig at sipforum.org> wrote:
> 
> Hi Scott and all SIG Participants,
> 
> You haven’t missed anything  - we’ve been in the process of recruiting a bunch of folks (some of whom were mentioned during the virtual BoF), and wanted to give them a bit more time to join the group before we scheduled the next meeting.
> 
> Will be in touch in the next few days re: the next meeting.
> 
> All best,
> 
> Marc
> 
>> On Oct 19, 2026, at 10:03 AM, Scott Tabor via NG911sig <ng911sig at sipforum.org> wrote:
>> 
>> 
>> Hi everyone,
>> 
>> I joined the NG911 SIG mailing list earlier this month and received the welcome message although I haven’t seen any discussion or meeting announcements yet.
>> 
>> Are there plans for a kickoff meeting, an initial scope of work, or requests for contributions?
>> I’d also appreciate knowing whether anything has circulated that I may have missed.
>> 
>> >From the DICE / IPtelX side, we’re interested in contributing operational experience from alarm monitoring and life-safety communications, particularly around reliable call delivery, identity preservation, and interoperability.
>> 
>> I look forward to all of our participation.
>> 
>> 
>> __________________
>> Scott Tabor
>> Senior Telephony Engineer
>> scott.tabor at iptelx.net <mailto:scott.tabor at iptelx.net>
>> Main:  (989) 891-2900 (ext 2828)
>> Direct:  989.891.2828
>>  <https://iptelx.net/>
>> <image.png> <https://iptelx.net/>
>> 
>> www.IPtelX.net <http://www.iptelx.net/>
>> <image.png>
>>  <https://dicecorp.com/>_______________________________________________
>> NG911sig mailing list
>> NG911sig at sipforum.org
>> http://mail.sipforum.org/mailman/listinfo/ng911sig
> _______________________________________________
> NG911sig mailing list
> NG911sig at sipforum.org
> http://mail.sipforum.org/mailman/listinfo/ng911sig

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.sipforum.org/pipermail/ng911sig/attachments/20261019/3c3ffeb2/attachment.html>