steep-balloon-41261
05/23/2026, 9:31 AMtall-airline-16756
05/23/2026, 9:31 AMtall-airline-16756
05/23/2026, 9:32 AMwait_until_answered causes the call to drop.
A few quick clarifying questions first (these will narrow the cause):
• Which LiveKit server version are you running?
• Which SIP server software and version are you self-hosting?
• Are you using SIP over UDP/TCP/TLS? Any custom SIP headers or forking configured on the trunk?
• Can you attach the LiveKit server logs around the call attempt (timestamps) and any SIP logs or SIP traces from your SIP server or Twilio showing the INVITE/200/ACK/CANCEL/487 flow when wait_until_answered=true?
• Do you see any SIP response codes (e.g., 487 Request Terminated, 408, 480) or a CANCEL from LiveKit when it disconnects?
• Does the issue occur with other carriers/trunks or only Twilio?
What I’ll look for once you provide logs:
• Whether LiveKit is sending a CANCEL or treating the call as unanswered due to missing/late 200 OK + ACK.
• Timing differences between ringing and answer handling (RTP/SDP/ACK timing).
• Any SIP transport or TLS handshake failures when wait_until_answered=true.
If you prefer, paste a short snippet of the SIP INVITE → 180 Ringing → 200 OK → ACK (or the sequence you observe) and the corresponding LiveKit log around that time and I’ll analyze it and recommend the next steps.
, with interactive elementslittle-king-41579
05/23/2026, 9:37 AMwait_until_answered=truetall-airline-16756
05/23/2026, 9:37 AMwait_until_answered=true.
Please provide the following so I can pinpoint the cause:
• LiveKit server version.
• SIP server software and version.
• SIP transport (UDP/TCP/TLS) and any custom SIP headers or forking on the Twilio trunk.
• LiveKit debug logs around the call attempt (timestamped).
• SIP trace or logs from your SIP server or Twilio for the same call showing INVITE → 180 Ringing → 200 OK (if present) → ACK/CANCEL/487 sequence.
If you can’t share full logs, paste the SIP message sequence (INVITE with SDP, provisional responses, final responses) and the LiveKit log lines showing the CANCEL.
What I’ll check once I have those:
• Whether LiveKit sends CANCEL due to a missing/late 200 OK + ACK or a timeout.
• If LiveKit is receiving Twilio’s provisional/final responses and their timing.
• Any transport or TLS errors that might cause LiveKit to abort the call.
If helpful, also tell me whether the behavior differs with wait_until_answered=false (you said it does) for the same call attempt so I can compare traces.
, with interactive elementslittle-king-41579
05/23/2026, 9:38 AMtall-airline-16756
05/23/2026, 9:39 AMwait_until_answered=true.
1. Check the LiveKit service status (systemd + docker container):
systemctl status docker.livekit-server@v0.13.service
1. Show recent LiveKit container logs:
# If using the service above
journalctl -u docker.livekit-server@v0.13.service -n 200 --no-pager
# Or if running as a Docker container
docker ps --filter "name=livekit"
docker logs --tail 200 <container_id_or_name>
1. Get the LiveKit server version (from the binary or container):
# If binary installed
livekit-server --version
# If container
docker exec -it <container_id_or_name> livekit-server --version
1. If using Kubernetes, check pod status and logs:
kubectl get pods -l app=livekit -n <namespace>
kubectl logs -l app=livekit -n <namespace> --tail=200
1. Gather related SIP/Twilio logs:
• Pull SIP server logs around the call timestamps and any SIP traces (INVITE/180/200/ACK/CANCEL).
• In Twilio Console, fetch the SIP trunk Call SID debug logs for the failing call.
What to paste here:
• The LiveKit logs around the call (10–20 lines before/after the CANCEL).
• The SIP trace showing INVITE → 180 Ringing → 200 OK → ACK/CANCEL (or what you observe).
• LiveKit version and transport (UDP/TCP/TLS).
Once you paste those outputs I’ll analyze the timing and messages and recommend the next steps.
Sources: Running LiveKit on AWS | LiveKit, with interactive elementslittle-king-41579
05/23/2026, 9:43 AMtall-airline-16756
05/23/2026, 9:43 AMdocker exec -it <container_name_or_id> <sip_binary> --version
Common SIP binaries:
• asterisk (Asterisk): docker exec -it <container> asterisk -V or asterisk --version
• kamailio (Kamailio): docker exec -it <container> kamailio -v
• opensips (OpenSIPS): docker exec -it <container> opensips -V
• freeswitch (FreeSWITCH): docker exec -it <container> freeswitch --version
2. If you’re not sure which binary is present, open a shell and check:
```bash
docker exec -it <container_name_or_id> /bin/sh
# or
docker exec -it <container_name_or_id> /bin/bash
# then inside the container:
ps aux | grep -E 'asterisk|kamailio|opensips|freeswitch'
which asterisk || which kamailio || which opensips || which freeswitch
1. If the image tags include the version, list the image:
docker inspect --format='{{.Config.Image}}' <container_name_or_id>
docker images --filter=reference='<image_name>*'
Paste the exact container name and output if you want help interpreting the version string.
, with interactive elementstall-airline-16756
05/23/2026, 9:52 AMwait_until_answered=true.
First, quick checks and commands to gather the logs I need:
1. Enable verbose LiveKit SIP logs and capture around the call (replace timestamps):
# increase logging level (if running as container)
docker exec -it <livekit_container> livekit-server --log-level debug
# collect recent logs
docker logs --tail 500 <livekit_container> > livekit_logs.txt
1. Grab the exact LiveKit SIP component logs (where CANCEL appears):
journalctl -u docker.livekit-server@v0.13.service --no-pager -n 500 > livekit_journal.txt
# or container logs
docker logs --tail 500 <livekit_container> > livekit_sip_logs.txt
1. Collect the SIP trace from your SIP server (example for containerized Asterisk/Kamailio/OpenSIPS):
# enter container
docker exec -it <sip_container> /bin/bash
# Asterisk real-time trace
asterisk -rvv
# then in asterisk CLI:
sip set debug on # (chan_sip) or
pjsip set logger on # (pjsip)
# Kamailio/OpenSIPS: enable pcap or siptrace module logs and export the trace around the call timestamp
1. Pull Twilio SIP trunk debug/call SID logs from the Twilio Console for the failing call and export the SIP trace.
What I’ll look for once you provide logs:
• Whether LiveKit issues a CANCEL because it didn’t receive a final 200 OK + ACK within its answer timeout.
• If Twilio or your SIP server sends 200 OK but ACK is missing/late, or if a provisional response lacks SDP/required headers.
• Any transport/TLS errors or SIP response codes (487, 408, 480) before the CANCEL.
• Timing between INVITE → 180 → 200 → ACK and the CANCEL timestamp.
One diagnostic you can try now:
• Temporarily increase any answer timeout LiveKit uses for SIP (if configurable) or test with wait_until_answered=false to confirm the only difference is the answer-wait path.
Please paste:
• The 20–50 lines of LiveKit logs showing the INVITE → CANCEL sequence.
• The SIP trace (INVITE, 180, 200, ACK/CANCEL) for the same call.
• Confirmation of SIP transport (UDP/TCP/TLS) and whether Twilio trunk uses forking or custom headers.
With those I’ll analyze the sequence and recommend the exact fix.
, with interactive elements