[ISSUE] SIP bridge sends BYE during LLM+TTS processing gap (~14s silence), Twilio Elastic SIP Trunk reports "caller hung up"

Telephony
, , , , ,
1

Hi everyone, I’m running into an issue with outbound SIP calls dropping mid-conversation and would appreciate any insight from the community.**

Setup:**

  • LiveKit Agents SDK v1.2.15, worker region: US West B

  • Outbound SIP via Twilio Elastic SIP Trunk (Umatilla/us2)

  • Pipeline: Google STT (streaming) → GPT-4o (max_completion_tokens=150, temp=0.3) → ElevenLabs TTS (eleven_turbo_v2_5, streaming_latency=2)

What happens:
After the user speaks and the STT transcript is received, the agent starts processing (LLM inference + TTS generation). During this processing window (~14 seconds in this case), no RTP packets are sent to Twilio. Twilio detects RTP inactivity and the call drops.

Twilio Voice Insights confirms “Who Hung Up: caller” — meaning LiveKit’s SIP bridge is sending the BYE, not Twilio.

Already ruled out / tried:

Relevant logs:
13:51:14 - received user transcript {“user_transcript”: “Hola Qué tal con John Down”, “language”: “es-US”}
13:51:28 - stream closed {“participant”: “carrier”, “source”: “SOURCE_MICROPHONE”}
13:51:28 - [LIFECYCLE] SIP participant disconnected: carrier
13:51:38 - livekit.plugins.google - stream timed out, restarting.

14-second gap between transcript received and disconnection = exact LLM+TTS processing time.

Question: Does the LiveKit SIP bridge send RTP silence/comfort noise packets during agent processing to keep the Twilio media session alive? If not, is there a configuration to enable this? This appears to be the root cause of intermittent call drops in production.

Thanks in advance for any help or pointers this is blocking us in production.

2

Do you have a call ID where this happened from here Sign in | LiveKit Cloud

3

Sure! this is the call id: SCL_DUgxmTogVQyF

4

I looked at your call and it looks like RTP is not getting transmitted from Twilio during silence. When that happens for more than 15s you will get a media timeout and the call will end. That is why LiveKit sent the BYE

Check your configuration on your Twilio account.

5

Can the SIP bridge media inactivity timeout be increased above 17 seconds? Our carrier (Twilio Elastic SIP Trunk) does not send RTP during silence periods due to VAD suppression, which triggers a media timeout and disconnects the call

6

I don’t believe so, but I will double-check.

7

@CWilson’s diagnosis lines up with Twilio’s behavior. The cleaner production fix is to eliminate the silent window, not extend the timeout. Fire session.say("one moment...") on user-transcript-final, before the slow LLM/TTS turn; that pushes real RTP for ~2s while the actual response generates. Pair with preemptive_generation=True on AgentSession so the LLM starts while turn detection finalizes. Worst-case silence drops below 5s.

14s for GPT-4o + ElevenLabs Turbo on streaming_latency=2 is itself slow. Check Agent Insights for which phase owns it (LLM TTFT vs TTS first-byte) before treating it as unavoidable.

Cc: @Jorge_Octavio_Nicolas_Diaz

8

There is a PR on the way to help in this case. You can track it here:

9

I would have to check again but I think this is the user silence and not an agent silence issue.

10

Thanks CWilson and Muhammad! I will implement the session.say(“one moment…”) on transcript-final and enable preemptive_generation=True. Also tracking the PR for the configurable timeout. Really appreciate the help!