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.
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
What isolates it to the transcription
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
InputBufferFrames5→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.