week we began an investigation into ways to deal with the many problems
inherent in getting SIP (Session Initiation Protocol) through NAT (Network Address
Translation) firewalls. There are two basic strategies: spend your life fighting
with SIPwith its attendant hair loss and unhealthy blood pressure levelsor
sidestep the problem entirely by using the IAX (Inter-Asterisk Exchange) protocol.
So we're looking at the pros and cons of using IAX. We've already looked at
some good IAX softphones; now let's see what the hardphone world has to offer.
That's right, nothing. Okay, there is one that I found: the Atcom AT-530. It gets decent user reviews, and it is priced under $100. It supports both SIP and IAX. If you can find a local vendor it is worth a try. Or you can order it from the manufacturer in China.
Bah, humbug IAX
I contacted a number of commercial vendors of both soft and hardphones, and asked about their plans to include IAX support in their products. IP phones already support rafts of codecs and features; some even support multiple protocols (mainly SIP and H.323), so what's the problem with adding one more? For some reason this is a touchy subject; the ones who actually deigned to speak to me wouldn't say anything other than "We have no plans to support IAX." Ordinarily they're all happy when I call. So naturally I'm suspecting all kinds of crazy things: bribery from a shadowy anti-IAX cabal, Mark Spencer got caught igniting dog doo on their doorsteps, or maybe everyone is having a bad day all at the exact same time, and I shouldn't take it personally. Or it's a cunning plot to prop up the lucrative SIP proxy market.
I know there is substantial customer demand for thiscustomer forums are full of requests for IAX support, and they get the same curt "you go away now" responses. So if any of you fine readers have inside knowledge as to why this silly state of affairs existsimagine, customers requesting useful and valuable features! Such audacity!I would love to hear about it.
IAX service providers
There are quite a few of these; visit VoIP Service Providers for starters. These come in a variety of flavors. Some are intended for individuals, so you only need an IP phone that supports IAX. Some support BYOD, or Bring Your Own Device. If you're running your own Asterisk server and don't want to hassle with doing your own PSTN termination, a service provider that does this for you might be a nice cost-effective way to go. Phone number portability is still iffy; but you may be able to use your existing phone numbers, so always ask.
Analog IAX adapters
These are worth considering for remote clients that connect to your Asterisk server over the Internet, such as road warriors, small branch offices where you don't want to hassle with running an Asterisk server, and for setting up your far-flung relatives to talk to you for free. Yes, you're stuck with using gormy old-fashioned analog telephones, instead of shiny new IP phones, but is that so bad? Well, yes it is, except for your tech-inexperienced users it's probably better.
Single-line IAX adapters like Digium's IAXy are popular with travelers.
The Atcom AG188 ATA adapter supports both SIP and IAX, and it even includes a PSTN pass-through.
The GlobetelX IAD-200X is a nice 2-port box cram-full of useful features: NAT router, DHCP server, VLAN, QoS, and more. It's rather a bear to configure, though, even with a Web configuration interface. But you get a lot of features for the money.
Putting it all together
So let's review where/how all these pieces fit together. In an ideal world, you would have nice efficient IAX trunks everywhere, serving SIP and IAX endpoints. There would be no cursing at the party-pooping NAT, merely happy people talking and carrying on without a care. So anyone who is running an Asterisk-based server is a potential IAX peer: your branch offices, friends, partners, and customers. You can run all the SIP endpoints behind your Asterisk server that your heart desires, as long as your SIP traffic is escorted through NAT via IAX.
It is true that doing this foils the SIP architecture, which by design separates signaling from the media stream, and allows the media stream to find its own best routes. Unfortunately, in a NAT-dominated Internet, the advantages gained from this flexible routing are lost to all the workarounds required for reliable NAT traversal. Moral: VoIP is still in its infancy, and is therefore messy, as babies always are.