SIP Bridge Audio Quality: Grainy/Choppy on All Calls (Enterprise Voice AI Platform)

[testedmedia]

Environment

• LiveKit Cloud Project: voiceconsole-qepnkdkp
• Agent SDK: @livekit/agents v1.2.0, @livekit/rtc-node v0.13.24
• SIP Provider: Telnyx (credential connection)
• Inbound Trunk: ST_cELUNjYgg3CB (krispEnabled: true, encryption: DISABLE)
• Outbound Trunk: ST_3c2PdSQNSDB5 (UDP transport)
• TTS: ElevenLabs Flash v2.5 + Cartesia Sonic failover
• STT: Deepgram nova-3
• Agent Hosting: Railway (Docker, node:22-slim)

Description

We're building an enterprise voice AI platform. Phone calls through the SIP bridge sound grainy/choppy (~85-90% quality). WebRTC widget calls on the same agent are crystal clear (100%).

The audio artifacts are consistent across:

• All TTS providers (ElevenLabs, Cartesia)
• All call attempts
• Multiple Railway regions (US West B, US Central)

This matches the issues described in TEL-56 and AGT-2226.

What We've Tried (None Fixed the Audio Quality)

1. G.722 HD Voice enabled on Telnyx (inbound codecs: G722, G711U, G711A)
2. Krisp enabled/disabled on inbound trunk
3. NoiseCancellation removed from agent code (was double-processing with trunk Krisp)
4. Jitter buffer tuned to 40-120ms on Telnyx
5. SRTP disabled on both Telnyx and LiveKit trunk
6. TTS sample rate set to 16kHz to match G.722
7. audioSampleRate: 16000 in session.start() outputOptions
8. Multiple Railway regions tested
9. ca-certificates added to Docker image

Questions

1. What codec is actually negotiated on the SIP leg? How do we verify?
2. Is the SIP mixer buffer fix from #348 (5 frames -> 15 frames) deployed on LiveKit Cloud?
3. What configuration do enterprise customers use for crystal clear phone audio?
4. Are there any SIP bridge settings not exposed in the SDK (ptime, DTX, FEC)?

Additional Issue: LiveKit Phone Number Not Routing

We purchased a LiveKit Phone Number (+19848849165, PN_PPN_QoiYJzLSMwnV) to test managed telephony. Status shows ACTIVE, assigned to dispatch rule SDR_NscPJKLvW8eR. When called, it rings once and immediately hangs up. No agent logs appear. Agent works fine for outbound via Telnyx.

Recent Test Call

Room name: recording-for-ticket-1774684969 (available in LiveKit Cloud logs for project voiceconsole-qepnkdkp)

We're happy to provide recordings or get on a call to debug.

[testedmedia]

Bumping this - enterprise production blocker. We've exhausted all client-side configuration (G.722, TCP transport, Krisp, sample rates, jitter buffer, DTX, multiple regions). The graininess is consistent across all settings. We believe it's in the SIP bridge transcoding layer.

Also the LiveKit Phone Number (+19848849165, PN_PPN_QoiYJzLSMwnV) still hangs up immediately on inbound calls. This is assigned to dispatch rule SDR_NscPJKLvW8eR and shows ACTIVE status.

Would really appreciate guidance from the telephony team. Happy to jump on a call. cc @davidzhao @biglittlebigben

[testedmedia]

Bumping this - still a production blocker for our enterprise voice AI platform.

Update from our debugging tonight:

We discovered the root cause of inbound calls hanging up: the SIP dispatch rule was missing roomConfig.agents. After adding agents: [{agentName: "voiceconsole-agent"}] to the dispatch rule via the SDK, the dispatch configuration is now correct. However, calls to our Telnyx number (+13692290140) routed through the LiveKit SIP bridge are still not reaching the agent.

Current config (verified via SDK):

• Inbound trunk ST_cELUNjYgg3CB with numbers [+19842496665, +13692290140]
• Dispatch rule SDR_PHvNEFNkX9u9 with roomConfig.agents: [{agentName: "voiceconsole-agent"}]
• Agent CA_v6LevekLHXLC running (v20260330040858, us-east)
• Agent registers as voiceconsole-agent in ServerOptions

