Hi Livekit team,
I’ve been facing challenges in connecting to the user via the SIP integration. It might be just the destination I am trying to reach, as they are either unavailable or disconnecting after 1-2 minutes. However, in the Livekit dashboard, I can see that a lot of calls from June 9 onwards are still showing as active, along with some calls having a ‘media timeout error’.
Can you please help me with identifying what exactly the issue is since almost 40-50% of the calls i am doing are getting disconnected after 1-2 minutes and i am not able to understand exactly why this is happening.
My Project ID is: p_1r06yw23yv1. I am also attaching a screenshot below for your reference:
The call showing as active on the dashboard is likely a cache issue, since the end time shows it has already ended.
Do you have a call ID that ended earlier than you thought it should? Do you see anything in the PCAP that might explain why it ended?
I have these call ID from today: SCL_7zgH2HU95u99, SCL_jriarV2fmh4A.
SCL_7zgH2HU95u99 - Looks like the caller hung up. Right?
Call established at 12:45:46, and at 12:46:50 the carrier sent a SIP BYE (Closing outbound call, reason: bye, result: success).
And for SCL_jriarV2fmh4A — media timeout (~3m56s)
And this one looks like we stopped receiving audio from the remote, which triggered a media timeout. Not sure if that is due to slilence but make sure SIP provider sends RTP even for silence.
@Pranav_Kale, I would second CWilson’s findings. On the “active” calls, every row in your screenshot has an end time yet still reads ACTIVE, so that lines up with the stale-display behavior already noted, not stuck sessions.
The media-timeout drops are the systematic part worth chasing. LiveKit SIP runs a media-timeout watchdog that ends the call once inbound RTP stops arriving for the configured media_timeout:
which is exactly the SCL_jria… case: the remote’s RTP stopped and the call was torn down at ~3m 56s, no BYE. Media timeout from an RTP gap is a recurring report [ livekit/sip#337 ].
So the fix is carrier-side, as already called out: keep the trunk sending RTP continuously. Concretely, turn off silence suppression / VAD on the carrier leg so it never goes silent on the wire (comfort-noise RTP per RFC 3389 still counts as packets), and in the PCAP check whether the remote RTP simply stops at the drop versus a SIP BYE. RTP stops with no BYE points to the silence gap; a BYE is a real hangup like SCL_7zg…
Okay, thanks. I’ll check on the carrier platform whether there are options to keep sending RTP.
Hi team, I’ve been trying to figure out what the issue is over the past few days, but I am still facing random disconnects. For example, in this call - SCL_ua6iBnQVbkXM, the conversation was active, but in the middle, it stopped and the user disconnected. I am using Didlogic as the telecom carrier and have gone through the setup again, configuring everything exactly. Additionally, I can’t see any configuration in the Didlogic console regarding RTP keep-alive.
Hi, I took a look at the call, SCL_ua6iBnQVbkXM and to me everything looks healthy up until we get the BYE from Didlogic, but I can’t tell why they sent that BYE as everything up until then looks normal. I don’t think this is associated with RTP keep-alive as I see the media flowing. Did you raise this with Didlogic?
I’ve Raised the issue with them, they are looking into it.
