SUBSCRIPTIONS: If you want to subscribe to updates for Emergency Services, click the Options menu button in the right-hand-corner of this article and select Subscribe. You will then receive email notifications when this article is updated with new release notes.
Check in here to see information about new releases from Emergency Services.
6/25/2026 – NG911 Phase 2 (i3) Compliance in Massachusetts
Sinch is now delivering location data to the Massachusetts’ NG911 system in a FCC Phase 2 (i3) compliant format.
The FCC adopted rules (FCC 24-78: Facilitating Implementation of Next Generation 911 Services), effective March 25th, 2025, which mandates Originating Service Providers (OSPs) to transition to Next Generation 911 (NG911). These mandates are triggered by valid requests from state or local 911 Authorities and require compliance within 6 or 12 months across two phases:
Navigating regulatory requirements can be complex and time-consuming. That is why Sinch proactively handles these integrations ahead of enforcement deadlines. Here is exactly what we’ve done in Massachusetts:
6/24/2026 – PSAP Outage Notification Service Update
Trouble Ticket Creation Improvement: Sinch has created a notification preview page in the Customer Portal when opening a PSAP Outage Notification ticket. Previously, when a user created a PSAP Outage Notification ticket using the Customer Portal, they did not receive a summary of the notification content or PSAPs included, based on the user’s inputs and selections. This enhancement has created a notification preview page whereby the Portal user will be able to see a preview of the notification content that the PSAPs will receive in the notification, as well as a list of the State and Counties who will receive the notification, so that the user can review and either confirm or cancel, as needed, prior to submitting the ticket and generating the notification.
6/23/2026 – Update to 933/Test Call Handling
Test/933: improved handling for Microsoft Teams PIDF-LO 933 calls. When a Microsoft Teams PIDF-LO 933 call is made, the caller is provided the ability to record up to 5 seconds of audio for playback on the call to validate bi-directional audio. Previously, if the caller did not record any audio during that 5 second window, then 5 seconds of silence would be played back to the caller. Moving forward, if no audio is detected/recorded, then the call will terminate rather than playing back 5 seconds of silence.
4/30/2026 – PSAP Outage Notification Service Update
Ticket Timing Update: Sinch has increased the automated ticket closure timeframe due to inactivity on a PSAP Outage Notification request/ticket from 24 hours to 30 days. Previously, if a PSAP Outage Notification ticket was opened and 24 hours passed without the Customer submitting an update to the ticket, the ticket would close automatically due to inactivity. In some scenarios, there are extended outages/issues and a material update every 24 hours is not practical, resulting in Customer opened PSAP Outage Notification tickets being closed for inactivity. When a Customer ticket is closed, the Customer has to open a new ticket should they want to notify PSAPs after those 24 hours have passed. The window of allowed inactivity has been increased from 24 hours to 30 days so that Customer’s have a longer timeframe to submit updates and generate follow-up notifications to PSAPs if/when needed.
3/31/2026 – Next Generation (NG911) i3 related enhancements
Location by Reference (egress to the PSAP / NG911 system): HTTP Enabled Location Delivery (HELD) is a protocol for delivering caller location information in an NG911 i3 format using a Location by Reference methodology. Sinch has added support for transmitting location data to NG911 i3 capable Public Safety Answering Points (PSAPs) using a Location by Reference method (i.e., HELD request and response), in addition to currently supported Location by Value method in the SIP invite (i.e., PIDF-LO embedded in the SIP invite). While all NG911 systems should support both Location by Reference and Location by Value methods for transmitting caller location data in an NG911 i3 format, some may only support one or the other initially. Sinch supporting both methods will accelerate further NG911 i3 adoption as PSAPs become ready.
Additional Data (ADR): ADR is a set of standardized information that provides PSAPs with supplemental details about the caller, the location, or the call itself (i.e., info about the service provider, device the call was placed on, building floor plans, etc…) to improve emergency response. Sinch will begin including, where supported, ADR data blocks along with location data when sending calls to i3 capable NG911 systems supporting ADR. More specifically, Sinch will include a Provider Information data block populated with Sinch service provider data, as well as Service Information data block populated with industry standard values for VoIP use cases. Sinch will additionally transparently pass-through any customer provided and properly formatted ADR data blocks without modification. Note: ADR support among NG911 systems is currently minimal.
Location Validation Function (LVF): the LVF is an important element of a NG911 system that validates civic location information against the authoritative GIS database information, designed to improve location accuracy and is required to achieve NG911 i3 standards compliance. In markets where the 911 Authority provides an LVF that Sinch has integrated with, Sinch will start providing feedback to customers during address validation if the address submitted to address validation passes the 911 Authority LVF validation. Note: currently the availability of an LVF is limited to only Massachusetts, but that will expand as additional 911 Authority’s support full NG911 i3 and make LVFs available to service providers for address verification. If the address passes the 911 Authority’s LVF as valid, then the customer will receive an address validation note of “LVF Validation” returned in the Validation Message parameter in the Portal and the validationMsg parameter in the /addressValidate API response (see example from the Portal immediately below).