call_b4d92a48936d37a5427938c8b06 — last turn 5186ms e2e
Not jitter. Component timings on that turn are clean: LLM TTFT 550ms, LLM total 673ms, TTS first-byte 231ms, ASR 168ms → sum ≈ ~1.0s. The remaining ~4s is endpointing/VAD silence wait, not model/TTS/network. The caller trailed off with “Which is” at 45.7s and the agent didn’t commit the turn until 51.0s because VAD was waiting for the sentence to finish. Dashboard “Estimated Latency” doesn’t include this wait, which is why LLM/TTS look fine but e2e is long.
Your agent (v254) has interruptionSensitivity: 0.7 and no explicit responsiveness set — raising responsiveness will shorten that silence gate. That’s the fix for this specific call, not TTS/LLM.
call_a3b085e6ca755dfb5c1671099ef — audio glitching
This one IS a media-path issue — the caller himself says at ~63s “the audio packets are being lost… around 20–30 seconds it started to get really glitchy, I can only hear every third word.” That’s a downstream audio degradation, not endpointing. Voice provider was platform (retell-Marissa) on Telnyx. to move on this we need the PCAP + Telnyx-side leg metrics for that call.
The e2e argument makes sense and it’s what I figured.
Following up on the audio quality issue: firstly I was the caller saying the audio packets are being lost but we’ve eliminated most of the path and want to hand over what we’ve found, because the remaining suspects sit inside your media pipeline.
SYMPTOM (revised from our earlier description)
This is not word loss. It’s periodic popping/clicking. It begins after at least 10 seconds, is fully established somewhere in the 10 to 20 second range, and worsens progressively for the rest of the call. Present on every TTS provider we’ve tried. Started approximately early July 2026.
Notably the onset time varies rather than landing at a fixed mark, which suggests it’s driven by cumulative audio produced rather than elapsed time.
WHAT WE’VE RULED OUT
Packet loss. RTCP from our carrier across full calls: fraction_lost 0 and packets_lost 0 on every report, start to finish.
Network jitter. Latest call: mean interarrival jitter 0.5ms, peak 2.3ms, with several reports at zero.
Pacing. Both directions pacing at exactly 50.0 packets/sec across every report interval. No bursting, no gaps, no starvation.
Carrier-side jitter buffer. Popping present both with and without it enabled.
TTS vendors. Provider-independent, so it’s downstream of the point where all TTS output converges.
Everything upstream of your recording tap. The pops are entirely absent from your own call recordings but clearly audible on the handset.
PARTIALLY TESTED
We enabled G722 on the carrier side and the popping persisted. We have not yet confirmed from the SIP trace whether the answer actually negotiated G722 rather than falling back to PCMU, so we’re not treating resampling as fully eliminated. We’ll confirm and update.
WHAT THAT LEAVES
The audio is clean in your recording and damaged at the handset, while the packets carrying it arrive perfectly and on time. The only stage satisfying all three facts is your resample, encode and packetisation path, which sits after the recording tap and before the wire.
Our working theory: a sample rate mismatch between audio generation and the RTP transmit clock. A buffer accumulates surplus audio, saturates after 10 to 20 seconds depending on how much the agent has spoken, and from then on every dropped or overwritten frame is a waveform discontinuity. This would be invisible in RTCP (packet rate stays correct at 50/sec while the audio content is over-supplied), absent from recordings (tapped pre-packetiser), provider-independent (shared stage), and unaffected by carrier-side buffering. It also explains the variable onset and the progressive worsening.
QUESTIONS
What changed in the LiveKit SIP media pipeline in early July? A version bump, resampler change or packetiser change would fit the onset date.
Can you verify RTP timestamp continuity, marker bit handling and SSRC stability on our outbound streams?
Is there a buffer between the recording tap and the RTP packetiser that could over- or underflow? What’s its depth, and what is the behaviour when it saturates?
Why is LiveKit not emitting RTCP receiver reports? Our carrier sends sender reports continuously throughout every call and receives nothing back, which means you have no RTCP measurement of your own media quality.
Separately: your Contact header is sent as a bare IP with no user part (e.g. sip:161.115.178.210:9000;transport=tcp). Telnyx requires the SIP username in the Contact header of the first INVITE to identify the connection and honour AnchorSite selection on credential-authenticated trunks. As a result our media anchors outside the APAC pool on every call. Can you include the trunk username in Contact?
SIP traces and RTCP data available on request. This has been affecting live customer calls for a month, so please let us know who owns this and what the timeline looks like.