Wideband (AMR-WB/G.722) re-encode introduces chunk-boundary artifacts on WebRTC→SIP bridge, amplified by T-Mobile VoLTE

[sitefeng]

Summary

When testing with LiveKit, I'm encountering audio jittering / loud crackling sound when testing with certain T-Mobile phones. This issue happens to me on both inbound and outbound calls, as long as I'm using wideband (AMR-WB / G.722) for the SIP trunk. I noticed that if I force the codec to G.711 (narrowband audio), the issue becomes less severe, but call audio quality is degraded to non HD audio. I think this is caused by a G.722 (HD) transcode path bug on LiveKit.

Observed behavior

On calls where a wideband codec is present in the transcode chain, the WebRTC→SIP bridge introduces audible chunk-boundary discontinuities ("sharp transitions" / high-pitch clipping). These are inaudible on VoIP-to-VoIP paths but are amplified by T-Mobile's VoLTE/EVS chain, making them clearly audible on carrier phones.

Environment

• Caller on T-Mobile reaches Telnyx over direct T-Mobile IMS peering with AMR-WB (HD Voice); Telnyx transcodes AMR-WB → G.722 toward LiveKit.
• LiveKit SIP bridge ↔ Telnyx SIP trunk.
• Reproduces on both inbound and outbound T-Mobile calls.

What isolates it to the transcription

• A direct Telnyx Call Control test on the same number is clean → the source audio and carrier are fine. (I use Telnyx as my carrier)
• The jittering issue affects localhost LiveKit agent deployment, LiveKit Cloud deployment, and Telnyx-hosted LiveKit. So it's not a Telnyx related issue.
• A direct call in a WebRTC LiveKit conference room does not have audio artifacts. Same encoding throughout, no transcoding needed.
• Same call through the Carrier (AMR-WB / Other HD codec) → LiveKit WebRTC (G.722) → SIP bridge shows the artifact.

What does / does not mitigate (our env)

The jitter-buffer negative result is the notable one: it suggests at least part of this is a re-encode seam discontinuity, not solely the mixer-starvation / silent-gap mechanism the InputBufferFrames 5→15 change in #608 addresses. The two may be additive.

Possible Solution

Boundary smoothing at the re-encode seam — e.g. short overlap-add / windowed crossfade across chunk boundaries when re-encoding Opus → G.711/G.722, so a discontinuity at a frame seam doesn't produce a step the carrier codec can splatter. This is mechanistically distinct from buffering.

[dennwc]

Hi! Could you please share the PCAP (including RTP) to demonstrate the issue? Similar issues were caused by the resampler in the past.

[sitefeng]

Please give me a few more days as I'm busy at the moment. The issue can be readily reproduced.

[mikefaille]

Adding production data from a LiveKit Cloud + Twilio Elastic SIP Trunk deployment, with a full reproduction recipe. Key point: our trunk leg cannot negotiate a wideband codec (Twilio Elastic SIP Trunking supports only PCMU/PCMA — no G.722), yet the corruption reproduces — so the root cause is codec-independent and sits before the encode step, consistent with the mixer input-buffer starvation that #727 benchmarks, rather than a wideband resample path.

Setup

• LiveKit Cloud (managed SIP bridge) ↔ Twilio Elastic SIP Trunk (outbound, agent → PSTN). Trunk supports PCMU/PCMA only; no codec knob exists on either side, so this is the default negotiation any Twilio user gets.
• Publisher: Rust SDK (livekit 0.7.50), one participant publishing 24kHz mono: NativeAudioSource::new(default_opts, 24000, 1, /*queue_ms=*/1000), 480-sample (20ms) frames via capture_frame(...) in a loop with a 20ms sleep — the SDK's 1000ms queue governs the wire cadence, so publisher-side burstiness is ruled out.
• Test signal: ~13s of continuous TTS speech (any deterministic WAV works; a speech-shaped signal makes dropouts audible and measurable).

Reproduction

1. Enable recording on the Twilio trunk (record-from-ringing).
2. Create a room; publish the reference WAV as above.
3. CreateSIPParticipant toward a real PSTN number through the trunk.
4. Download the Twilio call recording (16-bit PCM WAV).
5. Score it — the metric is ~30 lines of stdlib Python, no dependencies:
   • Mix to mono, split into 10ms RMS windows.
   • Speech span = first through last window with RMS > 150 (int16 scale), capped at 13s.
   • Dropout % = share of windows inside the speech span with RMS < 20 (i.e., injected near-silence during continuous speech).
6. Control: run the identical WAV between two WebRTC participants in the same room (no SIP hop) and score a client-side capture the same way. Using the same audio for both paths cancels natural speech pauses out of the comparison.

Results

Path	Dropout (10ms windows, RMS<20 inside speech span)
WebRTC loopback, no SIP hop (control)	~1%
Cloud SIP bridge → Twilio, controlled A/B (cross-correlation-aligned dropout detection)	~27%
Cloud SIP bridge → Twilio, live production-path call (recording-scored as above)	61.3%

Transport is clean throughout: Twilio Voice Insights reports zero packet loss, no timing drift across multiple calls. RTP is fine; the decoded audio has silence seams.

Why this matches #727

The offline benchmark in #727 drives the real mixer with bursty input at the default 5-frame (100ms) input buffer: 172/602 frames dropped (~28%) + ~3.4s injected silence per 12s; zero drops at 15 frames or with steady input. Our controlled A/B lands on the same ~27–28%, with the same clean-transport/injected-silence signature — and on a leg that can't be wideband, which also fits @ebilal's #608 observation if G.722 amplifies audibility rather than causing the loss. Likely the fastest internal repro is #727's benchmark itself.

Ask

1. Could Make the SIP audio mixer input buffer size configurable #727 (or an equivalent mixer_input_buffer_frames bump) be merged and deployed to Cloud SIP?
2. We can run before/after A/B captures on our trunk within a day of any change and share sanitized per-SSRC analysis. Call SIDs / UTC intervals available through a support channel — happy to open a ticket referencing this issue.

---

Repro scripts: https://gist.github.com/mikefaille/75f16a6edfaf9ca8c03198c3f12199b9 — the publisher (publish_and_dial.rs, livekit 0.7.50 + livekit-api 0.5.4) and the stdlib-only scorer (score_dropout.py) implementing the exact metric above, plus a README with the full procedure.