Nothing Special   »   [go: up one dir, main page]

Upgrade 3CX to v18 and get it hosted free!
IAX
Author image

The IAX revision 2 protocol was developed by Asterisk team as an alternative to SIP, H.323, etc. when connecting to other devices that support IAX (a limited list at the moment, but growing very rapidly). However, meanwhile, other software like YATE SofaSwitch, FreeSwitch Softswitch and OPAL have added IAX2 support.

  • IAX2 is not the result of a standards group, rather a collaborative, community-based effort (Note: IAX2 is now: RFC 5456)
  • IAX2 uses a single UDP port 4569, and thus works well in NAT environments (the obsolete IAX1 protocol used port 5036). IAX2 uses ONLY one udp port for both control and data traffic. As outlined in point 4 of the IAX versus SIP topic with IAX you will always have audio if the control connection can be established.
  • IAX2 supports PKI-style authentication and trunking.
  • The Asterisk IAX2 driver has a jitter buffer. (The SIP driver doesn’t in 1.2.x, but one has been added in 1.4.x. The IAX2 jitterbuffer is more mature, however.)

The main issue with IAX2 it’s the small number of calls that can be carried over a single trunk – around 300/400 calls.

Trunking

When trunking with IAX2, only the used bandwidth is allocated at all times. Other TDMoIP protocols used for trunking always allocate a certain amount of bandwidth to keep all channels open. IAX trunking allows multiple voice streams to share a single “trunk” to another server, reducing overhead created by IP packets. IAX always sends the DTMF outline (RFC2833), eliminating the confusion often found with SIP.

It should be noted that trunking requires both sides to know each other (i.e. they need to be valid peers). If one side has trunk=yes and the other does not cannot validate the peer, you will get one-way audio. The easiest way to make this work is to use a register line to register to the systems you want to trunk with.

Jitterbuffer

One of the major advantages of IAX2 over SIP is the IAX2 jitterbuffer (in Asterisk 1.2.x and higher). This tends to improve the audio quality noticeably over non-ideal links like ADSL. To enable it, add:

jitterbuffer=yes

to iax.conf. A jitterbuffer was added to the SIP channel in Asterisk 1.4, but it is not as mature as the IAX2 jitterbuffer. Some additional background info is available here: How to Use the New Jitter Buffer in Asterisk

General NAT Issues

One of the other big selling points of IAX2 is the relative ease with which it integrates with NAT, especially compared with nightmare of SIP NAT traversal. IAX2 uses just one UDP port, 4569. That said, there are a few subtle “gotchas” to be aware of:

  • Consistent NAT. Address translation usually involves re-writing the source port, so that the NAT device can keep track of connections. For reliable two-way communications, the same re-writing must always be used. For instance – say your internal Asterisk server sends a registration message (using source and destination ports of 4569) to your IAX provider’s server on the other side of the NAT device. The NAT device will re-write the source port to some random unused port number, like 14353. The provider’s server will note your source port so that it can contact your server if a call comes in. If you want to receive calls from the provider, you must ensure that the 14353 port stays associated with the 4569 port on your internal Asterisk server. Some firewalls DO NOT do this by default. For instance, on the Sonicwall TZ170, you must set “Firewall > VOIP > Enable consistent NAT” to “on”.
  • Consistent NAT Timeouts. Once you ensure that your NAT device uses consistent NAT re-writing as described above, you need to be aware that there may be timeouts associated with the port mappings. For instance, if no traffic occurs on port 14353 (see example above) for X seconds, the 4569 <> 14353 mapping will be dropped by the firewall – and your IAX2 provider can’t contact you anymore! For instance, on my Sonicwall TZ170 (Enhanced OS), the default Firewall > Advanced > Default UDP Connection Timeout (seconds) setting is 30 seconds – less than the Asterisk default IAX2 registration refresh period of 60 seconds! Boost your timeout setting to something more than the registration refresh period. (To see your Asterisk IAX2 registration refresh period, type “IAX2 show registry” from the Asterisk console.)

