When using livekit over SIP trunks it seems like o...
# ask-ai
w
When using livekit over SIP trunks it seems like our users speaks in a low volume. We also hear it in the tracks. However when we call the users directly we hear them crystal clear. The observability recording also shows that the volume is quite low fir the users, Which makes the AI agent unable to understand our custommers
t
Thanks for reaching out, Marius. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
Thanks — I hear you: audio from SIP-trunked callers is low in LiveKit (confirmed in observability), but direct calls sound fine, and this breaks AI transcription. I can help diagnose and fix this. A few quick checks that commonly find the cause — can you answer these? 1. Which SIP provider are you using (Telnyx, Twilio, etc.)? 2. Is
krisp_enabled
set to
true
on the inbound trunk? 3. What codec is being negotiated for the SIP calls (e.g., G.722, PCMU/PCMA)? 4. Do SIP logs show codec negotiation and packet loss metrics (any packet loss or reorders)? 5. Does the low volume happen for all callers/devices or only some locations/devices? What I’ll do after you reply: • If
krisp_enabled
is true, I’ll ask you to disable it temporarily to see if noise cancellation is reducing level. • If the trunk is using narrowband codecs, I’ll guide you to enable HD Voice (G.722) on the trunk/number. • If codec and noise cancellation look fine, we’ll check SIP-level metrics (packet loss, RTP levels) and consider server-side gain/processing or a client-side audio-gain node for transcription. If you prefer, share a short observability recording ID or a SIP call example (timestamps and SIP logs) and I’ll look for codec negotiation and level changes in the call. Sources: sip | livekit/livekit_composite | DeepWiki | Enhanced noise cancellation | LiveKit docs | HD voice for SIP | LiveKit docs | Subscribing to tracks | LiveKit docs | Agent speech and audio | LiveKit docs
w
1. currently we are using our own provider: Puzzel 2. Krisp is set enabled (True) 3. not sure where can i check it 4. where can I view my SIP logs? 5. it is for most of the custommers
t
Thanks — I’ll help you troubleshoot based on your answers. 1) Krisp is enabled • Temporarily disable
krisp_enabled
on the inbound trunk and test a few calls. Krisp can reduce perceived loudness in some cases; disabling it will tell us if it’s affecting level. 2) Check codec negotiation (what to look for) • Ask Puzzel whether calls to your LiveKit trunk are offered/negotiated as G.711 (PCMU/PCMA) or G.722. G.711/G.722 preserve volume and dynamic range; compressed narrowband codecs (e.g., G.729) often produce low/quiet audio for STT. • If Puzzel can provide the SDP or SIP INVITE/200 OK, check the audio codecs listed in the SDP offer/answer. 3) Where to find logs and recordings • LiveKit Cloud: Telephony → Call Logs — open the call entry to view signaling events, trunk ID, SIP call ID, and any SIP-level warnings. • Agent Sessions (if using agents): Sessions → select session → play the saved user audio recording. Listening to the recording confirms whether the low level is present in the audio LiveKit received. 4) SIP-level diagnostics to collect (please gather these if you can) • A short sample recording from Sessions that demonstrates the low volume. • A SIP trace/SDP for a representative call (INVITE and 200 OK) from Puzzel showing the negotiated codecs. • Any RTP packet loss/metrics from Puzzel or your SBC for that call. 5) Immediate recommended steps • Disable Krisp temporarily and retest. • Ask Puzzel to confirm/enable G.711 or G.722 for calls to your LiveKit trunk and to ensure they are not applying attenuation/gain compression. • Play the saved recording in Sessions to verify whether LiveKit’s ingest already contains the low volume (if yes, issue is upstream; if no, issue may be after ingestion). 6) If volume remains low after codec + Krisp checks • We can discuss adding a server-side gain stage in your agent audio pipeline (e.g., an audio gain node before STT) to normalize levels for transcription. I can provide a simple example if you want to try that. Which would you like to do next — disable Krisp and retest, or gather a sample session recording plus the SIP SDP from Puzzel? Sources: SIP inbound trunk | LiveKit docs | SIP overview | LiveKit docs | sip | livekit/livekit_composite | DeepWiki | HD voice for SIP | LiveKit docs | Create and configure a Plivo SIP trunk | LiveKit docs
w
Audio codec is:
audioCodec: "PCMU/8000"
t
Thanks — seeing
PCMU/8000
confirms calls are narrowband 8 kHz (G.711 µ-law) which preserves level better than compressed codecs but can still sound quiet for STT. Next steps to isolate and fix: 1. Disable Krisp temporarily on the inbound trunk and retest a few calls. Report whether recorded user audio level in Sessions changes. 2. Capture an example: ◦ From LiveKit Sessions, export or share a short recorded user audio clip that demonstrates the low level. ◦ Ask Puzzel for the SIP INVITE/200 OK SDP for that same call (or paste the codec lines). This confirms codec negotiation and any offered alternatives (e.g., G.722). 1. Have Puzzel check for any per-call gain/attenuation or transcoding on their side (SBC or media proxy). Ask them: ◦ “Is any gain compression or attenuation applied to outbound RTP to our trunk?” ◦ “Are you transcoding or altering RTP payloads when sending to our trunk?” 1. If recordings show low level after LiveKit ingest (you hear quiet in Sessions), we can add a gain stage before STT: ◦ I can provide a small audio-gain node example for your agent pipeline to boost input level prior to transcription. ◦ If you’d prefer, try increasing client-side mic gain on a test call to confirm upstream source level matters. Please tell me which you want to do first (disable Krisp and retest, grab a Sessions recording, request the SIP SDP from Puzzel, or have me provide a gain-node example).
w
i am using a realtime
t
Thanks — since you’re using a realtime agent and the SIP codec is PCMU/8000, here’s a concise plan you can try next. 1) Disable Krisp in the realtime agent and inbound trunk, then retest • Disable noise cancellation in your agent RoomOptions (set noise_cancellation to None) and set
krisp_enabled: false
on the inbound trunk. • Re-run a few calls and check the user audio in Sessions. Tell me whether recorded audio level improves. 2) Verify provider-side gain/transcoding with Puzzel • Ask Puzzel to confirm they are not applying attenuation or gain compression on outbound RTP to your trunk and that they are not transcoding/altering payloads. • Request the SIP INVITE/200 OK SDP for a representative call so we can confirm the offered/accepted codecs and any codec preference order. 3) Capture a short reproducible example • From Sessions, export or share a short recording showing the low user level (a 10–20s clip is enough). • If possible, also provide the SIP SDP for that same call (INVITE + 200 OK) from Puzzel. 4) If audio ingest is low in Sessions, apply a realtime gain node • If recordings confirm low level after LiveKit ingest, add a small gain stage in your realtime audio pipeline before STT. Start conservatively (e.g., 1.5×) and clamp to avoid clipping. Example approach:
Copy code
async for frame in audio:
    audio_data = np.frombuffer(frame.data, dtype=np.int16)
    boosted = np.clip(audio_data * 1.5, -32768, 32767).astype(np.int16)
    yield rtc.AudioFrame(data=boosted.tobytes(), ...)
• I can provide a complete node example tuned for your agent if you want. Which do you want to try first — disable Krisp and retest, or share a Sessions clip plus the SIP SDP from Puzzel? Sources: Enhanced noise cancellation | LiveKit docs | HD voice for SIP | LiveKit docs | sip | livekit/livekit_composite | DeepWiki | Pipeline nodes and hooks | LiveKit docs