Inter-Asterisk eXchange

IAX is the Inter-Asterisk eXchange protocol native to Asterisk PBX and supported by a number of other softswitches and PBXs. It is used to enable VoIP connections between servers as well as client-server communication.

IAX now most commonly refers to IAX2, the second version of the IAX protocol. The original IAX protocol has been deprecated almost universally in favor of IAX2.

Basic properties

IAX2 is a VoIP protocol that usually carries both signalling and data on the same path. The commands and parameters are sent binary and any extension has to have a new numeric code allocated. Historically this was modeled after the internal data passing of Asterisk modules Fact|date=August 2007.

IAX2 uses a single UDP data stream (usually on port 4569) to communicate between endpoints, both for signaling and data. The voice traffic is transmitted in-band, making IAX2 easier to firewall and more likely to work behind network address translation. This is in contrast to SIP, H.323 and Media Gateway Control Protocol which are using an out-of-band RTP stream to deliver information.

IAX2 supports trunking, multiplexing channels over a single link. When trunking, data from multiple calls are merged into a single set of packets, meaning that one IP datagram can deliver information for more than one call, reducing the effective IP overhead without creating additional latency. This is a big advantage for VoIP users, where IP headers are large percentage of the bandwidth usage.

The creation of IAX

The IAX2 Protocol or Inter-Asterisk Exchange Protocol was created by Mark Spencer for Asterisk for VoIP signalling. The protocol sets up internal sessions and these sessions can use whichever codec they want for voice transmission. The Inter-Asterisk Exchange protocol essentially provides control and transmission of streaming media over IP (Internet Protocol) networks. IAX is extremely flexible and can be used with any type of streaming media including video, however it is mainly designed for control of IP voice calls.

The goals of IAX

The primary goals for IAX were to minimize bandwidth used in media transmissions, with particular attention drawn to control and individual voice calls, and to provide native support for NAT (Network Address Translation) transparency. Another goal is to be easy to use behind firewalls.

The basic structure of IAX is that it multiplexes signaling and multiple media streams over a single UDP (user datagram protocol) stream between two computers. IAX is a binary protocol, designed to reduce overhead especially in regard to voice streams. Bandwidth efficiency in some places is sacrificed in exchange for bandwidth efficiency for individual voice calls. One UDP stream is easier to setup for users that are behind a firewall.

An additional benefit to having a single stream is the added security, which can be implemented very easily. Furthermore, in countries where ISPs are filtering the VoIP, IAX can be easily hidden.

IAX drawbacks

As stated previously, IAX2 uses 1 path for both signaling and media. This leads to the following issues:
* According to an email [ [http://lists.digium.com/pipermail/asterisk-dev/2004-January/002874.html [Asterisk-Dev IAX2 Transfer Message Sequence? ] ] by Mark Spencer, when you use a centralized server and transfer to a media gateway for call completion, the centralized server loses track of the phone call. As a result, the centralized server does not know when the call terminated and cannot provide billing information on that call. Asterisk 1.4 includes support for a new IAX2 message, TXMEDIA, which allows transferring only the media to flow between two other endpoints so that the server may still receive signaling and not media.
* As per ISS security advisory [ [http://www.iss.net/threats/228.html Asterisk IAX2 Protocol Denial of Service Attack] ] an attacker (or fairly busy network, i.e. enterprise-level) can use up all the available sessions, in which case no future sessions can be assigned until current ones expire or the session ends and they are removed. Sessions are used for call requests, authentication requests, basically any time a unique id is required for a series of related packets. Version 1.2.10 (and above) of Asterisk mitigates the attack by setting the maximum amount of unauthenticated requests made for a single username, but it is still possible to fill up this session queue if many usernames are used and there are sufficiently many calls.
* As Per Jeremy McNamara and Blake Cornell [ [http://www.jeremy-mcnamara.com/2008/07/23/iax-poke-resource-exhaustion/ IAX Poke Resource Exhaustion] ] - By flooding an Asterisk server with IAX2 ‘POKE’ requests, an attacker may eat up all call numbers associated with the IAX2 protocol on an Asterisk server and prevent other IAX2 calls from getting through. Due to the nature of the protocol, IAX2 POKE calls will expect an ACK packet in response to the PONG packet sent in response to the POKE. While waiting for this ACK packet, this dialog consumes an IAX2 call number, as the ACK packet must contain the same call number as was allocated and sent in the PONG. Exploit code [ [http://www.securityscraper.com/pingpoke/iaxPingPoker.txt IAXPingPoker] ] was released at The Last Hope. Shortly after a fix was released not reserving an AIX call number any more [ [http://securiteam.com/unixfocus/5HP0P15OUK.html Asterisk IAX 'POKE' Resource Exhaustion] ]
* Some implementations of IAX2 do not require a handshake when initiating a call. If a system has any accounts with no password (such as the default account ‘guest’, provided so that others can call via IAX without having an account) then the media from that call can be used in a DoS attack against anyone that that system can route packets to, by saturating the victim’s network. A security advisory [ [http://www.iss.net/threats/229.html IAX2 Protocol Denial of Service Amplification Attack] ] by ISS has been issued on this problem. In Asterisk, versions 1.2.20, 1.4.5 and later require a three way handshake before beginning to send media. This vulnerability can be avoided in earlier versions of Asterisk by not allowing any unauthenticated calls. It is also worth noting that this same problem exists with SIP, but in a worse way. The protocol is defined in such a way that directing media streams at arbitrary endpoints is a feature of the protocol, and no falsifying of packets is required to make this happen.
* Due to the lack of a generic extension mechanism, every new feature has to be added in the standard which makes it less flexibile than SIP or MGCP.

ee also

*SIP connection (aka SIP trunk)

References

External links

* [https://datatracker.ietf.org/drafts/draft-guy-iax/ "IAX: Inter-Asterisk eXchange Version 2"] protocol specification
* [http://eu.wiley.com/WileyCDA/WileyTitle/productCd-0470770724.html "Inter-Asterisk Exchange (IAX): Deployment Scenarios in SIP-Enabled Networks"] A book which describes the IAX protocol and its associated objects and operations in order to offer conversational services. Issues related to NAT traversal, support of IPv6, IPv4-IPv6 interworking, deployment in P2P context, etc.
* [http://www3.ietf.org/proceedings/06jul/IDs/draft-ietf-enum-iax-00.txt IANA Registration for IAX Enumservice]
* [http://www.voip-info.org/wiki-Asterisk+firewall+rules Firewall Rules for IAX2 and SIP] (voip-info.org)
* [http://www.icesi.edu.co/blogs_estudiantes/asterisk/ Project implementation asterisk-access router]