Aswath lit me up for saying IAX doesn’t suffer from the problems SIP does when traversing NATs. He basically wrote that I mischaracterized IAX by saying it’s immune to NAT problems. Well, I have respect for Aswath, as I’ve read his blog for years now, and the guy knows his stuff. So when he says I’m innacurate it makes me perk up.
Anyway, the point I was trying to make is, more precisely, that port-forwarding in particular doesn’t break IAX connections the way it breaks SIP connections. Aswath writes:
If so, then SIP could also decide to use a standard UDP port for media and realize the same benefit. Consider the case of an end-point that is behind a NAT.
Not true, Aswath. For one, it is NOT possible with SIP to use the same port for media all the time, since SIP uses RTP (while IAX has its own buil-in payload protocol), and RTP by definition must be set up by a signaling protocol such as SIP, MEGACO, or H.323. Protocol interop requires that RTP run on the port specified at call-setup during capabilities negotiation stage in its various forms on each signaling protocol.
For two, even if you could get all endpoints to use the same socket address for all signalling connections and media connections, SIP still doesn’t advertisig the correct socket address within its headers in a NAT scenario. More specifically: SIP headers, created by VoIP endpoints like phones and servers, include the local (not NATted) socket addresses that the responding endpoints will use to create a UDP connection back to an advertised socket at the calling host prior to the beginning of a call. So, even when attempting to port-forward SIP’s port (5060/5061), or RTP’s payload ports, the protocol simply breaks. Not because there are multiple ports, but because the protocol itself requires the use of non-NATted socket addresses in its headers in order to advertise communication pathways.
IAX simply doesn’t have this problem because the protocol doesn’t carry socket addresses to create connections back to the calling endpoint using a different socket. Rao does clarify his position by stating that the ICE traversal framework is his basis for his statement that I’m not giving the full story about IAX (because I didn’t mention direct call paths as a feature of IAX2, something just about nobody needs). But, on the streets, and especially on the SMB prem, nobody’s relying on ICE or worried about adherance, and everybody’s using inward NAT, port-forwarding, and socket translation. Seriously, ICE may be elegent but isn’t required to make IAX work in both directions through a NAT device. IAX simply works better than SIP when NAT techniques are used. Indeed, SIP doesn’t work at all with NAT (in either direction) unless application proxies are in place (STUN, a SIP media gateway, or something of the ilk).
Now, on Aswath’s point about direct call paths with IAX and SIP (which you can read about in my book Switching to VoIP), let’s face it. The only people using IAX are Asterisk users. Period. You won’t find Asterisk support on a Cisco or Avaya device. The bulk of Asterisk installations are campus-area in nature and fewer than 500 users per server. There’s literally no need to use direct call paths in the vast majority of these installs because IAX imposes little overhead on a modern server, even with dozens of simultaneous calls. In most environments where an Asterisk server would have a high enough call load to require the use of direct call paths a la CPO, you’re talking call center, you’re talking call recording, barging, conferencing, etc. The needs of a large environment necessitate centralized (ie server-proxied) call paths, making Asterisk users that much LESS likely to touch direct call paths.
So if the only people running IAX are Asterisk people, and Asterisk servers almost never experience a bottleneck requiring the use of direct call paths, seriously, who cares about ICE?
Anyway, Aswath, I love your blog, keep it coming. You should post more often! Just remember there’s more to life than protocol purity and adherance. There’s also what the street demands: practicality.
