DTMF with 6 digit node failing to connect

1

I have 3 nodes setup on 3 different Debian 12 hosts. When using Droidstar or DVSwitch, sending *3123456 to connect to one of the other nodes it fails. On the node being connected to there is warning in the logs (see below). I can connect using the CLI. I was able to connect, by accident, to another 6 digit node indicating something within my setup that is causing the issue. Any hints on what would cause this or if it is an issue with the release I am running?

WARNING[100369][C-00000018] app_rpt.c: Cannot find specified system node 12345

Asterisk 20.11.0+asl3-3.2.0-2.deb12

2

3 nodes setup on 3 different Debian 12 hosts ON THE SAME LAN? If so, have you looked at :

ASL3 Manual : Multiple Nodes on the Same Network

3

Yes, I have followed that document. Each on separate IPs and unique IAX ports with firewall port forwarding for TCP and UDP. The problem is using DTMF to connect to the other nodes. Using the CLI works. Using DTMF does not work. The nodes resolve using asl-node-lookup. One node is setup for Echolink and that works.

This is successful
*CLI> rpt cmd 456789 ilink 3 123456

This fails with the log showing the node truncated to 5 digits
DVSwitch, Droidstar connected to 456789, or Radio RF
sending
DTMF *3123456
generates the warning message in the logs on 123456
WARNING[100369][C-00000018] app_rpt.c: Cannot find specified system node 12345

4

What are the actual node numbers you’re asking about?

6

We found an issue with the DNS records for your pre-NNX node number. All should be better now.

7

A quick test with Driodstar and the DTMF worked. Thank you.

8

For others with a similar issue in the future
Using the following where 12345 is the node in the warning message

asl-node-lookup 12345

is an indicator of the DNS conflict issue if the response is anything other than

No SRV record.

I saw the entry for the old, original 5 digit node but wasn’t certain if it was normal when converted to the NNX or if it should not exist.

Thank you for removing it and clearing up the issue.

9

So, we need to be clear here because there’s a lot of accumulated back-end history here. When you convert a 5 digit node to a 6 digit node that’s been online for a period of time, there is a delay in withdrawing the 5 digit number from DNS. The reasons are complicated and confusing, but the short answer is there’s a different issue with the concept of “active nodes” and “active IPs” as it’s currently calculated and maintained. It makes removing a no-longer-there node problematic from a “how long it takes” computation problem. Currently, to minimize conflicts between “updates” and “cleanups”, the cleanups are only happening once per day. So a 5-digit to 6-digit conversion should be cleaned up sometime after midnight UTC.

Once we can get to the bug/issue/logic problem with the “active” concept, then this problem can be cleaned up once and for all.

10

Are you saying the cleanup should happen within 24-48 hours and there is work to make it happen at the time of conversion? For your awareness, I converted from a 5 to a 6 digit node about 5 days or more before opening this topic.

11

The cleanup script was not running properly. I fixed that. That’s why it took 5 days to cleanup.

12

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.