I have deployed the LiveKit on EKS cluster, When I change assigned private IP address to the the EKS Ek2 nodes, Voice is not coming

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

Hello I have a EKs cluster inside a private subnets and kamailio, rtpengine, sip server, livekit server and my ai agent are running as services and pods. Now the issue call is connected sip and livekit logs shows the call connects and livekit roo is crerate the ai agent joins the room and puts the first hello message as intinal conversation in room. I am able to see all this in logs. but in call the there is no voice a dead silence in the call. What could be the possible issue or break point.

Thanks — that’s a helpful update. I’m responding to the part where the SIP call connects, LiveKit shows the room and the AI agent joins and posts the initial message, but there’s no audio (dead silence). Let’s focus on likely break points and gather the few logs/outputs that will quickly pinpoint the problem. Quick likely causes • Media (RTP) packets are not being routed between the SIP side and LiveKit clients (NAT/firewall, wrong IPs, or missing UDP rules). • ICE negotiation fails or falls back to data-only (signaling OK but RTP not established). • rtpengine / Kamailio SIP-to-WebRTC bridging misconfiguration (wrong IP/ports, codec mismatch, or RTP relaying disabled). • TURN/coturn not reachable or not configured/used, so clients can’t exchange media across the private subnet. • Codec/DTLS/SRTP negotiation failures (mismatched codecs or encryption settings). • RTP port range not opened on nodes or blocked by security groups / NACLs. Targeted questions (these will let me point to the exact fix) 1. ICE / candidates ◦ Can you share the ICE candidate lines from the LiveKit SDK client logs or browser console (or a

getStats()

summary showing ICE candidates and selected pair)? ◦ Do ICE candidates include private node IPs only, public IPs, or TURN addresses? 1. TURN / relay ◦ Are you running a TURN server (coturn or similar)? Is it inside the private subnet or external? ◦ Is LiveKit configured to use that TURN server? Is the SIP side using it for media relaying? ◦ Can clients reach the TURN server on its UDP/TCP ports from their networks? 1. rtpengine / Kamailio setup ◦ Is rtpengine handling RTP media relay between SIP and LiveKit? If so, are rtpengine logs showing RTP packets being sent and received? ◦ Are the RTP proxy IPs configured correctly in Kamailio/rtpengine and matching the node IPs after your change? 1. Network / ports ◦ What UDP/TCP port ranges are you using for RTP on rtpengine and LiveKit? (Commonly UDP 10000–20000) ◦ Are the EKS nodes’ security groups and VPC NACLs allowing those UDP ports and RTP directions? ◦ After the private IP change, did you update any static IP references (rtpengine advertised IP,

externalIP

, LoadBalancer targets, or SIP contact/SDP fields)? 1. Logs and errors ◦ Do livekit-server logs show ICE/DTLS/TLS errors, ICE timeouts, or TURN allocation failures? Please paste a few relevant log lines around the time of a silent call. ◦ Any rtpengine logs showing packet counts, errors, or “no media” warnings? ◦ Any browser/client console errors relating to DTLS handshake, ICE state “connected” vs “completed”, or codec negotiation? 1. Call symptom specifics ◦ Is it one-way (agent hears user but user silent) or both-way silent? ◦ Are you seeing RTP byte/packet counters increase on either side? (rtpengine / LiveKit stats) ◦ Do participants appear “connected” in LiveKit and can send/receive data messages, but audio packets are zero? Immediate checks you can run now 1. From a pod or node, try UDP packet tests to the other side on the RTP port range (e.g.,

nc -u

or

socat

) to confirm connectivity. 2. Check rtpengine stats or use tcpdump on rtpengine and livekit-server pods to confirm whether RTP packets arrive on the expected interfaces/ports. 3. Confirm ICE selected pair in the client

getStats()

— if no candidate pair with RTP bytes is selected, ICE/media handshake failed. 4. Verify that rtpengine/coturn advertise the correct external/private IPs in their configs after the IP change. 5. Temporarily open RTP port ranges in security groups and run a test call to see if audio returns (helps confirm network block). What I can do next for you • If you paste snippets of: ◦ livekit-server ICE/DTLS logs around the call, ◦ rtpengine logs showing RTP activity for that call, ◦ a short

getStats()

ICE candidate/selected pair output from the client, I’ll review them and point to the exact failing component and config to change. If you prefer, tell me whether the silence is one-way or two-way right now and share which of these you can collect quickly (logs, getStats, tcpdump). I’ll give step-by-step commands to gather the exact traces. , with interactive elements