It is possible to change the Asterisk registration refresh period by editing the source code and re-compiling. Change this line:

iax2.h: #define IAX_DEFAULT_REG_EXPIRE 60

Of course, you are likely to forget about your tweak when you upgrade, so beware…

NAT Implementation Issues – Random “Raw Hangups”

I used the Sonicwall TZ170 (with the enhanced OS) to provide NAT for IAX2, but it never worked properly. A fraction of calls would end almost immediately after they started, with Asterisk reporting a “raw hangup” error and INVAL packets, suggesting that some IAX2 packets were being lost, mis-ordered, or mis-translated. My IAX2 provider indicated that other customers had the same problem with Sonicwall devices, and recommended a SnapGear SG560 instead.

As a temporary workaround, I replaced the TZ170 with an older, simpler Sonicwall SOHO/10 device, and it worked fine.

The SnapGear SG560 worked great too, and it offered multiple WAN connections, failover, VPNs, etc. Great inexpensive device! Highly recommended for IAX2 / VOIP / NAT use.

Moral of the story: if you get random raw_hangup errors on your IAX2 connections, replace your NAT device. (If you get raw hangup errors that are not random, that suggests a configuration error instead – see “General NAT Issues” above.) – mjc

NAT Implementation Problems – Linux kernel

Olivier ADLER of FRANCE IP reports that:

Some NAT devices can exhibit a really nasty bug when used in conjunction with a static IP with PPPOE or similar WAN connection.

The Linux kernel does not like at all to receive UDP data while the WAN interface is disconnected. During this period, Linux taint the NAT Masquerading table with the private LAN IP address of the source instead of the External public WAN IP — as there is no public IP available.

The bad thing is that after WAN reconnect, the kernel should rewrite the private LAN address to the new WAN public IP (the same one as we have a static address). But it does not do it. The kernel keep sending the private LAN address! So it transmits the previously private LAN address. The result is the IAX2 connection is broken.

Kernel 2.4 and 2.6.X are concerned. Kernel 2.6.22 need to be tested, as a new NAT code is present.

This bug does exhibit only if the WAN link has a static IP. With a dynamic IP, normal masquerading state is restored after the link reconnect — Pierre Belanger adds: on a reconnect that might be true if the IP address changes but on a fresh reboot/hard-reboot of the NAT device a static or dynamic IP have the same effect. When the unit reboots, chances is that it will receive a packet from the Asterisk box prior to have PPPoE properly setup. This taints the NAT table with an invalid entry.

It is evident that IAX2 cannot work with this problem, as the Asterisk peer cannot send back acknowledgments to a private LAN IP. To restore the masquerading process, the source (any device using IAX2 protocol, this includes Asterisk and IAX2 phones) need to stop sending UDP data on the IAX2 port during a time longer than the UDP Session Timeout. Typically more than 30 seconds on most routers (check the setup of your NAT device). Pierre Belanger adds: correct me if I’m wrong… since Asterisk sends a packet about every 60 seconds, shouldn’t the UDP Session Timeout be above 60 seconds to properly keep the entry in the NAT table? If so, I suggest a 65 seconds timeout.

Where things are even worse is when Asterisk detects a registration problem, it goes in a “panic” mode by sending registration requests every 2 or 3 seconds in the hope to recover the trunk as soon as possible — on the other side, your NAT device keeps the buggy state entry in the NAT table.

Unfortunately there is no setting in Asterisk to define the registration retry period.

So the only way to stop this problem is to stop Asterisk or temporary unload the IAX2 channel module for more than 65 seconds to avoid IAX2 data transmission. But be careful, if you are using this latest method, a single frame entering the firewall during reconnect (when there is no external Public address) will taint the kernel — if this happens, you need to unload the IAX2 channel module, wait for the kernel to remove the entry (UDP Sessions Timeout) and reload the module.

Restarting (unload and load back) the IAX2 channel module is not possible if a call is currently using an IAX2 channel. In this case, you need to restart Asterisk (stop & start).

