IAX2 Getting Stuck

Home » Asterisk Users » IAX2 Getting Stuck
Asterisk Users 10 Comments

I have a server that had been operating for a few years now with IAX2 trunks to several other servers. Since yesterday all IAX2 trunks now say UNREACHABLE. No configuration changes have been made and no upgrades have been done. The server is running 11.16.0 (yes, we are planning upgrades but lets solve this first). The server has a USB
ethernet adapter that got disconnected yesterday by accident and since it was reconnected we started having the problem. We have rebooted many times and even replaced the USB adapter but still the same issue, and the USB adapter is not the main ethernet link to the local network, it is just for a link to a provider. So far the only thing different is that the receive queue for port 4569 is not zero like all the other servers:

udp 128760 0 0.0.0.0:4569 0.0.0.0:*

Basically all packets for IAX2 are getting stuck in the queue. Any suggestions?


Telecomunicaciones Abiertas de México S.A. de C.V. Carlos Chávez dCAP #1349
+52 (55)8116-9161

10 thoughts on - IAX2 Getting Stuck

  • …snip…

    Have you tried rebooting the router which connects this machine to the Internet?

    It sounds like a stale connection-tracking table entry to me.

    Antony.

  • We have already tried that. One of the servers that has an IAX
    trunk to this server is on the same local network so that eliminates any firewall/router in the way. We disabled iptables just in case too.

  • Hm 🙁

    You say the USB ethernet adapter got unplugged and then reconnected…

    1. What’s the name of the network device for this adapter? Is it the same name as it previously had?

    2. What does ‘ifconfig’ say the IP address is for this adapter?

    3. What do you have in /etc/asterisk/iax.conf for ‘bindaddr’ and ‘bindport’?

    4. Do you have SIP connections on the same network interface, and are those working as normal?

    Antony.

  • 1- No changes to device names. eth0 is the main link to the network, eth1 (also internal) goes to a SIP provider and eth2 (the USB adapter)
    goes to another SIP provider. All IAX trunks use eth0

    2- ifconfig gives the proper IP and netmask for all interfaces

    3- We do not specify bindaddr or bindport in the config file as the default is to bind to 0.0.0.0

    4- We had to make new SIP trunks to replace the IAX2 trunks to all servers. The SIP trunk is working with no problems. Except for two SIP
    links to PSTN all internal extensions use the same network interface.

  • Ugh 🙁

    Sorry, I have no more ideas, then.

    I hope someone else comes into this thread with a helpful suggestion.

    Antony.

  • Can it happen that the routes lead the traffic through another interface?
    Did you try a packet capture with tcpdump? Do the packets really leave the usb adapter? Can asymmetric routing be in effect?
    Maybe there were some static routes that disappeared when the adapter was unplugged…

  • If routing was the problem then the SIP trunk would not work. Usually IAX2 is a little more forgiving about routing than SIP.

  • If SIP goes to the same provider then yes. Still I would check a packet capture for better understanding. BTW, did you try iax debug?

    чт, 20 апр. 2017 г. в 19:46, Carlos Chavez :

  • The new SIP trunks are replacing the IAX2 trunks to our other Asterisk servers and use exactly the same network paths, that is why I
    know it is not a network infrastructure issue. We did turn on IAX debug and we only se the server trying to poke the other servers but there is not response or any incoming traffic.

  • Hmmm.. So if you are sure that the poke packets leave the network interface
    (I would still check with tcpdump as well, maybe a firewall issue?) then it makes sense to check the other side to make sure the poke packets reach other servers. I mean with tcpdump you may see if there are incoming packets from your peers on the interface. If there are, then they are dropped or ignored by your servers. If no, then it’s better to check the other side. you may try smth like ‘tcpdump -npi host and port 4569′
    Do you have a firewall configured on this server?