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.