For static IP address, one way to cleanly solve this problem is to remove the masquerading from the firewall tables and use SNAT instead in conjunction with the WAN static IP in the rule.

Here is a typical WAN firewall NAT iptables rule :

iptables -t nat -A POSTROUTING -o $WAN -j MASQUERADE

Need to be replaced for a static WAN connection by :

iptables -t nat -A POSTROUTING -o $WAN -j SNAT –to-source <your static public wan address>

This solves definitively and efficiently the IAX2 lost link problem as well as the Linux kernel NAT table tainting.

A report of the problem by another user :

This is something I’ve run into myself and my VOIP IAX2 provider has this issue with many clients running Asterisk on TrixBox or other custom made systems behind a NAT (Linux) router.

If our PPPoE goes down, we have to reboot our Asterisk server to get our IAX2 trunk to re-register otherwise, it will try and just keep timing out. I have the 4569 forwarded internal (Pierre Belanger adds: in many cases, the 4569 port forwarding useless unless your Asterisk server provides service to IAX2 phones from the Internet, i.e. not on your local LAN).

I have a dirty script that avoids having to reboot the TrixBox and restore our service within 2 minutes of a blip automatically, and logs the ‘blips’ so i can see how ‘reliable’ our service is.

Here is the script. Its dirty, but it works. *IF* someone can help me get IAX2 working behind our NAT DSL session, let me know. I think its related to me not being able to use “Consistent NAT”. We’re using a Linksys WRT54GS with DD-WRT v230-SP2. Yes SPI is turned off, I tried all types and kinds of forwarding too! I’m a bigtime network guy so reply with detailed info if you have it for me….

With the script below, use a CRON job to execute it. Say every two minutes. Warning, memory leak will occur over time during LONG outages as when the system unloads/releads the IAX2 stuff a little bit of memory never gets released.

If anyone has feedback let me know. I’m not a bash guru but i solved the problem for us, so hey hey. The time delay between unloading and reloading is key, not having that prevents the registration from working.

Pierre Belanger adds: this script here below is buggy, the state can be in “Request Sent”, in this case the script SHOULD NOT unload the IAX channel module — in Request Sent mode the answer can come back within a few milliseconds. It’s a racing condition. I have a new script to replace this one, I’ll post it soon.

#!/bin/sh

#We record the status of the IAX2 Trunk
cd /root/ # I have script live in root,
#change to suit or use full
# paths in rest of script,
# i'm not BASH guru
/usr/sbin/asterisk -rx 'iax2 show registry' > reg_status
sleep 1
#We then Scan the Status and see if we're online or not...

TEST="Registered"
if grep $TEST reg_status > /dev/null
then
exit #Abort, we are online, all is well...

#IF we're this far down, we've lost IAX. Log the incident.

date >> slap.log

#Restart the IAX2 trunk. Delay required for some reason.

comment from Olivier Adler : restarting the IAX2 channel is not possible if there are calls on it. It's better to restart asterisk.

be careful: restarting IAX2 channel or asterisk solve the masquerading problem, but does not clean the kernel tainting.

/usr/sbin/asterisk -rx 'unload chan_iax2.so' > /dev/null
sleep 66;
/usr/sbin/asterisk -rx 'load chan_iax2.so' > /dev/null

Comparison of IAX and SIP

IAX2 Tools

Software support

IAX2 Hardware

IAX2 Providers

See Also

  • IAX and bandwidth in italian language. By Gianrico Fichera 2008
  • IAX Protocol Specification by Mark Spencer and Frank W. Miller, March 2004
  • IAX providers reviews – Compare IAX providers and services
  • RFC 5456 – IAX: Inter-Asterisk eXchange Version 2
Related Posts:
Get 3CX - Absolutely Free!
Link up your team and customers Phone System Live Chat Video Conferencing

Hosted or Self-managed. Up to 10 users free forever. No credit card. Try risk free.

3CX
A 3CX Account with that email already exists. You will be redirected to the Customer Portal to sign in or reset your password if you've forgotten it.