Outbound connections to UK nodes work perfectly and hold (e.g. 2196 FreeSTAR UK HUB 1 — ESTABLISHED, transceive, stable). Outbound connections to transatlantic (Canadian, and North American generally) nodes fail. Two failure patterns depending on the node:
chan_iax2.c:4830 __auto_congest: Auto-congesting call due to slow response, then repeated attempt_reconnect every ~10s until it gives up, or
Call accepted, format negotiated, then immediate HANGUP (cause code 16), node announces "connection failed", retries.
Example (node 43079):
-- Call accepted by 104.159.127.211:4569 (format ulaw)
-- Format for call is (ulaw)
-- Hungup 'IAX2/104.159.127.211:4569-xxxx'
NOTICE app_rpt.c:2531 attempt_reconnect: Reconnect Attempt to 43079 in progress
... (repeats) ...
NOTICE chan_iax2.c:4830 __auto_congest: Auto-congesting call due to slow response
This previously worked — I have connected to these North American nodes regularly since setting the node up. UK connectivity is unaffected.
What I have already checked / ruled out
Registration is valid and consistent.asl-node-lookup 66804 returns matching records:
rpt show registrations: 1 HTTP registration, State Registered, Perceived 92.40.204.204:4569 — registered IP and perceived IP match (so the documented CGNAT "different IP for registration vs IAX" failure mode does not appear to apply here — my egress IP is consistent).
Far-end lookup resolves correctly:rpt lookup 43079 → radio@104.159.127.211:4569/43079,104.159.127.211 (standard port, the IP the call reaches).
Network path is healthy.ping 8.8.8.8: 0% loss, avg ~41 ms, jitter (mdev) ~8 ms — a clean, low-latency 4G path. (The failing far-end host itself does not answer ICMP, but its IAX accepts the call, so it is reachable.)
Packet capture confirms bidirectional IAX to a failing far-end node: NEW → ACCEPT → ACK → … → HANGUP all flow in both directions; the far end completes the IAX handshake then tears the link down.
app_rpt debug level 7 logs nothing about the connection on my side during the failure — only the HANGUP/auto_congest. No local refusal reason is logged.
chan_simpleusb.so and res_usbradio.so loaded and running.
My questions
This pattern (works to some nodes, auto_congest/cause-16 to others, far end completes handshake then drops) matches app_rpt issue #389 — "ASL will not connect to some HamVOIP nodes", reported as unresolved since ASL2 and still present in ASL3. Is node 43079 (and the other North American nodes I'm failing on) running HamVOIP rather than ASL? If so, is #389 still the expected cause, and is there any current workaround?
If it is not the HamVOIP issue: given everything above checks out and UK nodes connect fine, what else would cause destination-specific auto_congest/cause-16 only to transatlantic (Canadian/North American) nodes? Is anyone else currently seeing connection problems to Canadian/North American nodes from outside the region?
I have a full Asterisk CLI log with iax2 set debug on output and the tcpdump capture available if useful — happy to attach.
I just checked, and node 43079 is running ASL, not HamVoIP.
That immediate accept/teardown thing sounds to me like either an IP address mismatch between your registered IP address and what the node sees you as (maybe something odd going on with CG-NAT once it leaves the UK).
Out of interest, can you successfully connect to node 55553, 506311, or 29777?
55553 and 506311 are both set up to ignore registration, and 29777 is not. However, just as a fun datapoint, 29777 and 506311 are both on the same physical host. So, if you can connect to 506311 but not 29777, that might be a clue.
These nodes are under my control, so I can look at your incoming connection from this side and maybe see what's going on if it fails.
I bet 2196 ignores authentication/registration. Several big networks do just to make it easier for people on mobile connections and with often changing IP addresses.
By the way, 55553, 506311 and 29777 are all HamVoIP nodes, but they have been modified to prefer ulaw instead of G726 as HamVoIP normally does. I can't easily upgrade these nodes, as they are running on Raspberry Pi's in data centers, and changing distros requires swapping images/SD cards, so this should be at least a reasonable test of connecting to HamVoIP and North American nodes.
Ran more tests — thanks, that matrix was useful. Your three all connect fine: 55553, 506311 and 29777, including 29777 which enforces registration. So it's not HamVOIP/codec (all three negotiated ulaw fine) and an enforcing node let me in.
My two usual nodes still fail though, and in two different ways:
43079 (ASL, port 4569): call accepted, then immediate hangup — cause code 16, "connection failed". The handshake completes, then it's dropped. This is the one I suspect is the CGNAT registration-IP-match issue. I'm on SMARTY (Three UK MVNO) on 4G, and the ASL manual's Known Issues page describes exactly this — mobile CGNAT where the registration server sees a different public IP than the receiving node sees on the incoming connection (it even lists Bell Canada, Vodafone et al). My registered IP is 92.40.204.204. Since 29777 is yours and enforces registration — next time it refuses me, or from your logs, what source IP do you receive my incoming connection from? If it's anything other than 92.40.204.204, that's the mismatch.
579050 / 579051 (host 156.57.190.25, port 4570): these never even accept the call — straight to auto_congest, no "Call accepted" line at all. They're on a non-standard port 4570, so I'm wondering if that's their own inbound forwarding/reachability rather than anything my end. rpt lookup resolves them correctly to 156.57.190.25:4570, so addressing is fine — the far end just isn't answering on 4570.
So possibly two separate issues. Keen to confirm the 43079/CGNAT one from your receiving side if you can.
The ones that never accept the call...I would suspect there are networking issues. Maybe their ISP reset the routers and erased all port forwards. Maybe it's offline. I think the easiest answer here is "those nodes have a problem"
As far as the ones handshaking and then hanging-up; that to me sounds like a NAT issue. Usually one side of the IAX connection initiates the handshake, the other-side initiates the connection. (I come from real VoIP land and this is how it's always worked over there). Ignoring auth/registration might help that....we absolutely never used that in our applications so I have no clue.
The only other thing I can offer is this: I run node 59408 and I'm in the US. My node's ingress/egress is in Buffalo. I have an asterisk console sitting in a shell window that I'll leave there for most of the day. If you want to try and connect to it and see if that fails...then just note down what time you attempted it and what your apparent IP was supposed to be. I'll turn the HT on...you can try to get my attention if you connect; although I work from home and I've got meetings I'm in an out of; so there's a chance I won't be able to respond.
This (poorly worded error) is always an network issue. Either the destination IP is not reachable for any reason or the incoming IAX call is being ignored (firewall rule, ACL check, database deny check, mismatched IP address). It could be originating from your site (behind CGNAT so ports are skewed, CGNAT using multiple IPs, etc.) or at the other end.
-- Accepting UNAUTHENTICATED call from 172.22.1.3:13805:
-- > requested format = ulaw,
-- > requested prefs = (ulaw|adpcm|gsm),
-- > actual format = ulaw,
-- > host prefs = (ulaw|adpcm|gsm),
-- > priority = mine
-- Executing [59408@radio-secure:1] Set("IAX2/172.22.1.3:13805-7867", "NODENUM=66804") in new stack
-- Executing [59408@radio-secure:2] NoOp("IAX2/172.22.1.3:13805-7867", "Connect from node 66804 to node 59408 using IAX2") in new stack
-- Executing [59408@radio-secure:3] ExecIf("IAX2/172.22.1.3:13805-7867", "0?Hangup") in new stack
-- Executing [59408@radio-secure:4] GotoIf("IAX2/172.22.1.3:13805-7867", "1?:allowlist") in new stack
-- Executing [59408@radio-secure:5] NoOp("IAX2/172.22.1.3:13805-7867", "Channel Peer IP: 172.22.1.3") in new stack
-- Executing [59408@radio-secure:6] GotoIf("IAX2/172.22.1.3:13805-7867", "0?connect") in new stack
-- Executing [59408@radio-secure:7] GotoIf("IAX2/172.22.1.3:13805-7867", "1?denylist") in new stack
-- Goto (radio-secure,59408,11)
-- Executing [59408@radio-secure:11] GotoIf("IAX2/172.22.1.3:13805-7867", "0?:connect") in new stack
-- Goto (radio-secure,59408,14)
-- Executing [59408@radio-secure:14] Rpt("IAX2/172.22.1.3:13805-7867", "59408") in new stack
[2026-06-30 11:06:37.152] WARNING[29573][C-00000001]: app_rpt.c:6498 parse_caller: Node 66804 IP 92.40.204.204 does not match link IP 172.22.1.3!!
So...oops. This is clearly a me issue. 172.22.1.3 is a VPN node my ASL3 is tunneled through. This is a Zerotier VPN and not a Wireguard...so I had to invent the setup. Let me look in to what rules I need to adjust on my gateway.
That's brilliant — that parse_caller warning is exactly the smoking gun. Node 66804 IP 92.40.204.204 (which is my correct registered IP) not matching the link IP it arrives on. Good to know it's your ZeroTier gateway in this case rather than my end — but it confirms the mechanism perfectly, which is hugely useful.
That's almost certainly what's killing my connection to 43079 too — same parse_caller IP-match reject, except in that case I suspect it's my SMARTY 4G CGNAT presenting a different public IP for the outbound IAX than my registered 92.40.204.204, rather than a VPN on their side. The ASL manual flags mobile CGNAT carriers for exactly this.
If you get your gateway rules sorted I'll happily retry 59408 as a clean test — and if it connects once your tunnel's fixed, that tells us your end was the only thing wrong there. Either way, thanks, this is the most concrete data I've had on the whole problem.
Yup. I apologize. I'm pretty red-faced over here offering a test on something that was broken. However, I thank you for attempting it as it showed me my stuff was actually broken.
I found the masquarade rule that was SNAT'ing everything to 172.22.1.3, removed it, restarted asterisk. It should work now.
CGNAT gateways often change on a whim. I've seen people appear as 3 or 4 different gateways when diagnosing phones. Every connection attempt would be a different gateway.
Just retried after your fix — still failing the same way my end (accepts then immediate hangup, connection_failed), 18:44 BST. Can you check your console for the parse_caller line on that attempt? Last time it showed Node 66804 IP 92.40.204.204 does not match link IP 172.22.1.3. Curious whether it's still showing 172.22.1.3 (SNAT rule didn't fully clear / Asterisk still holding it) or whether it's now showing my actual incoming IP — if it's the latter and it's a Three/SMARTY address that isn't 92.40.204.204, that's my CGNAT and confirms I need the tunnel.