We’re seeing an issue where the initial INVITE → 200 OK from LiveKit SIP contains correct SDP with the external IP, but the next SIP message in the same dialog (re-INVITE or the 200 OK to it) is received by our SIP provider without a c= IP line in the SDP. We are using LiveKit SIP with use_external_ip: true . Has anyone encountered LiveKit SIP omitting the SDP connection address in mid-dialog messages?
What is the Call-ID? It starts with SCL_ and can be found on your dashboard under telephony→calls
Do you have a PCAP for that?
Hi, thanks for looking into this.
Yes, I have the full PCAP. Please refer to the screenshots below:
The initial INVITE completes fine — full SDP negotiation, 200 OK with media on 192.168.10.2:30061, codec PCMU/8000, all good. The issue is what happens next. The trunk provider sends an offerless re-INVITE (in-dialog, no SDP body). LiveKit responds with a 200 OK that also has no SDP (583 bytes, no media description). The provider’s ACK then comes back with Content-Length: 0 — so no media gets renegotiated and audio breaks.
Note on our setup: This is self-hosted in a private virtual cloud. The NIC is directly mapped to the trunk provider’s network (no NAT) — the provider doesn’t support public IPs and operates entirely on private addressing. So the 192.168.10.2 in the SDP is correct and routable from the provider’s side. The private IP is not the issue here.
Not very easy to look at a PCAP as a screen shot. What is the call ID you are looking at so I can take a look at the PCAP.
Looking a little at the PCAP I am not actually sure how it is working at all.
Is this self hosted server or LiveKit cloud?
This is self-hosted in a private cloud provided by the telco with private IP addresses. The SIP server connects directly to the teleco provider’s SIP gateway using a dedicated private IP link. The private IP is not the issue here. Attached the PCAP.
01_20251210141926_00001 (1).pcap (1.5 MB)
