Hello team I am trying to integrate Whatsapp Calling with livekit. All the configs are done but while creating an outbound trunk with transport as TLS, I am not getting the SIP invite. On the other hand, if I am having transport as Auto/UDP, I am getting the SIP Invite but its not moving forward. Any idea on how to fix this

Thanks for reaching out, Achintya. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.

│INVITE sip:+917417508633@wa.meta.vc:5061 SIP/2.0 172.31.34.11:5060 163.70.144.1925061│Via SIP/2.0/UDP 13.235.180.195:5060;rport;branch=z9hG4bKPj06487aaa-f766-4d92-8a1a-3c16f3df608a ──────────┬───────── ──────────┬─────────│From: sip:+15551650393@13.235.180.195;tag=f8ee3946-b141-4f1b-91ad-74b59f0bab0a 141332.054373 │ INVITE (SDP) │ │To: <sip:+917417508633@wa.meta.vc> +0.500469 │ ──────────────────────────> │ │Contact: sip:+15551650393@13.235.180.195:5060 141332.554842 │ INVITE (SDP) │ │Call-ID: 65314325-a68b-4d10-b923-ea0562913edb +0.999347 │ ────────────────────────>>> │ │CSeq: 21814 INVITE 141333.554189 │ INVITE (SDP) │ │Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, INFO, MES +2.000163 │ ────────────────────────>>> │ │SAGE, REFER 141335.554352 │ INVITE (SDP) │ │Supported: 100rel, timer, replaces, norefersub, histinfo +4.000014 │ ────────────────────────>>> │ │Session-Expires: 1800 141339.554366 │ INVITE (SDP) │ │Min-SE: 90 +7.999732 │ ────────────────────────>>> │ │P-Asserted-Identity: "00919240209440" sip:00919240209440@13.235.180.195 141347.554098 │ INVITE (SDP) │ │Remote-Party-ID: "00919240209440" sip:00919240209440@13.235.180.195;party=calling;privacy=off;screen=n +16.000045 │ ────────────────────────>>> │ │o 141403.554143 │ INVITE (SDP) │ │Max-Forwards: 70 │ ────────────────────────>>> │ │User-Agent: Asterisk PBX 23.2.0-rc1 │ │ │Content-Type: application/sdp │ │ │Content-Length: 263 │ │ │ │ │ │v=0 │ │ │o=- 193060164 193060164 IN IP4 13.235.180.195 │ │ │s=Asterisk │ │ │c=IN IP4 13.235.180.195 │ │ │t=0 0 │ │ │m=audio 52918 RTP/AVP 8 0 101 │ │ │a=rtpmap:8 PCMA/8000 │ │ │a=rtpmap:0 PCMU/8000 │ │ │a=rtpmap:101 telephone-event/8000 │ Above meta is not responding

Thanks — I’m looking at the INVITE you pasted (UDP source 13.235.180.195 -> destination wa.meta.vc:5061) and that the Meta gateway is not responding. What I recommend next (please run these and share the outputs you can): 1) Confirm TLS connectivity from your LiveKit host • Run:

openssl s_client -connect wa.meta.vc:5061 -servername wa.meta.vc

• Paste the handshake output (or any errors). If it times out or shows cert/name errors, that explains no INVITE over TLS. 2) Check whether Meta requires SNI or a specific Host header • The INVITE’s Request-URI is correct, but the TLS SNI must match the certificate name Meta expects. If openssl shows a different cert, note the CN/SAN. 3) Confirm whether Meta requires mutual TLS (client certificate) • If they require client certs, the TLS handshake will be rejected silently—confirm with the gateway spec and check openssl for "verify return code" or "handshake failure". 4) Verify LiveKit’s outbound transport behavior • When transport=TLS, ensure LiveKit is actually attempting TCP/TLS to port 5061 (not still sending UDP). Share LiveKit SIP/log lines for the TLS attempt (connection attempt, TLS errors). 5) For the UDP/Auto case (INVITE arrives but no progress) • Share the SIP response codes (if any). If no response, Meta may require TLS-only signaling. • Check SDP: your SDP shows RTP/AVP PCMA/PCMU (no SRTP). Meta/WhatsApp often requires secure media (SRTP). If they expect SDES or DTLS-SRTP and you send plain RTP, they’ll drop the call. • Confirm codecs and whether media must be encrypted; if required, enable SRTP (DTLS-SRTP) and ensure correct SDP format. 6) Firewall / NAT • Ensure outbound TCP 5061 and RTP ranges are allowed and not intercepted by a proxy that strips SNI or TLS. • Verify the Contact and SDP IP (13.235.180.195) is reachable from Meta for RTP. What to share back: • openssl s_client output for wa.meta.vc:5061 • LiveKit SIP/TLS attempt log lines (TLS connect errors) • Any SIP responses from Meta after the UDP INVITE (4xx/5xx/none) • Confirmation if Meta requires mutual TLS or encrypted media Send those and I’ll pinpoint whether this is a TLS handshake/SNI/client-cert issue or an SDP/media mismatch and give exact config changes. , with interactive elements

CONNECTED(00000003) depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root G2 verify return:1 depth=1 C = US, O = DigiCert Inc, CN = DigiCert Global G2 TLS RSA SHA256 2020 CA1 verify return:1 depth=0 C = US, ST = California, L = Menlo Park, O = "Meta Platforms, Inc.", CN = *.meta.vc verify return:1 --- Certificate chain 0 s:C = US, ST = California, L = Menlo Park, O = "Meta Platforms, Inc.", CN = *.meta.vc i:C = US, O = DigiCert Inc, CN = DigiCert Global G2 TLS RSA SHA256 2020 CA1 aPKEY id-ecPublicKey, 256 (bit); sigalg: RSA-SHA256 vNotBefore Jan 22 000000 2026 GMT; NotAfter: Apr 22 235959 2026 GMT 1 s:C = US, O = DigiCert Inc, CN = DigiCert Global G2 TLS RSA SHA256 2020 CA1 i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root G2 aPKEY rsaEncryption, 2048 (bit); sigalg: RSA-SHA256 vNotBefore Mar 30 000000 2021 GMT; NotAfter: Mar 29 235959 2031 GMT --- Server certificate -----BEGIN CERTIFICATE----- MIIGBjCCBO6gAwIBAgIQCVY9u5LDrRWEsCpU8uObNjANBgkqhkiG9w0BAQsFADBZ MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMTMwMQYDVQQDEypE aWdpQ2VydCBHbG9iYWwgRzIgVExTIFJTQSBTSEEyNTYgMjAyMCBDQTEwHhcNMjYw MTIyMDAwMDAwWhcNMjYwNDIyMjM1OTU5WjBqMQswCQYDVQQGEwJVUzETMBEGA1UE CBMKQ2FsaWZvcm5pYTETMBEGA1UEBxMKTWVubG8gUGFyazEdMBsGA1UEChMUTWV0 YSBQbGF0Zm9ybXMsIEluYy4xEjAQBgNVBAMMCSoubWV0YS52YzBZMBMGByqGSM49 AgEGCCqGSM49AwEHA0IABF9KkulX014J5O3VmuZRf+xywE7IeRDd4ij60l6bH1Hx OWx+hvesXrqpQY2wdHR5NMGo5MIgEJzcbRPmGms4Gw+jggOCMIIDfjAfBgNVHSME GDAWgBR0hYDAZsffN97PvSk3qgMdvu3NFzAdBgNVHQ4EFgQUwSloZKAkRE984kek gh0NPOELZq0wHQYDVR0RBBYwFIIJKi5tZXRhLnZjggdtZXRhLnZjMD4GA1UdIAQ3 MDUwMwYGZ4EMAQICMCkwJwYIKwYBBQUHAgEWG2h0dHA6Ly93d3cuZGlnaWNlcnQu Y29tL0NQUzAOBgNVHQ8BAf8EBAMCA4gwEwYDVR0lBAwwCgYIKwYBBQUHAwEwgZ8G A1UdHwSBlzCBlDBIoEagRIZCaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0R2xvYmFsRzJUTFNSU0FTSEEyNTYyMDIwQ0ExLTEuY3JsMEigRqBEhkJodHRw Oi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRHbG9iYWxHMlRMU1JTQVNIQTI1 NjIwMjBDQTEtMS5jcmwwgYcGCCsGAQUFBwEBBHsweTAkBggrBgEFBQcwAYYYaHR0 cDovL29jc3AuZGlnaWNlcnQuY29tMFEGCCsGAQUFBzAChkVodHRwOi8vY2FjZXJ0 cy5kaWdpY2VydC5jb20vRGlnaUNlcnRHbG9iYWxHMlRMU1JTQVNIQTI1NjIwMjBD QTEtMS5jcnQwDAYDVR0TAQH/BAIwADCCAXwGCisGAQQB1nkCBAIEggFsBIIBaAFm AHYAZBHEbKQS7KeJHKICLgC8q08oB9QeNSer6v7VA8l9zfAAAAGb40KjDgAABAMA RzBFAiEAkUK3hwnh143RvfdEOXLB7BsddR8XSRA5JCeGCyWjZM0CIDNKG57t2i94 q08kx5H2lwyHZ/lqdZC+5CWSP0tu0jGIAHUAFoMtq/CpJQ8P8DqlRf/Iv8gj0IdL 9gQpJ/jnHzMT9foAAAGb40Ki8gAABAMARjBEAiAKW4doyvkMXxCsDmyGDSBQE6tE djfxAFr8Ln6uOCPmugIgMQ/nYa3fMs7FN/VxfemsRVvdLuvWs1o2Svv45lLv9OcA dQBJnJtp3h187Pw23s2HZKa4W68Kh4AZ0VVS++nrKd34wwAAAZvjQqPBAAAEAwBG MEQCIFX3q8LiawYUh01MzRnrY4A1z8Eb2Z7MdAFR865jWks0AiBU0ZOaohQMCDNd P+Khq1QtKHChJWRsi7nHdHZzQxO0+zANBgkqhkiG9w0BAQsFAAOCAQEAQFmRC0qa 3t37S4uQqlE/7Rixy5XnkXur9ieW9dHEwi9EcNOx8JsYdfFl0WDsh8oLLYQ/+GJt 0im6hEZSbhfbLJB+WBBLKUrCM2LOVXoxTtuiaEIKwHbutWbiw3oEzxaBpLsylXCY XrLvZHCC6RpSa4j/XvdXjc+lKuXKobC4hT4hS9dzfAsZGnikMT39ThtX42x01Ann tmseB+jEMltpCt/y1ozM5gf29c+0eIWCXmX/EU4uDq/q4qnWbMEUC1Vvd2tDVjLs 2G1rwNIlx5vgrRZY+gbAL/Oe5FMop8i5gLo69d3U9FC9Ch01XkI01BPSro2DRd78 tvHJ05xzeSIl7Q== -----END CERTIFICATE----- subject=C = US, ST = California, L = Menlo Park, O = "Meta Platforms, Inc.", CN = *.meta.vc issuer=C = US, O = DigiCert Inc, CN = DigiCert Global G2 TLS RSA SHA256 2020 CA1 --- No client certificate CA names sent Peer signing digest: SHA256 Peer signature type: ECDSA Server Temp Key: X25519, 253 bits --- SSL handshake has read 3113 bytes and written 376 bytes Verification: OK --- New, TLSv1.3, Cipher is TLS_CHACHA20_POLY1305_SHA256 Server public key is 256 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) --- --- Post-Handshake New Session Ticket arrived: SSL-Session: Protocol : TLSv1.3 Cipher : TLS_CHACHA20_POLY1305_SHA256 Session-ID: 08511F27B983634F72F7C91727DF3D9D8BF8F5D8154282DCC5F71A6504367FD5 Session-ID-ctx: Resumption PSK: DBF6C473F797F040D6AA9936209ABD5989BF2EA85226777F90B22DF78C365E18 PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 172800 (seconds) TLS session ticket: 0000 - dc d2 5a 81 d5 e5 fe 5e-c9 ac a5 57 d4 3e d0 c8 ..Z....^...W.>.. 0010 - 21 1a 69 f2 70 df b8 32-1c 53 92 9d 08 c2 4d 42 !.i.p..2.S....MB 0020 - 00 00 00 00 b5 3c b5 d7-86 34 21 83 0a 6b 09 f5 .....<...4!..k.. 0030 - 86 24 b2 9d 0d 9e 15 85-4d d1 ad 75 ba 69 32 bc .$......M..u.i2. 0040 - 67 3d f2 66 70 f3 d8 10-0d d2 e2 99 ed a2 30 78 g=.fp.........0x 0050 - cb bf c2 89 bd 71 52 81-2c e6 2d 4e b4 47 43 dd .....qR.,.-N.GC. 0060 - 3e 2d 31 9b 55 b3 e6 aa-bf 4b 3a 83 b2 fd 62 bc >-1.U....K:...b. 0070 - da a7 99 a1 f8 26 0f a1-12 4f c8 4b 9d .....&...O.K. Start Time: 1776262610 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no Max Early Data: 0 --- read R BLOCK

