WhatsApp Calling SIP inbound from LiveKit not ringing (drops during dialing)

Telephony
,
1

We are integrating WhatsApp Calling via SIP with LiveKit Cloud.
Outbound INVITE reaches wa.meta.vc:5061 but calls never ring on destination WhatsApp number.

Observed from provider side:

  • call status stays “dialing”
  • then disconnects (“CLIENT_INITIATED”)
  • provider reported transport errors in some attempts:
    • “tls: no application protocol”
    • “transaction failed to complete (0 intermediate responses)”

Environment:

  • SIP destination host: wa.meta.vc
  • port: 5061
  • transport: TLS
  • From number: +5511978308670 (business number)
  • Tested destination numbers: +558494198787 and +5584994198787
  • Username: phone_number_id
  • Password: SIP password (recently rotated and updated)

Please verify on your side:

  1. if this business number is fully enabled for WhatsApp Calling SIP,
  2. if there are restrictions for destination format (with/without 9 in BR),
  3. if there are required TLS/SIP profile settings for third-party SIP trunks,
  4. if these call attempts are being rejected and why.

anyone knows what could be the problem or where can i find the proper support for solving

2

How are you connecting WhatsApp to LiveKit? Last I checked WhatsApp only supported Opus codec but LiveKit requires codecs like G711, or G722.

Did this work for you previously?

We have a WhatsApp beta. If you would like to use that let me know and we can send you the form.

3

Hi, I’m having the same problem. Were you able to fix it?

4

How are you converting the G711 to Opus?

5

@Tecnologia_Atlas, Adding to @CWilson’s line, the codec gap here is structural enough to lay out the three working architectures for anyone landing on this thread:

  • Transcoding SBC in front of LiveKit. WhatsApp Calling SIP requires Opus end-to-end; livekit/sip doesn’t expose Opus on the trunk side today (Support Opus on SIP Trunks · Issue #281 · livekit/sip · GitHub is open, 34 comments, updated last week). Run Asterisk / FreeSWITCH / kamailio+rtpengine in front of livekit-sip, carrier-facing leg speaks Opus to wa.meta.vc:5061, LiveKit-facing leg speaks G.711.
  • LiveKit’s WhatsApp Calling beta. The managed path CWilson mentioned upthread, lowest-effort if @Valentino_Giardino qualifies.
  • Drop WhatsApp Calling SIP. A standard PSTN trunk (Twilio / Telnyx) speaks G.711 out of the box. Users still reach you on a phone number, just not via WhatsApp.

Separately, the OP’s tls: no application protocol is an ALPN handshake mismatch, not the codec gap, but even past that, calls land in ringing/no-media because of the codec issue above.

6

@CWilson @Muhammad_Usman_Bashir

According to Meta docs, G.711 is supported:

I enabled it on my phone number settings with:

curl --location 'https://graph.facebook.com/v25.0/{YOUR-WABA-PHONE-NUMBER-ID}/settings' \
  --header 'Authorization: Bearer <TOKEN>' \
  --header 'Content-Type: application/json' \
  --data '{
    "calling": {
      "status": "ENABLED",
      "call_icon_visibility": "DEFAULT",
      "callback_permission_status": "DISABLED",
      "sip": {
        "status": "ENABLED",
        "servers": [
          {
            "hostname": "<YOUR-LIVEKIT-SIP-URI>",
            "port": 5061
          }
        ]
      },
      "srtp_key_exchange_protocol": "SDES",
      "audio": {
        "additional_codecs": ["PCMA", "PCMU"]
      }
    }
  }'

User-initiated calls to WhatsApp work.

Inbound trunk:

{
  "name": "meta-inbound",
  "numbers": [
    "{YOUR-WABA-PHONE-NUMBER}"
  ],
  "krispEnabled": true,
  "mediaEncryption": "SIP_MEDIA_ENCRYPT_ALLOW"
}

However, calls from LiveKit to WhatsApp were failing.

I tried the same flow using Asterisk as a bridge between LiveKit and WhatsApp, and it worked. I am trying to achieve the same result without Asterisk.

Just as @Muhammad_Usman_Bashir described, I found there was a TLS handshake mismatch between LiveKit SIP and Meta. I opened an issue tracking it here:

I also submitted a fix:

After addressing ALPN, calls consistently progressed through TLS and SIP digest authentication.
However, some attempts still intermittently fail with:
403 SDP Validation Error: Provided SDP is invalid

This response comes from Meta after 180 Ringing. Retrying the same call often succeeds, so it’s still unclear whether the issue is in LiveKit’s SDP offer or in intermittent SDP validation on Meta’s side…
I’ll continue investigating this on my side, but if anyone has seen this specific intermittent 403 SDP Validation Error from Meta, or has any insight into what part of the SDP Meta may be rejecting, I’d appreciate any pointers.

8

Today I Learned (TIL). I did not realize they added G711 support:

I will bring this and your PR up with our team.

9

Good catch on the G711 support, @Valentino_Giardino. Owning the codec piece, I overstated in #5 (Meta does accept PCMA/PCMU with the additional_codecs setting). And the ALPN PR landed exactly where the wire trace pointed; thanks for taking it from observation to a tracked issue + PR.

On the intermittent 403 SDP Validation Error after 180 Ringing: since retries succeed, the SDP isn’t structurally invalid every time, so it’s likely a field that varies between calls. Capture two SDP offers side-by-side (one successful, one rejected) and diff. Likely candidates to watch:

  • SRTP key exchange: your settings pin SDES, but if livekit-sip sometimes offers a=fingerprint (DTLS-SRTP) instead of a=crypto (SDES), Meta will reject.
  • Codec ordering in a=rtpmap: if the offer permutes the codec list between calls (PCMA first vs PCMU first), strict validators may reject the unexpected order.
  • a=rtcp-mux presence: non-deterministic inclusion is a known stumble point for some carrier validators.

If the diff is clean, the issue is Meta-side and worth flagging in #685.