LiveKit experienced a major incident on May 6, 2026 affecting Global SIP, lasting 3h 17m. The incident has been resolved; the full update timeline is below.
Affected components
Update timeline
- investigating May 06, 2026, 07:46 PM UTC
We are observing outbound calls using TLS with Twilio trunks fail and are investigating this urgently
- monitoring May 06, 2026, 08:05 PM UTC
A fix has been implemented and we are monitoring the results. The issue persisted from 18:10 - 19:58 UTC. We will follow up with a postmortem as soon as possible.
- monitoring May 06, 2026, 08:32 PM UTC
We've realized that this incident has impacted all outbound calls using TLS (not just those placed through Twilio) and have updated the incident title accordingly.
- resolved May 06, 2026, 11:04 PM UTC
We have observed no more errors since we pushed the fix. Resolving the incident.
- postmortem May 10, 2026, 03:11 PM UTC
**Summary** On 2026-05-06 between 18:07 and 19:56 UTC, a code change to the API server which handles CreateSIPParticipant calls caused outbound calls to incorrectly inherit their encryption settings from outbound trunks. This resulted in calls that didn't specify an encryption setting in the request itself to be sent without SRTP, even if the LiveKit trunk was configured to require it. If users had configured their carrier’s trunk to expect SRTP \(by enabling Twilio’s Secure Trunking, for example\) those INVITEs were rejected. Approximately 2% of global outbound SIP calls were affected during the incident window. **Impact** - Window: 2026-05-06 18:07 - 19:56 UTC - Scope: Outbound TLS calls where the encryption setting was not set in the request and the carrier was configured to expect SRTP. - Customer symptom: Outbound calls failed at the carrier with `488` rejections such as Twilio's `32208 SIP trunk or domain is required to use secure media (SRTP)`, `Not Acceptable Here`, or `Media Encryption Required`. - Identifying impact: Customers can search their call records during the window for failed outbound calls returning `488` from their carrier with one of the above reason phrases. **Root cause** A recent code change introduced a regression in how SIP trunk encryption settings were applied to outgoing calls. SIP trunks configured to require SRTP had that requirement silently dropped on outbound INVITEs when the per-call request did not also explicitly set an encryption mode. As a result, outbound calls were sent without SRTP, and carriers that were configured to expect SRTP on TLS correctly rejected them. **Timeline \(UTC\)** - 18:07 - Production deployment containing the regression went live. - 18:39 - Internal monitoring paged on a periodic end to end functionality test. - 19:42 - First customer-reported outbound call failures. - 19:56 - Fix deployed to production. Failure rate returned to baseline. **Resolution** A fix was deployed that ensures trunk-level SRTP requirements are correctly applied to outbound calls. Regression tests covering this and the adjacent code paths have been added to prevent the same class of issue. **What we are doing to prevent recurrence** - Strengthening pre-deployment validation requirements for changes that affect our SIP infrastructure. - Improving the reliability of our automated test coverage so similar regressions are caught before reaching production.