SIP gateway sends 180 Ringing ~12s after agent joins room and publishes audio

Telephony
1

Hi everyone,

We’re experiencing inbound SIP call failures due to a delay between our agent being ready in a Livekit room and the SIP gateway sending 180 Ringing to the caller.

Our upstream SIP provider has a ~20s INVITE timeout. From our pcap and agent logs on a failed call (Feb 18, 16:02 UTC), the timeline is:

  • T+0.0s — INVITE arrives at Livekit, 100 Processing sent immediately ✓
  • T+1.7s — Agent connects to room, participant joins
  • T+6.7s — Agent publishes placeholder audio track
  • T+7.7s — session.start() completes, agent begins speaking intro
  • T+20.0s — Provider CANCEL (timeout, caller drops)
  • T+20.1s — Livekit sends 180 Ringing (too late)

The agent was fully active and speaking in the room by ~T+8s, but 180 Ringing wasn’t sent until ~T+20s — a 12-second unexplained gap.

Additionally, after our Provider sends CANCEL, the agent room is not torn down. The agent continues running and participant_disconnected does not fire.

Our SIP trunk uses dispatchRuleIndividual with a roomPrefix. No ringing_timeout or early media options are configured.

Questions:

  1. Can Livekit send 180 Ringing immediately upon INVITE receipt or dispatch rule match, before the agent connects? This would prevent upstream timeouts regardless of agent init time.
  2. Is there a ringing_timeout or early_media configuration option for inbound SIP trunks?
  3. Is the SIP CANCEL being propagated as a participant disconnect event? We’re not seeing it on our end.

Call details:

  • Call ID: 09357eb7-4d7d-4daf-9bc8-a1ca24c0ac7b
  • Time: Feb 18, 2026 ~16:02 UTC

Happy to share pcap and agent logs if helpful.

Thanks

2

Are you sure you don’t have another agent running somewhere that maybe intercepting this call?

3

100% sure. We only have one agent. We use completely different projects for dev work as well.