Intermittently not receiving 200 OK SDP from Livekit

Telephony
,
1

Hi team,

We’re seeing an intermittent issue where 200 OK responses for SIP INVITEs sent to our trunk (20bb9gxx1qz.in.sip.livekit.cloud:5060) are not reaching our public IP (13.205.190.16:5060).

We’ve isolated two calls that reproduce the issue:

• SCL_Zgnz65HQ9EoR (SIP Call-ID: a93d4b6aa724481f0b1ebc03aeaffa08)
→ 200 OK was sent from 143.223.91.141:5060 — we did NOT receive it :cross_mark:

• SCL_oJFy5m8UMb7a (SIP Call-ID: db86dc172330f50d76357e3772a2ad56)
→ 200 OK was sent from 143.223.91.157:5060 — we received it fine :white_check_mark:

Scale of the issue: roughly 10 out of every 250 calls fail this way, so it’s intermittent but consistent enough to be impactful.

We’ve ruled out UDP packet drops on our end — no drops observed in our captures.

Could you help us with:
Can you confirm whether 143.223.91.141 successfully dispatched the 200 OK for SCL_Zgnz65HQ9EoR toward 13.205.190.16:5060? If possible please share the trace / log.

We have pcap files for both calls (SCL_Zgnz65HQ9EoR_3c5728481126b957b51da37a5d707457.pcap and SCL_oJFy5m8UMb7a_db86dc172330f50d76357e3772a2ad56.pcap) and can share them if helpful.

Thanks

Link to our pcap (7MB): https://drive.google.com/file/d/1PhoIwM_vBAq4o_X2IIgh--wnGjrn-BQE/view?usp=sharing (there is 5MB file limit on this UI)

SCL_Zgnz65HQ9EoR_3c5728481126b957b51da37a5d707457.pcap (94.9 KB)

SCL_oJFy5m8UMb7a_db86dc172330f50d76357e3772a2ad56.pcap (270.5 KB)

2

This is a reply from @CWilson

Hi Jaivarsan, welcome to the community!

Thanks for the thorough investigation — the call IDs, PCAPs, and failure rate details are really helpful.

Based on what you’ve described, this is most likely a source IP mismatch on the SIP 200 OK response. Here’s what’s happening:

LiveKit Cloud does not use static IP addresses for SIP signaling. Your INVITEs are sent to 20bb9gxx1qz.in.sip.livekit.cloud:5060, which resolves to one of several IPs, but the 200 OK response may come back from a different IP than the one your INVITE was sent to. In your two examples:

  • SCL_oJFy5m8UMb7a — 200 OK from 143.223.91.157 → received successfully

  • SCL_Zgnz65HQ9EoR — 200 OK from 143.223.91.141 → not received

The ~4% failure rate (10/250) is consistent with this — it depends on which SIP node handles the response.

The reason you’re not seeing UDP drops in your captures is likely because the packets are being dropped before they reach your SIP stack — typically at the firewall, security group, or NAT layer. Since your IP (13.205.190.16) is in AWS, we’d recommend checking:

  1. AWS Security Groups — Ensure inbound UDP on port 5060 is open to 0.0.0.0/0 (or at minimum, not restricted to a single LiveKit IP). If your security group only allows return traffic from the IP you sent the INVITE to, responses from other LiveKit IPs will be silently dropped.

  2. NACLs — If you have custom Network ACLs on the subnet, verify they also allow inbound UDP 5060 from any source.

  3. Any upstream firewall or SBC — If there’s a session border controller or firewall in front of your SIP endpoint, check that it isn’t doing source-IP validation against the original INVITE destination.

Our recommendation: switch to SIP over TCP or TLS. With TCP/TLS, responses flow over the established connection, eliminating the source-IP mismatch issue. You can configure this on your inbound trunk. This is also our general recommendation for reliability over UDP.

We’ll also look into the server-side logs for SCL_Zgnz65HQ9EoR (Call-ID: a93d4b6aa724481f0b1ebc03aeaffa08) to confirm the 200 OK was dispatched from our end.

Let us know if you have any questions or need help configuring TCP/TLS transport.