Upon checking the logs, we can see that the INVITE...
# ask-ai
m
Upon checking the logs, we can see that the INVITE request is being sent to the destination URI (livekit SIP URI). However, we are not receiving any response from the destination server. As a result, the call is being terminated after 5 seconds with a 408 Request Timeout.
✅ 1
t
Thanks for reaching out, Mridul. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
Thanks — I see you're reporting that LiveKit sends the INVITE to the destination SIP URI but gets no response, and the call ends with a 408 Request Timeout after 5 seconds. I can help troubleshoot this. Below are the most likely causes and targeted checks you can run to narrow down the problem. What to check (quick diagnostics) • Verify destination reachability ◦ Confirm the destination SIP host resolves to an IP (nslookup/dig). ◦ From the LiveKit side (or any host on the same network), attempt a TCP connect to the SIP port: ▪︎ Port 5060 for plain SIP (UDP/TCP) ▪︎ Port 5061 for SIP over TLS (recommended) • Confirm transport and URI format ◦ Ensure the SIP URI and transport are correct (
sip:
vs
sips:
and
transport=tls
where appropriate). Using TLS on port 5061 is recommended. • Check firewall / network policies ◦ Ensure no rules are blocking SIP traffic (UDP/TCP 5060 or TCP 5061). Firewalls often drop packets silently causing no SIP response. • Certificate and TLS handshake (if using TLS) ◦ Run an
openssl s_client -connect host:5061 -servername hostname
from a host in the same network to confirm a successful TLS handshake and valid certificate (hostname matches, not expired). ◦ Certificate mismatches or invalid certificates can cause a silent failure. • Look for a provisional response ◦ LiveKit expects at least a provisional response (100 Trying) before the 5s timeout. If the destination replies slowly or not at all, the call will time out. • Packet capture ◦ Capture traffic with tcpdump/wireshark to confirm whether the INVITE left LiveKit and whether any packets return. This will show whether the destination is receiving the INVITE and if any response is sent. • Multi-IP / load-balanced destination ◦ If the destination hostname resolves to multiple IPs, ensure each endpoint has a valid cert and accepts SIP on the expected transport/port. Targeted next steps I can walk through with you 1. Share the SIP URI (mask private parts, e.g., user@host) and whether you’re using
sip:
or
sips:
and which transport/port you configured. 2. Confirm whether LiveKit is expected to use TLS or plain SIP for this trunk. 3. If you can run checks, tell me results for: ◦ DNS resolution for the destination hostname ◦
telnet host 5061
or
openssl s_client -connect host:5061 -servername host
◦ A short tcpdump capture around the INVITE attempt (I can tell you what to look for) 1. Let me know if the destination has recently changed certificates, IPs, or firewall rules. If you prefer, start by sharing the transport and port settings you configured and a sanitized example of the SIP URI; I’ll suggest the exact commands and the specific fields to inspect in your packet capture. Sources: How to detect and handle silence during calls | Understanding TLS in SIP | LiveKit | Firewall Tips for LiveKit Connectivity | LiveKit, with interactive elements