IAX2 false unreachable

Hi All,

I sometimes have a problem with IAX2 peers showing unreachable, but I can ping the peer. Executing iax2 reload doesn’t resolve the issue. Restarting asterisk also doesn’t resolve the issue. If I reboot the machine then the peers will be reachable again. If I stop asterisk and restart the network interfaces the IAX2 peers will sometimes be reachable again. This happens on servers that either have or don’t have firewalls running. I have seen this happening with asterisk 1.4, 1.6 and 1.8. I make use of CentOS 5.6

Help would be greatly appreciated.
Thank you
Corne.

Is this a new install or have these peers been working for a long time and suddenly stopped working reliably?
Are all the peers on the same subnet or are they routed?
Is there any NAT involved?
You have multiple systems, are the trunks defined as a star or mesh? If mesh, are multiple machines reporting unreachable to the same peer? For instance. A is trunked to both B and C, B is trunked directly to C. If A reports C is unreachable, does B also report C as unreachable?

Hi dalenoll,

I am referring to old and new sites with various typologies and instances though out a couple of years, which we always resolved by restarting the network interfaces or rebooting the servers. The last specific occurrence I am fighting with now, is a star type of typology with natting through a Cisco router. It is a static configuration with microwave and fiber endpoints and static ip addresses. After a reboot of the central server, the IAX connections will stay reachable of x days then all of a sudden become unreachable, but you can still ping the servers. We have no funny configurations, we use stock standard Asterisk 1.6 with stock standard and minimal configuration. For example:

server side:
[general]
bandwidth=low
jitterbuffer=yes
forcejitterbuffer=no
autokill=yes

[xxxxxxxx]
secret=yyyyyyyy
type=friend
host=dynamic
context=lcr-1
qualify=yes
disallow=all
allow=g729
notransfer=true
requirecalltoken=no
trunk=no
accountcode=xxxxxxxx

client side:
[general]
bindport=4569
bindaddr=0.0.0.0
disallow=all
allow=g729
jitterbuffer=no
requirecalltoken=no
autokill=yes

register=>xxxxxxxx:yyyyyyyy@zzz.zzz.zzz.zzz

[aaaaaaaa]
type=friend
trunk=false
qualify=yes
host=zzz.zzz.zzz.zzz
username=xxxxxxxx
secret=yyyyyyyy
disallow=all
allow=g729
context=inbound

Thank you,
Corne

Very interesting situation.

You stated you have a static configuration. I assume that mean all the Asterisk servers have static IPs. Does that also mean that you have a static IP on the WAN side of the Cisco router?

You stated that you can ping the remote during an ‘unreachable’ state. Can I assume you are pinging from the central server?

Is it possible that the latency of your connection goes up, causing the qualify to make the trunk as bad? The default timeout for qualify is 2000ms, you could try increasing that number and see of the results change.

You may also want to turn on IAX2 debugging to see what asterisk is doing during the outage.

Hi! i have an issue like that but with asterisk 1.8

I think its caused because a lag in the network or any peer, makes all unreachable

Did you solve it?

I think many of these IAX2 Unreachable problems may be fixed in 1.8.23 or 11.5.0

Refer to all of the IAX2 fixes since April 2013;
svnview.digium.com/svn/asterisk/ … c?view=log

Alec Davis

I will test he update, But for users that its impossible for what ever reason to update. I have a script that unloads and loads IAX2 module

cyber-cottage.co.uk/en/2013/07/i … reachable/

One of the issues I see by unload/reload of chan_iax that an IAX packet can arrive before the iax process threads have started properly.

The fix is one of recent patches, which waits for all of the iax process threads to get started, before starting the network thread.

refer to the issue and reviewboard
issues.asterisk.org/jira/browse/ASTERISK-18827
reviewboard.asterisk.org/r/2427/

However, if the link is already down, then it can do no harm.

Hi

We are seeing this issue on systems that have been stable for years but have migrated to bonded DSL links of EFM links when one leg of the bonding has gone down and come back up.
The script only unloads and loads if the chosen link is unreachable, Its running on a selection of problem sites and is 100% successful in keeping the link in service.

I still have this problem. I’ve tried to use ian’s script to unload the iax module and load it back again but the connection is still unreachable until I reboot the server. I know that the problem happens when the link of my vpn office has some instability but it doesn’t come back again. I am using asterisk 11.5.0, the topic is a little old but if someone could help me it would be great. Tks.

hi mrfrossard,
I stumbled on the same problem even with Asterisk 11.7.0. I think the problem is related to the NAT problem as described in url voip-info.org/wiki/view/IAX (NAT implementation section) - if there’s NAT involved.

Recently, I got an assignment to setup two asterisk servers, both were behind NAT (without VPN on each site), and only using port forward implementation. In some x hours, I got UNREACHABLE status between IAX2 trunk connection, and the only told me something like:

NOTICE[30372] chan_iax2.c: Peer ‘eIAX196’ is now UNREACHABLE! Time: 89

Even I got disconnection while call session was in progress and the log said:

WARNING[30111] chan_iax2.c: Max retries exceeded to host xxx.xxx.xxx.xxx on IAX2/eIAX196-293 (type = 6, subclass = 2, ts=7
98051, seqno=237)

I did a lot of config maneuvers including changing the maxexpiry, defaultexpiry, etc. And I also adding static port setup on both routers to avoid port rewrite, all directions. And still got same problems next few hours.

Problem was solved by implementing SSL/TLS vpn (OpenVPN) on both sides. But still I need to know if I could still connect IAX2s behind NAT without aforementioned problem.

I had the same problem twice with machines behind NAT. Only solution for me was changing the router on the “unreachable” side to another model. Days of playing with settings gave nothing.

Using Asterisk 11.17.1