I’m an ASL newbie. I have two nodes in the cloud. One accepts incoming calls I place from DVSM, while the other always fails. Both are extension nodes.
629651 is the working node. I’ve created it on a Linode server with Debian 12. I can dial in from DVSM either with or without WT mode enabled.
629650 is the problem node. It was created on a Vultr server also with Debian 12. Dialing in with either WT mode enabled or disabled always fails. Sometimes I get a Calltoken failure. I’ve looked at /var/asterisk/messages.log, but it’s not updated on each call attempt and the data is vague. I’d really like to get better incoming call logging if possible.
Both nodes work with allmon3. The Linode (working) node has no firewall at the moment. The Vultr node (non-working) has a firewall but it’s disabled.
I’m quite frustrated trying figure out why the Vultr node is failing at incoming calls. I don’t want to choose a cloud provider based on which one is working.
All of my registration has been through DVSM. I wasn’t aware of another method. 629651 has been registered for a few days now, but I’m really not sure how it occurred. I am familiar with asl-menu and comfy using the terminal. And I’m starting learn about the different conf files.
Note I also use RepeaterPhone on my iPhone and iPad. 629651 is the only node working there.
Please tell me more about the distributed ‘node list’. I see it’s an option in asl-menu, but I’ve ignored it so far.
Please keep your descriptions down to only that which is relevant to the issue at hand or you confuse it.
I would go back to the NNX instructions before you do anything and make sure you have set it up correctly.
Perhaps you have missed converting the node number in the dialplan somewhere.
Type error etc.
but the nodelist is in /var/lib/asterisk/
So you can view it yourself to see when it has corrected.
It has all the connection data for all registered nodes.
Without being in the list, you can not connect to it. It don’t know how.
These are peer to peer connections. ASL does not make the connection for you, just manage the connection data through registrations.
If you have decided http registration does not work for you, you can revert back to iax registration. See the manual.
Bottom line, I have no clue how I registered the working one. I don’t know anything about http vs iax registration.
Also I don’t see anything at /var/lib/asterisk other than astdb.sqlite3 which I can’t open w/o downloading to my PC. So that leaves me blind about viewing the nodelist.
The dialplan is how asterisk routes the calls and is the file extensions.conf.
This tells the system how to route calls.
It’s not our term, it’s asterisk’s.
That is the distributed file.
It should contain all registered nodes being hundreds of listings within.
Granted I don’t know a lot of the terminology. So let’s get back to my issue. You’re not seeing 629650 in your distributed node list. That threw me off as I was looking for a list in the cloud. The question is why don’t you have that node in your local node list? Why doesn’t 629650 receive calls?
I currently have 4 NNX nodes: 629650, 629651, 629652, & 629653. And each node shows all 4 of these nodes in their respective rpt_extnodes file.
As to passing IP traffic, I don’t know if there’s something you need to configure with Vultr to enable traffic to pass on that port (i.e. this may not be a firewall issue on your server but, instead, a configuration issue with the VM).
You don’t need a bindaddress because by default it will listen on all IPs which is the usual desired case.
I see node 629650 as registered to 140.82.22.46. That’s a Vultr IP space so I’ll assume that’s you. I tried to connect to your node and got the standard “Auto-congesting call due to slow response” error which is Asterisk-speak for “Asterisk isn’t accessible and/or is ignoring me”. To do some debugging:
In /etc/asterisk/logger.conf comment out the line console => that does NOT have the word “debug” in it and uncomment the one that does.
Restart asterisk with systemctl restart asterisk
Go into asterisk with sudo asterisk -r
Run core set debug 4 app_rpt.so
Try to connect to 629650 from another node and watch the output. You should see something like:
[2024-10-31 18:28:32.700] DEBUG[2002452][C-00000059]: app_rpt/rpt_config.c:531 node_lookup: Resolved by internal: node 460181 to radio@172.17.16.60:4569/460181,NONE
[2024-10-31 18:28:32.700] DEBUG[2002452][C-00000059]: app_rpt/rpt_bridging.c:308 __rpt_request_pseudo: Requested channel DAHDI/pseudo-331462321
[2024-10-31 18:28:32.700] DEBUG[2002452][C-00000059]: app_rpt/rpt_call.c:32 rpt_disable_cdr: No CDR present on DAHDI/pseudo-331462321
[2024-10-31 18:28:32.700] DEBUG[2002452][C-00000059]: app_rpt/rpt_bridging.c:374 dahdi_conf_add: Channel DAHDI/pseudo-331462321 joining conference 1022
[2024-10-31 18:28:32.788] DEBUG[2002452][C-00000059]: app_rpt.c:6766 rpt_exec: Stopped PBX on IAX2/172.17.16.60:4569-11055
That’s obviously a normal connection. The output may give you a hint as to your problem.
It took me a few tries to get debug output in the console. I commented out the line without debug. But there were other lines with debug already commented out, which I un-commented.