 |
|
|
|
|
The mechanism for carrying a VoIP connection generally involves a series of signaling transactions between the endpoints (and gateways in between), culminating in two persistent media streams (one for each direction) that carry the actual conversation. There are several protocols in existence to handle this. In this section, we will discuss some of those that are important to VoIP in general and to Asterisk specifically.
If you claim to be one of the folks in-the-know when it comes to Asterisk, your test will come when you have to pronounce the name of this protocol. It would seem that you should say "eye-ay-ex", but this hardly rolls off the tongue very well[109]. Fortunately, the proper pronounciation is in fact "eeks[110]." IAX[111] is an open protocol, meaning that anyone can download and develop for it, but it is not yet a standard of any kind. It is expected that IAX2 will become an IETF protocol soon. IAX2 is currently in draft status with the IETF, and it is popularly expected to become an official protocol in a few years time.
In Asterisk, IAX is supported by the chan_iax2.so module.
The IAX protocol was developed by Digium for the purpose of communicating with other Asterisk servers (hence "the Inter-Asterisk eXchange protocol"). It is very important to note that IAX is not at all limited to Asterisk. The standard is open for anyone to use, and it is supported by many other open source telecom projects, as well as by several hardware vendors. IAX is a transport protocol (much like SIP) that uses a single UDP port (4569) for both the channel signaling and media streams. As discussed below, this makes it easier to mange when behind NAT'ed firewalls.
IAX also has the unique ability to trunk multiple sessions into one dataflow, which can be a tremendous bandwidth advantage when sending a lot of simultaneous channels to a remote box. Trunking allows multiple media streams to be represented with a single datagram header, to lower the overhead associated with individual channels. This helps to lower latency and reduce the processing power and bandwidth required, allowing the protocol to scale much more easily with a large number of active channels between endpoints. If you have a large quantity of IP calls to pass between two endpoints, you should take a close look at IAX trunking.
Since IAX was optimized for voice, it has received some criticism for not better supporting video—but in fact, IAX holds the potential to carry pretty much any media stream desired. Because it is an open protocol, future media types are certain to be incorporated as the community desires them.
IAX includes the ability to authenticate in three ways: plain
text, MD5 hashing, and RSA key exchange. This, of course, does nothing
to encrypt the media path or headers between endpoints. Many solutions
include using a Virtual Private Network (VPN) appliance or software to
encrypt the stream in another layer of technology, which requires the
endpoints to pre-establish a method of having these tunnels configured
and operational. However, IAX is now also able to encrypt the streams
between endpoints with dynamic key exchange at call setup (using the
configuration option encryption=aes128), allowing
the use of automatic key rollover.
The IAX2 protocol was deliberately designed to work from behind devices performing NAT. The use of a single UDP port for both signaling and transmission of media also keeps the number of holes required in your firewall to a minimum. These considerations have helped make IAX one of the easiest protocols (if not the easiest) to implement in secure networks.
[109] It sounds like the name of a Dutch football team.
[110] Go ahead. Say it. Now that sounds much better, doesn't it?
[111] Officially, the current version is IAX2, but all support for IAX1 has been dropped, so whether you say "IAX" or "IAX2," it is expected that you are talking about the Version 2.
|
|
 |
|
 |