The general perception is that unlike SIP, IAX does not suffer from NAT traversal problem. Claims along this line are routinely made and every time I encounter such a claim I will scratch my head and will do some fact checking to confirm my understanding is correct. The latest example of such a claim was recently made by Ted Wallingford as part of his review of a SOHO PBX from Jazinga. It is informative to analyze how IAX handles (“does not suffer” is not a correct characterization) NAT traversal. This is topical because Adobe has announced that they are planning to support UDP based media streaming in Flash 10 and I suspect that they are using the same methodology that IAX uses. In this post I argue that either of the schemes falls within ICE framework.
IAX specification itself claims that NAT traversal is much simpler because “IAX also uses the same UDP port for both its signaling and media messages, and because all communications regarding a call are done over the same point-to-point path”. This can not be the full explanation. 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. Even though that end-point will use the well-known port 4569 for IAX, there is no guarantee that NAT will allocate the same port number for external communication. So how will an external end-point reach this end-point? It is clear that such end-points need to be aided by an external peer, otherwise known as “server”. Since this server will handle the media packets as well, it is essentially acting like a TURN server. Involving a TURN server for the duration of the call is inefficient. Recognizing this, IAX specification has developed “Call Path Optimization” (Section 6.5)procedure. According to this procedure, the IAX server will request the two end-points to exchange media directly between themselves by providing the IP addresses of the end-points. Since the server is providing the IP addresses, they are “server reflexive addresses” that ICE uses. We know that there are instances when these server reflexive addresses will not be reachable as in the case when the two end-points are behind the same NAT. Thus the procedure specified in the IAX specification is sub-optimal to IAX. Of course they can update their procedure to conform to ICE. But the point remains that IAX addresses NAT traversal problem not because it uses the same UDP port for media and signaling, but because it uses a server that can act as a TURN server and that server facilitates an ICE-like procedure.
From the description of Flash 10, it is clear that they are also doing a similar thing. But it is not clear whether they are following the full ICE framework or a subset. It is worthing looking into it once we have additional information.
Posted by aswath at July 5, 2008 06:11 PM
While I'm not expert on IAX2 I think I understand something of its appeal. All signaling and media is on one port. This happens regardless of use as trunk or line between Asterisk and an IAX capable handset.
SIP, OTOH allows the media to pass over ports designated by the end point. Signaling is usually on a separate port. If you add calls to an end point in an on-phone conference you inherently use more ports.
The fact that it's dynamic makes it difficult to establish simple port forwarding rules in a router or firewall when you have several SIP end points connected to a remote host.
With IAX2, which I have done myself in the past, port forwarding literally may not be required. The phone registering and the keep-alive mechanism (qualify=x) will sustain the connection. All signaling and media is on that same port, regardless of the call circumstances.
It tends to make things simple. That said, IAX2 has had its share of problems over time. And IAX2 capable end-points are not plentiful.
Posted by: Michael Graves at July 5, 2008 09:28 PMHow would port forwarding be sufficient if you are planning to have multiple IAX clients behind a single NAT? If you are using the registration and keep alive signals to maintain the connection, then effectively you are using the IAX server as a TURN server. The point of ICE and section 6.5 of IAX spec is to avoid the use of TURN as much as possible. The question then is why not IAX explicitly state that they are adapting ICE framework instead of claiming that IAX does not have NAT traversal problem.
Posted by: Aswath Rao at July 5, 2008 10:40 PMAgain, I can only speak of my own experience using IAX2. Because only one port is involved in any case PAT is practical and possible in supporting multiple clients. I've never taken WireShark and done a traffic analysis of IAX2, but I have had multiple clients behind NAT without requiring any specific forwarding on the router.
Could there also be a timing issue here. I suspect the early implementation of IAX pre-dates ICE/TURN. My first IAX experience was in late 2002, and online examples were already well in place by then.
Posted by: Michael Graves at July 6, 2008 03:19 PMHi,
Henry Sinnreich is heading Adobe's efforts in Voice communications. He also plays an important role in p2psip working group in IETF. I think they are using ICE as the standard itself in Flash.
Peter
Posted by: Peter at July 7, 2008 10:48 PM