IAX Port

Home » Asterisk Users » IAX Port
Asterisk Users 7 Comments


Sometimes IAX peers are not reachable and with “iax2 set debug on” I get something like this

Tx-Frame Retry[ No] — OSeqno: 000 ISeqno: 001 Type: IAX Subclass: PONG
Timestamp: 00014ms SCall: 00001 DCall: 01200
Rx-Frame Retry[ No] — OSeqno: 001 ISeqno: 001 Type: IAX Subclass: ACK
Timestamp: 00014ms SCall: 01200 DCall: 00001

I am not sure what causes port 4569 to be replaced an an arbitrary port, which could be the reason for my problem. Does someone know whether this is a router related problem?


7 thoughts on - IAX Port

  • 2015-02-09 14:36 GMT-06:00 jg :


    Port is changed when NAT is applied from LAN to WAN. While UDP session is maintained as ESTABLISHED, that port should not change.

    If your peer changes constantly of session port could be UDP session is too short in NAT table on routers. You can try setting qualify00 (which is in ms. Default is 2000), and see if peer keeps same port.


  • I get an occasional similar problem, we have Mikrotik firewalls and from tcpdump monitoring on the asterisk boxes I can see that the firewall
    (unbidden) has changed the IAX port. Usually a firewall reset and sometimes PBX reset combination fixes it.

    Its odd as its only one direction, occurs rarely and with no obvious driver. So IAX is happy in one direction but not the other. And I can see packets in the unhappy point arriving on the wrong port.

    I couldn’t fix it without kicking the router/firewall so I would say its a router problem in the Destination NAT process.

    Cheers Duncan

  • voip-info.org also has an entry about general NAT related issues, which could be relevant here

    I do not seem to have problems with Netgear firewalls, but other firewalls show this effect. So far it happened only on a single side, such that calls work from the other side. I already checked the open ports with nc/ncat/netcat as UDP sender and receiver on the other end. The ports are open, even when the arbitrary ports are used by Asterisk.

    I’ll need to read a bit more and evaluate my pcap traces and possibly ask the router vendors.

    Thank you for your efforts.


  • Some firewalls have a ‘consistent NAT’ option that needs to be enabled, otherwise you get the symptoms described.

  • While reading about NAT, I came across this web site:
    The test tool looks at various NAT related properties and prints the results related to TCP/UDP
    binding properties, TCP/UDP hole punching, etc.

    In my case a very short value was reported for the UDP timeout, such that depending on the sequence of packets, the entry in the mapping table might already have been deleted. This could explain the random nature of my connection problem. Port predictability does not seem to be a problem.

    Does that make any sense?

  • Yes

    UDP timeout being too short is another thing I’ve experience with firewalls
    (admittedly limited and once removed experience). Actually, this one can be a (mild) problem on Draytek routers and can be resolved by telnetting into the router and using the portmaptime command.

    Also, turn of stateful packet inspection if it is an option.