Thanks — this is a clear description and a common pattern. I’ll address what’s likely happening, what to check first, and some focused actions you can take to restore media when your EKS nodes are private. Acknowledging the problem • You said SIP signaling (via Kamailio + NLB with Elastic IPs) works but audio is lost once the EKS nodes are private. That strongly indicates signaling is reaching your SIP stack but the media (RTP/WebRTC) path is being blocked or not being routed back to participants. Why this typically happens • WebRTC media uses UDP (RTP) and relies on bidirectional connectivity to the SFU (LiveKit) or a TURN relay. When nodes are in private subnets without public IPs, external peers cannot open direct UDP paths to the LiveKit pods unless you provide a public-facing relay or properly NAT/forward UDP traffic. • SIP can work over TCP/UDP through your NLB because you already exposed Kamailio with Elastic IPs; media uses high UDP ports and STUN/TURN traffic which are commonly blocked or not forwarded by default. • If LiveKit (SFU) cannot receive or send RTP to the client (or the TURN relay), audio will be one-way or silent even though signaling is OK. Targeted diagnostic checks (quick wins) 1. Confirm ICE candidates and connectivity ◦ Check client-side WebRTC stats or logs: are ICE candidates being gathered that point to public IPs or a TURN server? Are connections failing to establish (ICE state stuck at "checking" or "failed")? 1. Check LiveKit location for public candidates ◦ Verify the SFU advertises reachable candidates (public IP/NLB/TURN). If it only advertises private addresses, external clients can’t reach it. 1. Verify TURN/relay configuration ◦ Are you using a TURN relay? If not, direct peer-to-SFU connectivity will fail when SFU is not publicly reachable. ◦ If you are using TURN, ensure clients actually receive TURN candidates and can authenticate/connect to TURN on TCP/443 and/or UDP. 1. Check network path & ports ◦ Ensure UDP ranges used by LiveKit (RTP) are allowed through any NLB or NAT gateway you use. ◦ Confirm security groups, NACLs, and route tables allow return UDP traffic. 1. Observe server logs and WebRTC stats ◦ Look for dropped or missing RTP packets, STUN failures, or ICE timeout messages in LiveKit logs and client console. Focused remediation options • Use a TURN relay (recommended if you cannot give pods public IPs) ◦ Configure a TURN server reachable on firewall-friendly ports (TCP/443 and TCP/3478). TURN over TCP/TLS (443) is especially useful when UDP is blocked. ◦ Ensure clients receive TURN candidates and that LiveKit is configured to advertise/use the TURN relay for media. • Put LiveKit media behind a UDP-capable load balancer / public entrypoint ◦ Deploy an NLB with UDP listeners for the RTP port range and target the LiveKit nodes, or use a public NAT gateway that correctly forwards UDP to pods. ◦ Ensure the NLB is configured to preserve source IPs if required by your deployment and that health checks align with LiveKit expectations. • Hybrid approach: keep Kamailio public but relay media through TURN ◦ Keep your SIP signalling path as-is (NLB → Kamailio) but configure LiveKit clients to use TURN for media. This avoids making SFU nodes public. • Ensure proper STUN behavior ◦ If using STUN, the cluster needs to be able to reflect the correct public address. If STUN responses are not reachable, ICE candidate selection will fail. Specific clarifying questions to narrow it down • Are you currently providing any TURN server to clients? If yes, which host/ports and do client logs show TURN candidates? • What ICE state do client-side logs report when a call connects but audio is missing (e.g., connected vs checking vs failed)? • How is LiveKit exposed today (Service type, Ingress/NLB config)? Do you have any UDP listeners configured on the NLB? • Do LiveKit logs show any STUN/TURN errors or RTP packet drops around the call time? Next steps I can help with • Walk through how to verify ICE candidate exchange and read WebRTC stats to confirm whether the SFU or TURN is being used. • Provide a checklist for TURN configuration and minimal NLB settings (UDP listeners, health checks) to publish media securely. • Help interpret LiveKit logs or a sample client ICE trace if you paste them here. If you tell me whether you already have a TURN server configured and what the LiveKit exposure currently looks like (Service/NLB details), I’ll give step-by-step checks and configuration recommendations tailored to your setup. Sources: Firewall Tips, with interactive elements