I investigated the reported call UUIDs, and found ...
# ask-ai
b
I investigated the reported call UUIDs, and found that the reason the calls are dropping off at 900 seconds is because the customer's endpoint does not support SIP Update. The customer is using an external SIP endpoint, and it is not advertising support for the UPDATE method in its Allow header. When a call is established, our platform negotiates a session timer of 1800 seconds as a keep-alive mechanism. At the halfway point (900 seconds), our platform sends a SIP UPDATE request to refresh the session however, the endpoint is rejecting this with a 405 Method Not Allowed response, which causes the call to drop. The customer needs to check if the SIP endpoint they are using supports SIP UPDATE, and if it does, it needs to be advertised on their SIP INVITE.
✅ 1
t
Thanks for reaching out, G. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
Thanks — I reviewed your findings about calls dropping at 900s because the external endpoint does not support SIP UPDATE. I can help with concrete next steps and configuration examples, but I need one quick clarification so I give the right guidance: Which SIP integration are you using with LiveKit? • LiveKit’s built-in SIP gateway (livekit-server / livekit-sfu), or • A different SIP trunk/provider integration? Also confirm whether you control the external SIP endpoint and can change its configuration (or if it’s managed by a third party). Once you reply I will provide: • Exact troubleshooting steps and example SIP headers/INVITE snippets to verify UPDATE support, • Two remediation paths with step-by-step actions: have the endpoint advertise/support UPDATE, or change LiveKit behavior (options: disable session timers, lower timer, or use re-INVITE), • Example SIP messages and recommended settings for each option., with interactive elements
b
LiveKit’s built-in SIP gateway
t
Thanks — I reviewed your findings about calls dropping at 900s because the external endpoint does not support SIP UPDATE. I’ll help you with next steps. What I’m responding to: the call drops occur because LiveKit’s SIP gateway negotiates a 1800s session timer and sends a SIP UPDATE at 900s; the remote endpoint returns 405 and the session is terminated. Please try the following options (pick what you can control): • Verify and enable UPDATE on the external endpoint ◦ Check the endpoint’s Allow header in the initial INVITE/200 OK. It must include UPDATE. ◦ If you control the endpoint, enable RFC 3311 (UPDATE) support in its SIP stack or trunk settings and ensure UPDATE is advertised in the INVITE. ◦ After enabling, place a test call and confirm LiveKit’s UPDATE is accepted (no 405). • Have the endpoint perform session refreshes (re-INVITE) ◦ If the endpoint can’t accept UPDATE but can send re-INVITE, configure it to refresh the session before 900s so LiveKit won’t need to send UPDATE. • Change LiveKit behavior (if endpoint cannot be changed) ◦ Use a provider or endpoint that advertises UPDATE (recommended). ◦ Consider LiveKit Phone Numbers to avoid the third-party SIP trunk incompatibility. (See: https://livekit.com/blog/introducing-livekit-phone-numbers-zero-to-ringing-in-60-seconds/) What I can help with next: • If you want, share a SIP trace (INVITE/Allow header and the UPDATE + 405) and I’ll point out exactly what to change. • Tell me whether you control the external endpoint or if it’s a third-party provider, and which provider it is. Sources: Agents telephony integration | LiveKit Documentation | Introducing LiveKit Phone Numbers: zero to ringing in 60 seconds | LiveKit, with interactive elements