Just posted this for better understanding and trouble shooting on your own.
The list has been updated to now 7 items.
1- Lacks connection information.
Your connection data is put on a list of registered nodes.
Distributed to registered nodes.
Are you registered ? Are you in the nodes list located /var/lib/asterisk/rpt_extnodes
Does that connection info look correct in the file ? Mainly IP and IAX Port
If you are not registering and you are on a GSM Hotspot (AT&T/T-Mo) AND using asl3,
You might want to revert to IAX based registration (see asl3 manual)
Your connection target may have this issue.
2 - Do you have a path to the connection ?
The 'dialplan' (as asterisk names it) is the file extensions.conf
It contains how a incoming call is handled (or not)
Private nodes need routing for they are not part of the allstar system of registered nodes.
The same apply to sip and other iax connections including iaxrpt.
You qualify the connection in iax.conf or sip.conf but when you dial anything, it is extensions.conf that routes and/or connects it to something else.
3- Lack of authorization
Passwords and the like. Easily verifiable if you take the time.
Mainly when you fail to register. But includes iaxrpt or any iax/sip connection.
Allmon and other management interfaces are HTTP connections also have passwords to deal with in both apache (web access) and the asterisk manager interface (AMI).
4- A connection conflict.
Your intended target also has a private node connection as the same number.
The software prevents 'looping' of connections. It will be rejected.
But this includes if you and your target are both also connected to a particular public node.
Rejected because you are already connected, just not directly.
It can be helpful to look at a bubble map to visualize this.
You can look at the targets connections with the results of this @ links
https://stats.allstarlink.org/api/stats/<node#>
So you can look for a conflict yourself.
5- IAX Port
On inbound connection failure and your server is behind a router, the port must be forwarded to the correct IP inside your network. A improper port forwarding does not change your outbound connection ability.
Also make sure the port reported in iax.conf bindport= is corect
And is also the same port reported in the [nodes] section of rpt.conf for each node on that server if stated. (default internal port not required here but if you put it in, you can keep it straight in your head when dealing with many servers)
6-. Servers behind the same NAT
If you have 2 servers behind the same NAT / router / WAN IP
There are some special considerations to be made for those connections between nodes on those servers..
This document will help.
Basically, you must describe each of those nodes in [nodes] (rpt.conf)
with the local address and port as seen from that servers perspective.
Just like they were a private node connection. Because the data from registration in the files tells it to use the wan ip to make the connection, and that will never work.
Just don't forget to change this if you move one of them 'outside your NAT'.
The software first checks the [nodes] section for connection info,
then the registration database.
7-. Remote Base designation
. If you look at this registration line from a rptextnodes file
/var/lib/asterisk/rptextnodes
2586=radio@108.239.105.244:4473/2586,108.239.105.244,y
We see it has been designated as a remote base.
That designation changes one important thing.
It only allows for a single iax connection.
So you might look in your registration file list at you or your target for it.
See what it is registered as and in your [nodes] section.
A private node connection counts as a connection just the same.
n,no,none are the proper designations when it is not a remote base.
in your [nodes] section of rpt.conf
29261 = radio@192.168.1.223:4569/29261,NONE
You do not have to designate a remote base as such. But it's a good idea when it's a public accessible node. You can make it on a private node to limit it's availability.
===
+++
FAT FINGER ERRORS are sometimes hard to spot. Let some other eyes look at it.
Always test a failed connection against other nodes and see if it is widespread / all nodes, private nodes or just one node or on a particular server. That will help you localize the issue.
Do not automatically assume the problem with the connection is on your end and tinker with your settings unless you have valid idea of a incorrect setting.
Remember to change back 'test' modifications. It can keep you from finding a resolution.
If you are going to post a issue you are having, at least test it with connection attempt of varying types, like outside your NAT or located on a different server, not just a different node number. And bring those details forward to the group for faster resolution.
If this guide helps you, give it a like so I know it's doing some good.
Encouragement for appending with time ?
If you think I missed something, note it in a reply.
I have been appending this for a while now.