I have one main freepbx system (SIP trunk only) (FreePBX 13.0.192.8) “system A” with an ip of 172.29.122.117
I have deployed a second freepbx system at another site, “system B” has an IP of 172.29.126.6
These two systems are connected via VPNs and can both ping each other.
I’ve tried creating an IAX trunk between the two:
System A:
name=System2
host=172.29.126.6
username=System1
secret=password
type=friend
qualify=yes
context=from-internal
No, don’t be friendly. Use all the passwords and usernames you want, and make them as complex as you can.
Also, why bother with IAX2? SIP is better documented, more portable, and easier to troubleshoot. It’s 2017 and there is almost no reason to be using IAX.
I’ve upgrade both PBXs to the same updated version. Now I see an option for IAX2 trunk on both system.
I’ve rebuilt the trucks with the following:
Name=System2
host=172.29.131.9
username=System1
secret=password
type=friend
context=from-internal
qualify=yes
trunk=yes
You appear to have set up your trunks to point to themselves not the peer/friend you intended, again check your trunks against the “known working configurations”
What it all means that IAX2 in a private network will ALWAYS beat SIP as to efficiency and ease of deployment.
IAX stands for Inter Asterisk eXchange, the 2 for “it’s better” for any tie-lines between Asterisk servers, it IS well documented and for a “private” network, then a minimalist deployment needs then you really don’t need Auth of any form, so for a trunk:-
You really don’t even need the qualify if it is truly a robust local,unroutable network , but if you use it, then any NAT traversal would likely be transparent and you should add an authentication process for your protection if the IP is routable , if so you should NOT use 4569 for obvious reasons (add port=unlikelyforknuckledraggerstofind), bear in mind that the context {[rom-internal] might give more or less exposure than you need.
If you have a shorter and more efficient way with SIP, please post it.
You cited voip-info.org. Not sure what to tell you. None of those sites mean anything whatsoever. The problems IAX2 solve don’t exist. It is not needed, especially in a private network.
Thank you for your opinion, but why do real-world solutions not mean anything?. Many have used it for years without any problems, and yes those problems with SIP’s NAT traversal DO exist, please explain your position more fully, but better yet , offer your SIP solution with your ubiquitous routing solution.
I’ve got stuff to do, but would be happy to reply later. In case someone actually stumbles on this page, though, please realize that IAX2 doesn’t “beat” SIP. It is not inherently better. It does not have some magical interoperability with Asterisk that SIP does not. What the acronym means is not important. You want to be using SIP; if you MUST have IAX2, you’ll know it. The main advantages were important more than a decade ago, but since then NAT traversal and bandwidth have become far less of a problem. I cannot think of a single reason I’d ever recommend anyone use IAX2, except maybe in very niche wireless scenarios.
Again , thank you for opinion, when you are less busy, you should expand and expound, I am pretty sure anyone who has used IAX2 for the last 10+ years will disagree with you though. The magic is in the I , A and X of the protocol, one port for signalling and media,NAT traversal through multiple routers , trunk efficiency and ease of use (you can interpret that as “interoperibilty”, magic or not ) , SIP can’t do any of the above. Again, if you have a more robust SIP solution,. please post it, but please just don’t dive and duck and so waste everyone’s time.
NAT traversal is still a major problem for SIP, will always be and it’s just something SIP sucks at big time and where IAX triumphs.
Just look at the regular posts here on the forum with no audio, one way audio problems, etc.
The solutions like STUN, ICE and whatever people came up with are insufficient workarounds for that big disadvantage.
With that in mind, IAX would theoretically be the preferred protocol in almost every scenario, except for maybe voice service providers who like to run the audio stream through other carriers, but IAX seems to have a few problems as well.
We were running an IAX trunk over the internet between our Asterisk servers and one day it starting failing one way with “Reject, cause code 50”, which we weren’t able to solve.
Then tried SIP instead, which worked and people started telling us how much better the call quality was since we had made a “change”.
People had complained about voice drop outs very often, which we had blamed the network for, but after the switch to SIP, they all went away.
But I don’t have the slightest idea why that would be, just glad it’s better. But there are probably many other users out there for whom IAX works great.
I also found IAX debug gives you very little info to properly troubleshoot.
Despite its advantages, it unfortunately never took off and saw widespread adoption, especially among voice service providers and phone manufacturers.
If that had happened, it would have been a serious competitor to SIP, especially as we would have seen continuous advances in the IAX protocol, which we haven’t.
But who knows what the future will bring, SIP might die out, with the advent of WebRTC.
IAX2 requires both ends to be or at least behave like Asterisk . It does have a problem of ‘choking’ when the concurrency gets into the hundreds so many VSPs like Vitelity stopped supporting it. Cause 50 likely is exposing that problem
It is however an ideal choice for smaller networks, in this case two machines, that it can be setup as a trunk , means the connection is always up so a real ‘tie-line’ unlike SIP which treats each call as a separate one so a lot more overhead.
True the debug is minimal but a reliable
POKE, PONG,ACK
every 60 seconds , if qualify=yes, for each trunk will confirm a) that it is working and b) the IP of the far end Asterisk, there is little else to be gleaned from the trunk apart from increasing ’ tries’ if not connected, endpoint activity is not too bad ina kinda yes/no fashio.
There is of course :-
tcpdump -X -s 0 -vv port 4569
And that can be diagnostic if there is no connectivity that dump should of course be symmetrical as to packets and origination/destination IP
So for me IAX2 between my boxen , SIP for origination and termination of PSTN calls.
Not understanding how to implement NAT properly does not indicate a problem with the protocol. SIP works fine over NAT, so long as you have any idea what you’re doing.
SIP is more work to implement in NAT and more error prone.
IAX is easier to implement in that aspect and that also means “better” in that area.
Many NAT scenarios have to be tweaked to make SIP work, that could otherwise be left untouched with IAX.