I am able to connect inbound / outbound call from my third party indian CPAAS, but my agent audio is not audible in the call. in my voice ai pipeline logs i can see a conversation is happening just that audio is not audible. I am describing my CPAAS provider screenshot of call tracer tool and please guide what might be wrong. The image is a screenshot from a SIP/RTP call tracing tool (likely Homer, SIPp, sngrep, Wireshark with call flow view, or a similar PBX/voip monitoring interface like from Asterisk or a custom media server dashboard). It shows a call flow diagram for an inbound SIP call (from a phone number to a LiveKit-integrated setup), colored by request/response, with timestamps, SIP messages, and media (RTP) streams visualized as arrows between participants. Key visible elements and timeline (left to right / top to bottom): • Left side — Appears to represent the originating caller / PSTN side (IP 159.117.150.40 or similar private/public IPs in 159.117.x.x range, possibly NAT'ed or carrier-side). • Middle / right side — Represents the LiveKit / Asterisk / IncomingMediaServer side (IPs like 143.223.94.x or 143.223.156.x, and internal 192.168.x.x addresses). • Call-ID — Something like alad f948-4ceb-b7e0-4f231d1b9521 (partial in the image). • Main SIP dialog flow: INVITE sent from caller (192.168.25:5060 or external) → to your SIP endpoint (sip:asterisk@... or similar @alert-easter-19258.cloud:5060). Multiple 100 Trying / 100 Processing responses. • Several 180 Ringing responses (at least 2–3 shown with slight time deltas, possibly forked or multiple legs). • 200 OK from your side (143.223.94.156?) → back to caller, with SDP body visible in the lower black area. • SDP details in the 200 OK include: • o=... 1979458311 ... IN IP4 159.117.150.40 (caller/originator info) • c=IN IP4 159.117.150.40 (connection address — caller sending media to this IP/port?) • m=audio 3572 RTP/AVP 0 101 (audio port 3572 on caller side, PCMU + telephone-event) • a=rtpmap:0 PCMU/8000 • a=rtpmap:101 telephone-event/8000 • a=ptime:20 • a=maxptime:140 etc. • ACK sent (completing 3-way handshake). RTP media streams shown as horizontal arrows: Bidirectional RTP appears briefly (labeled "audio 35372 (g711u)" and "audio 57448 (g711u)"). One direction has RTP flowing (e.g., from caller port ~6052 → your side port 57448 or similar). • But the diagram emphasizes one stream prominently, and the call ends with BYE from one side → 200 OK. What this likely indicates for your "call connects but no audio on phone" issue The signaling completes successfully (INVITE → 180s → 200 OK → ACK), so the call is "answered/connected". However, this is a classic one-way or no-audio-on-phone symptom. From the visible SDP and flow: • The 200 OK SDP is advertising media to 159.117.150.40 (likely the caller's public/NAT IP), but the caller phone may never receive RTP packets there — common when: • NAT/firewall blocks inbound RTP to the phone (phone is behind symmetric NAT/carrier-grade NAT). • LiveKit (or the IncomingMediaServer) is sending RTP to the wrong address/port (e.g., private 192.168 IP leaked instead of public, or wrong via received IP). • Asymmetric media paths: RTP from phone reaches LiveKit/agent (you hear caller), but RTP from LiveKit/agent doesn't reach the phone (caller doesn't hear you/agent). • Only one or partial RTP streams are highlighted — possibly showing media mostly in one direction or dropping early. • Codec is G.711 μ-law (PCMU), which is standard and unlikely the issue unless mismatched. Suggested description you can copy-paste to LiveKit support "Call connects successfully (INVITE → multiple 180 Ringing → 200 OK with SDP → ACK), but no audio is heard on the phone (caller side). The agent/LiveKit side can usually hear the caller fine. Attached call-flow screenshot from sngrep/tracer (or tool name) shows: • Signaling completes normally. • 200 OK SDP offers c=IN IP4 159.117.150.40 (caller's apparent public IP), m=audio 3572 RTP/AVP 0 101 (PCMU). • RTP starts briefly (g711u on ports ~35372 ↔️ ~57448), but likely only one direction flows properly. • BYE sent after ~35–50 seconds. Suspect one-way/no-audio from LiveKit → caller: • Possible NAT issue (caller behind CGNAT/carrier NAT, RTP from LiveKit not reaching phone). • LiveKit sending to wrong IP/port in SDP (private leak?). • RTP timeout/firewall drop on caller side inbound. • IncomingMediaServer / asterisk / LiveKit SIP dispatch misconfig for media relay. Happy to provide full PCAP or logs if needed. Using LiveKit Cloud + SIP trunk? Inbound call scenario." This should give them a clear starting point — one-way audio in LiveKit SIP setups is very commonly NAT/firewall/SDP address resolution related. Good luck!

