We have been working on connecting Meta WhatsApp Business Calling directly to LiveKit SIP.
The integration was challenging because Meta’s SIP media differs from a typical PSTN SIP trunk. It requires:
SIP over TLS
ICE-lite negotiation
DTLS-SRTP instead of SDES-SRTP
Opus audio
Correct DTLS fingerprint and role negotiation
Reliable transport cleanup when either side hangs up
Initially, SIP signaling and DTLS negotiation succeeded, but we experienced one-way audio. Meta’s media reached the SIP server, while decoded audio was not consistently forwarded into LiveKit. We also encountered calls that remained active for several minutes after the remote party hung up because ICE and DTLS reader goroutines could block during teardown.
We implemented an opt-in solution that:
Adds Opus negotiation and encoding
Supports inbound UDP/TLS/RTP/SAVPF offers
Handles Meta’s ICE-lite candidates and credentials
Establishes ICE before starting DTLS
Derives SRTP keys from the negotiated DTLS session
Supports bidirectional encrypted audio
Cleans up ICE, DTLS, SRTP, and SRTCP without blocking
Leaves existing PSTN RTP and SDES-SRTP behavior unchanged
We have tested it with real WhatsApp calls, including bidirectional audio, remote hangup, and ordinary Twilio PSTN calls. All upstream CI, integration, Codecov, and automated review checks are passing.
We opened an upstream PR here:
Would this integration be helpful to others using WhatsApp Business Calling? We would appreciate feedback from the LiveKit maintainers and anyone interested in testing it with their Meta setup.
Nice write-up, and the problem list matches what makes Meta’s media awkward.
One thing worth addressing head-on in the PR description: LiveKit already ships a WhatsApp Connector in beta, documented under Telephony → Connectors. It bridges WhatsApp calls into rooms with codec translation and lifecycle management, and participants arrive with kind = CONNECTOR. That’s going to be the first question a maintainer asks, so better to answer it up front than have it come up in review.
You likely have a good answer, since the connector is a managed bridge that deliberately avoids SIP trunking while yours is direct SIP into livekit-sip. Worth checking whether the connector is available on self-hosted or Cloud only, because if it’s Cloud only then your PR fills a real gap and that’s the argument to lead with. Either way the distinction needs to be explicit rather than left for a reviewer to infer from 1100 lines of diff.
Worth looking at livekit/sip#685 as well. It reports outbound TLS to wa.meta.vc:5061 failing because the ALPN is hardcoded to sip and Meta responds with alert 120. That report is against Cloud rather than self-hosted, but if the same TLS config is in the path you touched, linking the two would help the PR get attention.
One practical suggestion: if the teardown fix (ICE and DTLS reader goroutines blocking on hangup) also affects non-Meta paths, split it into its own small PR. A focused bug fix merges quickly, whereas a 1100-line feature waits for someone with time to review it properly. Shame for a real fix to sit behind that.
I did explore the official WhatsApp Connector before going down this path. From what I found, the Connector is currently a LiveKit Cloud-only offering, so it doesn’t solve the self-hosted use case.
That’s really the gap I’m trying to address here: direct Meta/WhatsApp SIP media into livekit-sip while keeping the entire deployment self-hosted.
I’ve also now tested the implementation end-to-end against a self-hosted LiveKit deployment, and the full call flow is working — SIP signaling, DTLS-SRTP negotiation, Opus media, bidirectional audio, call lifecycle, and teardown.
Good call on livekit/sip#685 as well. I’ll review that separately because the TLS/ALPN issue could be relevant on the signaling side even though this work is primarily focused on the media path.
I did speak with the connector team on the back of this thread and can confirm the WhastApp Connector will remain a LiveKit cloud-only feature for the foreseeable future.