Asking this question hoping for some good thoughts back.
Recently we went through an initiative to upgrade all of our FreePBX boxes to the latest supported versions and transfer our trunks to Encrypted PJSIP. We then also made sure that each extension was making encrypted connections to each server.
It recently dawned on me that IAX2 which is used to communicate between our servers (call one system from another) likely doesn’t have the same encryption level that we implemented every where else via PJSIP
What is your experience? Is IAX2 still the best way to connect internal FreePBX boxes together or should we figure out how to move these connections to PJSIP?
No, IAX it’s not the best way to connect two Freepbx boxes together imo as IAX is software that’s no longer supported and hasn’t received any changes, updates or bug fixes in years.
If you go with current pjsip you are on a good path.
Use IAX if you want, it’s probably gonna work just fine for you, it didn’t for me though.
I was using it initially to connect Asterisk over the internet but suddenly started to run into show stopping problems that I couldn’t fix. That’s where I found that iax has poor debugging facilities with logs that are hard to read and few people understand them.
Then I thought why bother with long end of life software anyway and went to sip and won’t be going back.
The only real advantage of IAX is that you have signaling and media over the same port which makes NAT traversal easier.
The answer to this is a plain and simple No. You can hang on to the one reason people went with IAX/IAX2 back in the day, NAT. Honestly this is not longer the issue that it was 15 years ago. Outside of the fact that routers have improved their NAT capabilities (most at least), the rise of IPv6 being used and the fact that numerous Telecom/LECs/ISPs are now doing dedicated peering/connections to end users. IAX was created during a time when SIP, H.323 and MGCP were still fighting to be the “prime standard”. That time has passed, we known who won that. Since then everyone has adjusted accordingly.
Now take all that off the table and just look at IAX2 over the 4-5 years. Reviewing the change log you’ll see Digium’s activity on IAX2 come to an almost sudden stop around the end of 2015 because it went to Extended support by then. That means Asterisk developers are no longer handling those issues and the community/contributor’s are where those issues are handled now.
2016 saw only one change for IAX and that was to remove plaintext auth support as it’s deprecated and was slated to be removed in Asterisk 16 (which I think it was).
2017 saw four issues dealt with and 50% of those was dealing with Netsock being deprecated and removed from the Asterisk core but since IAX2 is the only thing still requiring it the changes where to move Netsock into IAX2 only.
2018 saw a single issue handled.
2019 saw zero issues handled for IAX2. In fact the only mention of IAX2 in the 2019 changelogs is from Matt Jordan in regards to a new metric that was added for PJSIP and might work with Chan_SIP and IAX2 but never tested (because they are deprecated).
(And why are you still using IAX2 and [CHAN_]SIP? It’s 2019 folks. Get with the program.)
At this point the vendor who created the protocol is wondering why people are still using it and the changelog is showing that less and less are contributing to the maintenance of the protocol. So Matt’s question is valid, why would you use IAX2 in 2019? It’s just not wise.
Just remember that Asterisk, FreeSWTICH and 3CX (I believe) are the major players that support IAX2. While they have a decent share of the business PBX market they don’t own the space and well VoIP providers that support IAX2 are considered niche providers for a niche market.
The question is loaded. “Is IAX2 still the best trunk type…” Was it ever? Thinking back ten years or more, I do remember people mentioning IAX2 from time to time, but never really for its own merit, only that it’s not SIP, so if you’re struggling to get SIP to work for some reason, try IAX2.
@xrobau tweeted at me earlier in the week, “IAX2 is great for places that have a restrictive firewall that insists on screwing with SIP traffic. I have a handful of customers that literally can’t use SIP without explicit mangling at both ends to avoid sip unHelpers.” OK, but if you’ve got packet inspection ruining things and you can’t avoid it, enable TLS. Problem solved.
There will be die hard IAX2 fans out there just as there are hard core Skinny fans (looking at you, @cynjut) and UNISTIM fans (no, just kidding, there aren’t any UNISTIM fans). Can’t dissuade them. But if you’re coming at it fresh, IAX2 probably isn’t the way to start.
I’m not so much a hard core fan of either; I’m just lazy as crap.
IAX2 is easy for the thing that it’s easy for - like interconnecting two Asterisk PBX systems. Other uses of IAX2 are “ok” for things that are there, like Zoiper phones. It gets around some of the hard bits that other equipment make harder than they need to be.
As far as Skinny goes - the 7940 and 7960 phones can be loaded with a deliberately crippled SIP load and “used” (kind of) to connect to Asterisk and FreePBX. Setting up Chan-SCCP-B takes an hour (well, this week there’s a source code issue that needs some TLC, but I’m working on it) and getting the phones going is as simple as filling out a credit card app. With PhantomVI’s Manager (which this week is also having a source code problem, and I’m working on that too) you can manage the phones through the FreePBX GUI.
I’m not a Luddite, I’m just opposed to doing things the hard way. I have the tools to do these particular things in an easier way than people that think “old and working isn’t as good as new and really hard to get right, so let’s try the new way.” I’ll continue to recommend them until they stop working or doing it the new way is as easy as the old way.
No offense meant Dave; I was just joking around. With skinny, there’s an obvious use case–phones that only really work properly on that protocol. Perhaps if folks gave PJSIP inter-pbx trunking a try they’d find that the new way is as easy as the old way, and far better supported, too.
I know - I was pushing back “just a little”. As long as SIP is SIP, there are going to be interconnectivity challenges that face “casual” users. As we, as a community, get better at explaining how to do what they want to do and participate in the new Sangoma Documentation Project, things like getting PJ-SIP interconnects working through a series of firewalls, many of which we don’t have control over, will become easier.
I think @billsimon posted a picture of a point-to-point PJ-SIP setup at PJSIP trunk between servers that should work fine if you are really doing what you say you’re doing. IP Authentication is the way to go in this case.