Thanks — I’m responding to the TLS handshake output and the INVITE trace showing UDP -> wa.meta.vc:5061 with no response. Good signs: TLS to wa.meta.vc:5061 succeeds (TLSv1.3, valid DigiCert chain, no client CA requested). That means Meta is reachable over TLS and does not require mutual TLS. Next focused checks (please run / share results): 1) Confirm LiveKit is actually using TCP/TLS for the trunk • In your outbound trunk config, ensure the destination URI uses transport param, e.g.

sip:wa.meta.vc:5061;transport=tls

(not

sips:

). • Share the LiveKit SIP log lines that show the connection attempt when transport=TLS (connection open, TLS handshake, or TCP connect error). 2) Verify the actual packet flow from LiveKit when TLS is selected • Capture a packet trace on the LiveKit host while initiating an outbound call (tcpdump filter:

host wa.meta.vc and (tcp port 5061 or udp port 5061)

). • Confirm you see a TCP SYN and TLS handshake from the LiveKit IP. If you only see UDP, LiveKit is still sending UDP. 3) Check SNI/Host header used by LiveKit • Your openssl showed certificate for *.meta.vc — good. Ensure LiveKit sends SNI

wa.meta.vc

(or the same host you used with openssl). If you can’t confirm, paste the LiveKit TLS log or the tcpdump TLS Client Hello SNI (I can show how to extract it if needed). 4) If TLS connect is fine but Meta still doesn’t reply to INVITE over TLS • Compare the INVITE Request-URI and From/To formatting when using TLS vs UDP — some gateways require specific From/Contact formatting (E.164, no extra params). Paste both INVITE headers for comparison. • Confirm you’re sending the INVITE to port 5061 (your trace shows UDP->5061; for TLS it must be TCP->5061). 5) UDP INVITE arrives but call doesn’t progress — likely media/SDP expectation • Your SDP shows plain RTP (PCMA/PCMU). Meta/WhatsApp commonly requires secure media (DTLS-SRTP or SDES). Confirm the provider’s media requirement. • If Meta requires DTLS-SRTP, enable DTLS on the LiveKit trunk and ensure the INVITE includes `a=setup`/DTLS fingerprint lines. Share the SDP you send over UDP and what (if any) response you get. 6) Firewall/NAT & RTP reachability • Ensure LiveKit’s Contact/SDP IP (13.235.180.195) and RTP port 52918 are reachable from Meta. Run a basic UDP echo from Meta side is not possible, but confirm your NAT/firewall allows inbound RTP from 163.70.144.192/wa.meta.vc range (ask provider for their IPs if unknown). What to share next (most useful): • LiveKit SIP logs for the TLS attempt (connection/TLS handshake and subsequent INVITE if any). • tcpdump output showing whether TCP SYN/TLS ClientHello are sent to wa.meta.vc:5061. • The full INVITE headers and SDP when transport=TLS (if any), and the UDP INVITE + any SIP responses you saw. • Confirmation from Meta whether they require secure media (DTLS/SDES) or any specific SIP header formatting. Send those and I’ll pinpoint whether this is a LiveKit config (still sending UDP), SNI/host mismatch, header/URI formatting issue, or an SDP/media encryption mismatch and give exact config changes. , with interactive elements