Jun 02, 2011

Testing Devices That Handle Inter-Asterisk eXchange, Version 2 (IAX2) Protocol

by Eric Reeves

Inter-Asterisk eXchange (IAX) is a Voice-over-Internet Protocol (VoIP) protocol used by Asterisk PBX systems. Its uses include communication between Asterisk PBXs, as well signaling and media for VoIP calls between IAX clients. BreakingPoint’s latest ATI update includes support for IAX version 2, including pre-configured application traffic mixes for registration and IAX media calls. (Technically, this protocol is “IAX2,” but version 1 is deprecated in favor of this one, so we will call it simply “IAX.”) A BreakingPoint customer asked us to add coverage for IAX so they could use it to test their own products. Besides meeting that specific customer need, addition of this protocol lets BreakingPoint customers put IAX to use in testing content-aware devices that handle IAX traffic. Support for this protocol adds to our growing list of VoIP protocols, including SIP, H.323, H.248, BICC, and SCCP [PDF links].

While IAX may not be as well-known as SIP, H.323, and SCCP, there are some aspects of its design that may be advantageous in certain network topologies. One such characteristic is that IAX operates both signaling and media over a single UDP port (4569). Since media occurs in-band, NAT and firewall traversal is less complicated. Additionally, since IAX uses its own framing for media, the size per media packet can be reduced when compared to the more frequently used RTP/RTCP protocols. This is especially true when taking advantage of IAX trunking, which carries multiple media streams in a single IAX frame. Finally, IAX is binary-encoded. Not unlike protocols in the H.323 suite, each IAX frame may include information elements that further describe the message they accompany. What follows is a brief overview of the protocol, including its encoding scheme and a basic call flow.

The Structure of IAX Traffic

The purpose of a full-size IAX frame is to carry both signaling and media. Shown below, the frame structure provides call identification (Source / Destination Call Number), sequencing (OSeqno, ISeqno), and latency detection (time-stamp). The “Frame Type” and “Subclass” fields are used to classify the type of message and give clues about what data may occur after the header. Here is a diagram representing a full IAX frame:

Signaling messages will often contain a sequence of information elements (IEs) used to give additional details about the message. For example, an “IAX NEW” message will contain IEs that describe the calling party, the call recipient, and information about the network on which this call resides. IEs are type-length-value (TLV) encoded, meaning that a fixed number of bits are reserved to represent the type and size of the information expressed by the element. Each IE has its own identifier.

Miniature IAX frames are used solely to carry media streams on IAX calls that have already been established. In an IAX media exchange, the first chunk of the media stream occurs in a full frame, denoting the encoding of the media (for example, G.729, G.711 mu-law, or G.711 a-law). Subsequent frames need only reference the call identifier to inform the IAX peer of the payload. Here is a diagram of a mini IAX frame:

The flow for a call between two IAX peers is not unlike that of a SIP or H.323 call. The call establishment phase includes authentication (if applicable), media codec negotiation, and then an initial media exchange. Finally, a quick teardown phase ends the call.

IAX is described by RFC 5456 and RFC 5457. These RFCs, however, are published as “Informational,” meaning that they merely serve as references rather than proposing a standard. While published somewhat recently (February 2010), these documents are already becoming out of date. Recent versions of Asterisk servers (as well as IAX clients) use message types and information elements that are not in the RFC. When new information elements and frame types are introduced, an identifier must be allocated for it. Information about these new elements and message types may be found in the Asterisk source code, which is freely available online. Also, protocol analyzers such as Wireshark may shed insight into the meaning of an IE or frame that is not documented in the RFC. Here is a screen shot of Wireshark’s IAX dissector in action:

As previously mentioned, BreakingPoint’s latest ATI update includes support for the IAX protocol. We’ve included a number of pre-configured application traffic mixes (which we call Super Flows) for use in the Application Simulator component: IAX media calls (with and without authentication), IAX registration, and IAX registration release. In addition, we’ve added three Super Flows for use in the Client Simulator component: two IAX media call Super Flows (authenticated and guest) and one IAX registration Super Flow. Our implementation also includes support for a vast majority of the frame types in the “Control” and “IAX” categories, giving you the flexibility to create your own effective custom Super Flows. In Part 2 of this series, I will demonstrate our implementation by using an IAX Client Simulator test against an Asterisk PBX.

Tags: