Livekit - Whatsapp media relay issue

Telephony
1

## :bug: Issue: Intermittent Audio Failure – LiveKit Using TURN Instead of Direct RTP (SIP ↔ WebRTC)

### Description

We are experiencing intermittent one-way / no-audio issues when connecting SIP calls (via rtpengine + Kamailio) to LiveKit rooms.

In some calls, audio flows correctly. However, in many cases:

  • No RTP is received from the LiveKit side
  • Calls are terminated after ~20 seconds (likely due to upstream SIP timeout, in this case - WhatsApp)

This behavior started suddenly without any infrastructure changes on our side.

—

### Setup Overview

WhatsApp SIP → Kamailio → rtpengine → LiveKit (Cloud) → Browser
  • SIP side codec: PCMU (8kHz)
  • WebRTC side codec: Opus (48kHz)
  • rtpengine handles transcoding (PCMU ↔ Opus)

LiveKit is cloud-hosted (not self-hosted).

—

### Observed Behavior

From rtpengine-ctl call info:

#### :cross_mark: Failing calls

Media (WebRTC side):
172.17.0.4:24998 <> 57.144.41.49:3484
0 packets, 0 bytes, 93 errors
  • No RTP received from LiveKit side
  • Errors continuously increment
  • Call drops after ~20s

—

#### :warning: Partially working calls

Media (WebRTC side):
172.17.0.4:25028 <> 57.144.49.49:3484
494 packets, 34 errors
  • Some RTP received
  • Audio is intermittent

—

#### :white_check_mark: Working calls

Media (WebRTC side):
172.17.0.4:23068 <> 57.144.49.49:3484
227 packets, 0 errors
  • Audio works normally

—

### Key Observation

In all cases, LiveKit is sending media from:

57.144.x.x:3484

This strongly suggests that:

  • LiveKit is using a TURN relay
  • Instead of a direct ICE host/srflx candidate

—

### Expected Behavior

We expect LiveKit to:

  • Prefer direct UDP (host/srflx ICE candidates) when reachable
  • Avoid TURN unless strictly necessary
  • Even if that’s not possible, how to reliably use TURN to relay media

—

### Actual Behavior

LiveKit appears to:

  • Prefer or fall back to TURN frequently
  • Resulting in:
    • No RTP flow in some cases
    • Intermittent audio in others

—

### Impact

  • Calls drop after ~20 seconds due to no media
  • Unreliable audio experience
  • Production impact on SIP-based calling (WhatsApp integration)

—

### Questions

  1. Under what conditions does LiveKit Cloud prefer TURN over direct candidates?
  2. Is there a way to force or prioritize host/srflx candidates?
  3. Could there be regional TURN routing issues causing intermittent RTP failures?
  4. Are there any logs or metrics available from LiveKit Cloud to debug ICE candidate selection?

—

### Additional Notes

  • No changes were made to:
    • Kamailio
    • rtpengine
    • Network/firewall
    • SIP side RTP (WhatsApp ↔ rtpengine) is always stable
    • Issue only occurs on WebRTC (LiveKit) side
    • Other SIP calls on same infrastructure are working normally

—

### What We Need

  • Guidance on ensuring direct RTP path (no TURN)
  • Debugging steps for ICE candidate selection in LiveKit Cloud
  • Any known issues with TURN reliability on LiveKit Cloud

—

### Optional Debug Info (can provide if needed)

  • Full SDP offer/answer
  • ICE candidate pairs
  • Packet captures (tcpdump)
  • rtpengine logs
2

Update

Been testing since morning by updating almost nothing. Basically a few logs here and there.
Media is now relaying but is jittery and has improved over the last couple hours.
But the audio is not smooth.
Audio from Livekit to WA is smooth and realtime.
Audio from WA to Livekit is a bit jittery and sometimes not realtime
Also the audio starts streaming after 4-5 seconds of call being answered

3

Hi, sorry I know this sounds confusing, but can you please post issues related to the WhatsApp connectors beta to the private community support channel beta-connectors.

The WhatsApp connector beta predated our move to this new forum so we decided to keep discussions about the connectors on Slack.

Also, not everyone who needs to see this message is monitoring this category / tag.

1 Like