I’m using a self-hosted LiveKit server and a self-hosted SIP server with a Twilio SIP trunk configured as an outbound trunk. When I create a SIP participant with

wait_until_answered = false

, the call is initiated successfully and the phone continues ringing normally. However, when I set

wait_until_answered = true

, the call disconnects immediately after the first ring and retries 3 times with the same behavior each time. So the issue only occurs when

wait_until_answered

is enabled

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

sip | 2026-05-23T100213.935Z DEBUG Unhandled sip response. UnhandledResponseHandler handler not added{"nodeID": "NE_wxYhEdULWABe", "caller": "transaction.Layer", "msg": "response status=200 reason=canceling transport=UDP source=54.172.60.0:5060"} 2026-05-23T100213.935Z INFO sip service/service.go:265 SIP call ended {"nodeID": "NE_wxYhEdULWABe", "callID": "SCL_3AghAPX7PCyH", "reason": "invite-failed"} 2026-05-23T100213.936Z DEBUG Unhandled sip response. UnhandledResponseHandler handler not added{"nodeID": "NE_wxYhEdULWABe", "caller": "transaction.Layer", "msg": "response status=487 reason=Request Terminated transport=UDP source=54.172.60.0:5060"} 2026-05-23T100214.427Z DEBUG Unhandled sip response. UnhandledResponseHandler handler not added{"nodeID": "NE_wxYhEdULWABe", "caller": "transaction.Layer", "msg": "response status=487 reason=Request Terminated transport=UDP source=54.172.60.0:5060"} 2026-05-23T100215.427Z DEBUG Unhandled sip response. UnhandledResponseHandler handler not added{"nodeID": "NE_wxYhEdULWABe", "caller": "transaction.Layer", "msg": "response status=487 reason=Request Terminated transport=UDP source=54.172.60.0:5060"} 2026-05-23T100217.428Z DEBUG Unhandled sip response. UnhandledResponseHandler handler not added{"nodeID": "NE_wxYhEdULWABe", "caller": "transaction.Layer", "msg": "response status=487 reason=Request Terminated transport=UDP source=54.172.60.0:5060"} 2026-05-23T100250.275Z DEBUG Server transaction terminating {"nodeID": "NE_wxYhEdULWABe", "caller": "transaction.Layer"} 2026-05-23T100250.275Z DEBUG Server transaction destroyed {"nodeID": "NE_wxYhEdULWABe", "caller": "transaction.Layer", "tx": "z9hG4bK-scaninfragrab__scan.invalid__5060__OPTIONS"}

Thanks — I’m responding about the logs you shared where calls end immediately with

invite-failed

when

wait_until_answered = true

. The logs show Twilio sending a

200 Canceling

and multiple

487 Request Terminated

responses, and LiveKit logs an unhandled SIP response handler then ends the call with reason

invite-failed

. That matches the earlier symptom: LiveKit is not receiving (or not handling) the expected provisional/final response flow and is treating the call as failed. Please confirm/provide the following so I can pinpoint the fix: 1. SIP server type/version (e.g., Asterisk 18, FreeSWITCH X, Kamailio Y) and whether there’s an SBC/proxy between Twilio and your SIP server. 2. LiveKit server version. 3. A short SIP trace (INVITE + downstream responses) showing the full response sequence from Twilio to your SIP server and from your SIP server to LiveKit for one failed attempt. Include timestamps. 4. Whether your SIP server forwards provisional responses like

180 Ringing

/

183 Session Progress

to LiveKit, or whether it converts/consumes them. 5. Any SIP-related config you’re using in LiveKit (participant creation fields) and in your SIP server for this trunk (early media, timer settings, forking, cancel handling). Immediate checks you can run now: • Verify Twilio is returning 1xx (180/183) and 2xx answers toward your SIP server in the call attempt. If Twilio returns Cancel/487 toward your SIP server (as logs hint), find why Twilio cancelled (Twilio debug logs will show this). • Confirm your SIP server does not swallow or transform provisional responses into 487/200 cancel events before forwarding to LiveKit. If it does, enable forwarding of provisional responses or adjust early-media handling. • Inspect any SBC/proxy for automatic CANCEL or request-termination timers (could be closing the server transaction). • On the LiveKit side, the unhandled-response messages indicate LiveKit didn’t have a transaction handler for those responses. Ensure your SIP server preserves Call-ID/branch/tags so LiveKit’s transaction layer can match responses to the original INVITE. If you share the SIP trace and the items above, I’ll analyze the exact response sequence and tell you the specific config change (Twilio, SIP server, or LiveKit) to stop the immediate disconnects when

wait_until_answered = true

. , with interactive elements