What we see:

• Zero activity in lk agent logs when calling the number
• The call hangs up immediately (no ring, no hold music, instant disconnect)
• Web-based calls via LiveKit rooms work perfectly (agent connects, speaks, full conversation)
• Only SIP inbound is broken

What we need from the LiveKit team:

1. Can you verify the SIP bridge is receiving the INVITE from Telnyx for +13692290140?
2. Is there a known issue with dispatch rules + roomConfig.agents for SIP calls?
3. Any additional SIP trunk configuration needed (allowed addresses, authentication)?

This is blocking production launch. We have paying clients waiting. Happy to jump on a call anytime.

cc @davidzhao @biglittlebigben

[alexlivekit]

Hi @testedmedia , can you please share the domain name provided to Telnyx for use with your calls? Is that using what the docs suggest?

The reason I'm asking is I see only one call from the number you mentioned on our platform, and it is using your project name rather than the SIP URI that's supposed to go there, and thus is promptly dropped on our end.

Edit: You can find the appropriate SIP URI in the top-right of either the Telephony/Trunks or Telephony/Dispatch Rules pages, or on the project settings page under the "Genera" section.

[alexlivekit]

A few more follow-up questions, if you don't mind answering those as well:

• Can you please provide a call ID we can take a look at for quality issues? Do I understand correctly that the quality issues were observed in the self-hosted version of our product, and attempting to reproduce this in our cloud environment ran into the difficulties described above and thus there are no example calls we can look at on our end quite yet?
• You mention you have measured the audio quality of SIP bridge calls, and consistently seen them score around 90%. Do you mind sharing some details on how these scores were obtained? There are quite a few means to measure audio quality, so I would love to understand which one it is in your case.
• Continuing with the quality score, I would love to understand what quality of results you see when transcoding either G.722 or G.711 to Opus, in place of the WebRTC widget that uses Opus natively and does not involve transcoding at all.

[testedmedia]

Hi @alexlivekit, thank you for the detailed response and for looking into this!

Root Cause Confirmed

You're right -- we had the wrong SIP URI configured in Telnyx. Our Telnyx FQDN connections were pointing to voiceconsole-qepnkdkp.sip.livekit.cloud (our project slug) instead of the actual SIP URI assigned to our project.

Additionally, we discovered that the phone number (+13692290140) was assigned to a Telnyx Call Control Application (webhook-based callback routing) rather than an FQDN connection for direct SIP forwarding to LiveKit. This explains why you only saw one test call -- most calls were hitting our webhook and never reaching the LiveKit SIP bridge.

What We're Fixing

1. SIP URI: Updating the Telnyx FQDN to use the correct LiveKit SIP URI (retrieving from the LiveKit Cloud dashboard per your guidance -- Telephony > Trunks, top-right)
2. Connection type: Moving the phone number from Call Control Application to FQDN connection for direct SIP forwarding
3. Codecs: Removing G.729 from Telnyx FQDN connection codecs (was in the allowed list alongside G722/G711U/G711A)

LiveKit-Side Config (Already Correct)

• Inbound trunk: ST_cELUNjYgg3CB (numbers: +19842496665, +13692290140)
• Dispatch rule: SDR_PHvNEFNkX9u9 (room prefix: sip-inbound-, agent: voiceconsole-agent)
• Krisp: disabled (handling noise at agent level)
• Media encryption: disabled

Follow-up Questions

1. Can you confirm that the SIP URI format should be <sip-subdomain>.sip.livekit.cloud where the subdomain is shown in the dashboard (not the project slug voiceconsole-qepnkdkp)?
2. For audio quality -- we haven't been able to test SIP bridge quality yet since inbound calls weren't routing. Once we fix the URI, we'll make test calls and share call IDs for your analysis.
3. Our quality scoring was subjective (team members rating calls) -- we'll provide proper call IDs from LiveKit Cloud logs once calls are flowing through the SIP bridge.

Will update this thread with a call ID once the fix is deployed. Thank you for the quick turnaround!