In the past we have found that IAX@ peers have been reliable and solid.
But lately with the advent of bonded ADSL lines and other forms of aggregated lines we have seen issues where the IAX2 trunk will go down and a simple reload of Asterisk or even a restart doesn’t fix it.
Taken from Voip-info
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 behing 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.
We have take the original script posted and made some changes, Notably it checks a defined peer name as we have seen that the problem doesn’t always affect all peers on a system.
======Code follows ======
#!/bin/sh #We record the status of the IAX2 Trunk cd /root/ # I have script live in root, # Set the peer name to monitor here # ****** peername="YOURIAX2PEERNAME" # ****** date >> slap.log echo "Testing $peername peer" >> slap.log /usr/sbin/asterisk -rx 'iax2 show peers' |grep -i $peername >> slap.log /usr/sbin/asterisk -rx 'iax2 show peers' |grep -i $peername > reg_status sleep 1 #We then Scan the Status and see if we're online or not... TEST="OK" if grep $TEST reg_status > /dev/null then echo "All OK Here" >> slap.log exit #Abort, we are online, all is well... fi #IF we're this far down, we've lost IAX. Log the incident. echo "we have a problem with $peername, Restarting it" >> slap.log #Restart the IAX2 trunk. Delay required for some reason. /usr/sbin/asterisk -rx 'module unload chan_iax2.so' >> slap.log sleep 90; /usr/sbin/asterisk -rx 'module load chan_iax2.so' > /dev/null echo "Restarted it Now lets check status" >> slap.log sleep 5; /usr/sbin/asterisk -rx 'iax2 show peers' |grep -i $peername >> slap.log #We record the status of the IAX2 Trunk /usr/sbin/asterisk -rx 'iax2 show peers' |grep -i $peername > reg_status sleep 1 #We then Scan the Status and see if we're online or not... TEST="OK" if grep $TEST reg_status > /dev/null then echo "All OK Here" >> slap.log exit #Abort, we are online, all is well... fi #IF we're this far down, we've lost IAX. Log the incident. echo "we have a problem with $peername, Restarting it" >> slap.log #Restart the IAX2 trunk. Delay required for some reason. /usr/sbin/asterisk -rx 'module unload chan_iax2.so' >> slap.log sleep 120; /usr/sbin/asterisk -rx 'module load chan_iax2.so' > /dev/null echo "Restarted it Now lets check status" >> slap.log sleep 5; /usr/sbin/asterisk -rx 'iax2 show peers' |grep -i $peername >> slap.log #We record the status of the IAX2 Trunk
======Code ends======
This seems to do the trick and its cronned to run every night or hour in some cases.
UPDATE
on testing and speaking to suppliers. We would advise adding the following settings to your IAX2 peers
qualifysmoothing=yes qualifyfreqnotok=30000 qualifyfreqok=120000 qualify=yes
With this added we have not seen any unexpected unreachables.