ASL will not connect to some HamVOIP nodes

[davidgsd]

This issue exists in ASL2, was never resolved, and appears to still be a bug in ASL3.
(ASL2 bug report: AllStarLink/ASL-Asterisk#70)

I posted on the ASL forum about an issue a customer was seeing (https://community.allstarlink.org/t/node-having-connect-issues-chan-iax2-c-auto-congesting-call-error/20155/4) and it turns out that the issue was happening because a node he was trying to connect to was running HamVOIP. I am able to duplicate the issue trying to connect to East Coast Reflector node 45192, whereas ECR node 27339 works fine. An ECR admin informed me that this is a known issue and thus why they have a node that runs ASL rather than HamVOIP so that ASL users are able to connect to their system.

Asterisk output when connecting to these nodes:

3040-asl3*CLI>  rpt fun 571570 *345192
[2024-08-24 21:31:46.868] NOTICE[13210]: chan_iax2.c:4790 __auto_congest: Auto-congesting call due to slow response
    -- Hungup 'IAX2/12.17.28.213:4598-16274'
    -- Hungup 'DAHDI/pseudo-1198605625'
3040-asl3*CLI>

Successful connect example to ECR's ASL node:

3040-asl3*CLI> rpt fun 571570 *327339
    -- Call accepted by 12.17.28.195:4569 (format ulaw)
    -- Format for call is (ulaw)

This may not be an ASL bug per se but ASL and HamVOIP should be interoperable over IAX. Would be great if the cause of this issue could be found and fixed. It is very easy to reproduce, just try connecting to 45192 from any ASL node. (HamVOIP nodes do not get any error and connect fine to 45192.)

I and others have noticed that a significant percent of other nodes also exhibit the same issue when trying to connect to them from an ASL node. The connection status will show as "Connecting" for a few seconds (eg. in AllMon) and then disappear.

[eliggett]

Try adding:

autokill=no

To the relevent sections in iax.conf. I think this may disable the auto-congestion feature. I'm not sure though as I haven't run into this before.

[davidgsd]

Hi, I changed autokill from yes (default) to no in iax.conf, and now the auto-congesting message went away, but the connect still fails.

Connected to Asterisk 20.9.1+asl3-3.0.4-1.deb12 currently running on 3040-asl3 (pid = 39741)
3040-asl3*CLI> rpt fun 571570 *345192
    -- Hungup 'IAX2/12.17.28.213:4598-12526'
    -- Hungup 'DAHDI/pseudo-1484859680'

Thanks

[jxmx]

``

I think this may disable the auto-congestion feature. I'm not sure though as I haven't run into this before.

It's basically a "don't permit slow connection" response timer:

autokill yes | no | <milliseconds> If we don't get acknowedge packet (ACK)
in 2000ms and this option is set to 'yes', then we cancel the whole thing. Except
yes and no, we can specify the timeout in milliseconds.

example: autokill=yes

In general, you DO NOT want to set this to 'no' because then a very slow-responding node will pull your whole system performance down.

[InterLinked1]

It could be that those nodes don't support call tokens, I forget when those were added. Does this help at all?

maxcallnumbers_nonvalidated = 5
calltokenoptional=0.0.0.0/0.0.0.0
requirecalltoken=no

[jxmx]

There is no general case of interoperability problems with AllStarLink and HamVOIP-based nodes. Our local system currently has a mix of both as we're still in the process of upgrading all legacy nodes to ASL3. I can connect to any of the old HamVOIP nodes just fine. Most likely, there is some incompatible settings change regarding the IAX protocol or Extensions on the HamVOIP side that prevents inbound IAX connections from ASL3. Someone with admin/debug level access to a node that doesn't work would be needed to troubleshoot.

You can try connecting to node my node 43211. That is a HamVOIP system and I have no problems connecting to it from ASL3.

[jxmx]

When I try to connect to node 45192, it's immediately hanging up on my "call":

# grep chan_iax2 debug.log
[2024-08-25 14:37:55.122] DEBUG[217739] chan_iax2.c: Immediately destroying 15680, having received hangup
[2024-08-25 14:37:55.125] DEBUG[217751] chan_iax2.c: We're hanging up IAX2/66.219.164.130:4575-15680 now...
[2024-08-25 14:37:55.125] DEBUG[217751] chan_iax2.c: Really destroying IAX2/66.219.164.130:4575-15680 now...
[2024-08-25 14:37:55.125] DEBUG[217751] chan_iax2.c: schedule decrement of callno used for 66.219.164.130 in 60 seconds
[2024-08-25 14:37:55.125] DEBUG[217721] chan_iax2.c: Checking device state for device 66.219.164.130
[2024-08-25 14:38:11.176] DEBUG[217751] chan_iax2.c: ip callno count incremented to 1 for 12.17.28.213
[2024-08-25 14:38:11.176] DEBUG[217721] chan_iax2.c: Checking device state for device 12.17.28.213
[2024-08-25 14:38:16.256] DEBUG[217751] chan_iax2.c: We're hanging up IAX2/12.17.28.213:4598-9499 now...
[2024-08-25 14:38:16.257] DEBUG[217721] chan_iax2.c: Checking device state for device 12.17.28.213
[2024-08-25 14:38:26.255] DEBUG[217735] chan_iax2.c: Really destroying 9499 now...
[2024-08-25 14:38:26.256] DEBUG[217735] chan_iax2.c: schedule decrement of callno used for 12.17.28.213 in 60 seconds
[2024-08-25 14:38:38.697] DEBUG[217751] chan_iax2.c: ip callno count incremented to 2 for 12.17.28.213
[2024-08-25 14:38:38.698] DEBUG[217721] chan_iax2.c: Checking device state for device 12.17.28.213
[2024-08-25 14:38:43.977] DEBUG[217751] chan_iax2.c: We're hanging up IAX2/12.17.28.213:4598-9132 now...
[2024-08-25 14:38:43.978] DEBUG[217721] chan_iax2.c: Checking device state for device 12.17.28.213
[2024-08-25 14:38:53.977] DEBUG[217735] chan_iax2.c: Really destroying 9132 now...
[2024-08-25 14:38:53.977] DEBUG[217735] chan_iax2.c: schedule decrement of callno used for 12.17.28.213 in 60 seconds
[2024-08-25 14:38:55.124] DEBUG[217735] chan_iax2.c: ip callno count decremented to 0 for 66.219.164.130

[davidgsd]

It could be that those nodes don't support call tokens, I forget when those were added. Does this help at all?

maxcallnumbers_nonvalidated = 5
calltokenoptional=0.0.0.0/0.0.0.0
requirecalltoken=no

I added those lines in iax.conf below the autokill line but above any context stanzas, and it does not make a difference.

FYI I do see this behavior on at least 5-10% of nodes I try to connect to, and always have, from many different nodes I've made in the past 1.5 years.

(I do recall someone mentioning it might have something to do with IAX port numbers, some HV versions use different port # defaults. I wouldn't see why that should make any difference, an IAX connect should work to any port number, but maybe HV or ASL2/3 are doing something non-standard / not allowing certain port numbers.)

[eliggett]

You should probably remove the autokill line as it was merely a diagnostic to see if the same thing kept happening or not.

[davidgsd]

There is no general case of interoperability problems with AllStarLink and HamVOIP-based nodes. Our local system currently has a mix of both as we're still in the process of upgrading all legacy nodes to ASL3. I can connect to any of the old HamVOIP nodes just fine. Most likely, there is some incompatible settings change regarding the IAX protocol or Extensions on the HamVOIP side that prevents inbound IAX connections from ASL3. Someone with admin/debug level access to a node that doesn't work would be needed to troubleshoot.

You can try connecting to node my node 43211. That is a HamVOIP system and I have no problems connecting to it from ASL3.

Could you try connecting to node 45192 from one of your HV nodes? If that works (which I'm sure it will), but it does not work from any of your ASL (2 or 3) nodes (which I'm sure it won't), this will confirm ASL is doing something differently and maybe you could then take a look at the IAX packets from both and see what's different?

BTW this is not just an issue with 45192, I could list dozens of other nodes that also don't accept connections from ASL nodes, thus it is a pretty major issue that seems to have been around a long time. Maybe no one has noticed because historically HV has been the more popular distro (due to their being the first to support RPi and because most node vendors use HV), thus it would be easy for the relatively small number of ASL users to assume it was a bug with other nodes not accepting connections, when in fact those nodes accept connections fine from HV nodes.

Theoretically the process by which Asterisk opens an IAX connection should be pretty straightforward and should be the same whether it's HV or ASL 2 or 3. There could be other variables, maybe HV is verifying registration status of nodes differently or something like that.

[jxmx]

As I noted above, HamVOIP is sending back an immediate "hangup" from the IAX debugging output. The only way to successfully debug this would be for someone with a HamVOIP node that isn't interoperable to provide their configuration and provide debugging output. There's nothing I can see from the side that works that solves this problem.

[KB4MDD]

I turned on iax2 set debug on and it does not appear that we are even getting a response from the HamVOIP node. As @jxmx noted, we really need to see debugging output on their side.

[W6HBR]

Correct me if I'm wrong, but didn't HV implement their own registration and DNS lookup system that worked side by side with the ASL system? I'm wondering if these HV nodes are only using the HV reg system and not allowing nodes that are only registered on the ASL system.