Hey Chrism, signaling is fine, issue is on the media return path.
Retell’s agent is producing audio but RTP isn’t making it back. Your tcpdump is only watching for return traffic from 161.115.x.x but Retell actually publishes three IP ranges:
18.98.16.120/30
143.223.88.0/21
161.115.160.0/19
Retell could be sending RTP back from one of the other two ranges and your firewall is dropping it before it hits the NIC, which is why tcpdump shows nothing.
Two things to do right now:
Run tcpdump -i any -n udp portrange 10000-20000 with no source filter during a live call and see if packets are coming in from any of those ranges
Make sure your firewall allows inbound UDP 10000-20000 from all three blocks, not just 161.115.x.x
Hello @chrisin.apa Retell’s known IP ranges for RTP traffic:
18.98.16.120/30 (all regions)
143.223.88.0/21 (certain US traffic)
161.115.160.0/19 (certain US traffic)
Your tcpdump shows Retell is sending RTP from 161.115.x.x — which is within the 161.115.160.0/19 block. The most probable issue is that Retell is sending RTP to the correct address, but something between Retell and your Asterisk is dropping it (upstream firewall/ISP, not your local firewall).
Things to verify:
Confirm your upstream/cloud firewall (not just local) allows inbound UDP 10000–20000 from all three Retell CIDR blocks.
Verify the SDP c= line Asterisk sends in the INVITE/200 OK actually contains the public IP 45.161.109.142 — not a private/NAT’d address.
Ensure no intermediate device (router, ISP NAT) is blocking asymmetric UDP flows from 161.115.x.x.
Can you share the relevant Call Ids so i can check it with the Team. Thank You
Thanks for the clarification. Here are the relevant Call IDs for your team to review:
call_dafc484f868f394e2e07cb47fe8
call_f295dee229337a5246ec7d3e746
call_e28c81838f59af72adcf5b2ed39
From our side, we confirmed that SIP signaling is working and Asterisk is publishing the public IP correctly in SDP:
45.161.109.142
We also confirmed that local iptables allows UDP 10000–20000. However, tcpdump on the server shows RTP leaving Asterisk toward Retell, but we do not see RTP returning back to the server.
We will also validate with our upstream/cloud provider that inbound UDP 10000–20000 is allowed from all Retell RTP ranges:
18.98.16.120/30
143.223.88.0/21
161.115.160.0/19
Please check from your side whether Retell sent RTP back to our Asterisk server for those Call IDs, and from which source IP/range.
Hello @chrisin.apa thanks for the detailed write-up and the three call IDs. Here’s what we’ve verified end-to-end on our side:
All three calls are BYOC outbound via your Netvoiss trunk prsip.netvoiss.cl, UDP), dialToSip=true. Signaling is clean — INVITE / 100 / 180 / 200 OK + SDP / ACK / late BYE from your side. No 4xx/5xx, no early teardown.
Our 200 OK advertises media at 161.115.181.95:9000, 161.115.181.204:9000, and 161.115.180.215:9000 for the three calls respectively. All three are inside our published egress block *161.115.160.0/19** (see Custom Telephony Overview - Retell AI ). It is not a NAT’d or rewritten address.
The agent half worked: LLM and TTS ran, bot audio is in the call recording. But our ASR socket opened cleanly (62/73/76 ms) and then received zero user audio frames on every call — the transcripts are agent-only, and on call_e28c818… the agent’s own silence detector fired a reprompt at t≈16s before your side BYE’d at t≈20s. That means the audio gap is bidirectional, not only Retell → caller.
A separate inbound call on the same DID at 01:20:49 UTC call_c07008a17…) ran 25 s and ended on user_hangup, so the trunk itself is reachable bidirectionally — the failure is scoped to these outbound sessions.
We can’t fully attribute the missing return-RTP from Retell-side data alone: LiveKit Cloud is a managed plane and we don’t have direct access to its per-session SIP-ingress / RTP counters, and our SBC PCAPs only contain signaling. Two parallel asks on a fresh test call:
Confirm your PBX/firewall allowlist (egress AND return) includes all three Retell ranges, not just the two most commonly cited:
18.98.16.120/30
143.223.88.0/21
*161.115.160.0/19** ← this is the one actually serving your calls
Run a tcpdump on the public/WAN-facing interface of your firewall (not the Asterisk LAN side), filtered to UDP between 45.161.109.142 and 161.115.0.0/16 in both directions, for one fresh test. Share that pcap plus:
the new call_id,
the public source IP and port your Asterisk used for outbound RTP.
If the WAN capture shows LiveKit’s RTP is not reaching your edge at all, we can take that call_id + your RTP 5-tuple to LiveKit support for the session-level ingress trace (received-from vs egressing-to IP:port, packet counts, any rtp_timeoutparticipant_left). If it is reaching the WAN side but being dropped before Asterisk sees it, the issue is CGNAT / stateful translation on the Claro circuit.