Thanks for reaching out, Manav. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.

simply tell me what change i need to do on livekit side or cpaas side

Thanks — I’ll keep this short and actionable. Changes to make on the LiveKit side • Force media relay (TURN) so RTP is relayed instead of sent directly: ◦ Set

iceTransportPolicy: 'relay'

in your WebRTC client/connection config or ensure your server-side RTC config forces relay. • Ensure TURN/TLS is reachable from the PSTN/CPaaS path: ◦ Allow outbound TCP/TLS to LiveKit TURN on port 443 from your media servers. • Ensure LiveKit advertises public IPs (no private-IP SDP leaks): ◦ If self-hosted, configure your public IP/port or external IP mapping for RTP in your LiveKit/ingress gateway. • (If using LiveKit Cloud) ensure TURN domains are not blocked by DPI/proxy; allow/whitelist LiveKit TURN domains or disable DPI for them. Changes to make on the CPaaS / PSTN side • Use media anchoring or relay on the CPaaS so inbound RTP from LiveKit is accepted: ◦ Configure CPaaS to accept/route RTP from LiveKit’s public/TURN-relayed IP:port rather than requiring symmetric NAT from the caller. • If the caller is behind carrier NAT, enable or request CPaaS to enforce or enable RTP relay/TURN usage between CPaaS and LiveKit. • Ensure the CPaaS does not rewrite SDP to a private IP and that it forwards the correct public connection address (no 192.168.x.x in final SDP). • If required by the carrier, allow-list LiveKit egress IPs (provide your CPaaS with LiveKit’s region IP ranges). Immediate single-step test • Temporarily force TURN relay on LiveKit (

iceTransportPolicy: 'relay'

) and confirm the caller can hear agent. If that fixes it, finalize TURN/firewall and CPaaS relay settings. If this does not fix it, send the 200 OK SDP text or a short PCAP and I’ll tell you the exact IP/port mismatch to change.

Temporarily force TURN relay on LiveKit (

iceTransportPolicy: 'relay'

) and confirm the caller can hear agent. If that fixes it, finalize TURN/firewall and CPaaS relay settings. How to do this via livekit cloud

Thanks — here’s the short, exact change to make on LiveKit Cloud to force TURN relay. What to change (one-line) • Set the WebRTC connection option

iceTransportPolicy: 'relay'

when connecting to LiveKit so all media goes through TURN. How to do it (examples) 1) JavaScript / TypeScript (Browser or Node)

import { Room } from 'livekit-client';

const room = new Room();
await room.connect(
  'wss://<your-project>.livekit.cloud',
  '<access-token>',
  {
    rtcConfig: {
      iceTransportPolicy: 'relay',
    },
  }
);

2) Flutter • Pass

rtcConfig

with

iceTransportPolicy: 'relay'

in the

connect()

options of the LiveKit Flutter SDK (use the same key name). 3) iOS (Swift) • Provide

rtcConfiguration

with

iceTransportPolicy = .relay

when calling

connect()

. 4) Android • Set the PeerConnection/RTC configuration to use

iceTransportsType = "relay"

/ equivalent when creating the connection. Network checklist (required) • Ensure TURN (LiveKit’s TURN) is reachable from where your media originates — allow outbound TCP/TLS to LiveKit TURN on port 443. • If you have DPI/proxy (Zscaler, etc.), whitelist or bypass LiveKit TURN domains so TURN-over-TLS can establish. • If using a CPaaS/PSTN path, ensure they accept media from LiveKit TURN-relayed IPs or are configured to relay media. Test • Make a test call after changing the client(s). If the caller can now hear the agent, keep

iceTransportPolicy: 'relay'

or update CPaaS/firewall to allow non-relay paths once stable. If you want, tell me which SDK you’re using (JS/Flutter/Swift/Android or server-side) and I’ll paste the exact snippet for that SDK. Sources: client-sdk-flutter | livekit/livekit_composite | DeepWiki | client-sdk-swift | livekit/livekit_composite | DeepWiki | Configure ZScaler proxy for LiveKit connections | LiveKit | Firewall Tips for LiveKit Connectivity | LiveKit

i am creating a sip participant how to do it there

I don't have the answer you're looking for. You could also try asking your question: • in one of the other Slack channels or • to https://deepwiki.com/livekit/livekit_composite which is trained on all LiveKit source code If you find the answer, please post it here to help others!

give me an idea how to disable ice support telephony in livekit for my trunk