Tag: Technical

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.