[Asterisk-Dev] IAX Calls close after 140 seconds

Derek Smithies derek at indranet.co.nz
Tue Jun 21 15:51:45 MST 2005

  Sorry for the long post, but here is some stuff that is going to be 
useful for the iax-rfc.

 I have been using the iax client QTIAX and firefly to make iax calls to 
an * box. I have tried a couple of different * boxes, and the calls still 
get terminated.

Careful packet dumping + ethereal (0.10.10 (which includes iax decoder)) 
has provided some clue, but I wonder if someone can give an authoritative 

It appears that the iseqno used at each end is increased by 1 on receiving
each full frame.
iseqno is not increased on receiving a ACK packet.
 (code inspection suggests iseqno is not increased on receiving a INVAL 
  packet, and a couple of other transfer related packets)
iseqno is not increased on receiving a repeat transmission of the same 

oseqno is increaed on the same rules as for increasing the iseqno. 
However, oseqno is increased after sending a packet. Thus, for the first 
packet of a call, oseqno is 0
A New packet will be sent with oseqno equal to 0

when generating a ack packet (to acknowledge receipt), or an implict ack 
 the iseqno of the ack packet is from the counter of endpoint sending the 
 the oseqno of the ack packet is the iseqno of the packet being replied to
 the timestamp of the ack packet is the timestamp of the packet being 
   replied to.

An example of an implicit ack packet is a lagrp packet, which is sent in 
reply to a lagrq packet. - also, ping/pong - pong being an implicit ack.

An Accept packet is not am implicit ack packet. The accept is not an 
implicit ack to a new packet.

Note that The iseqno and timestamp of a full packet form a unique
identifying pair. An iax2 device will keep a record of timestamp and
iseqno of packets sent. On receipt of an ack packet, the iax2 device will
be able to determine which packet has been acknowledged.

should two packets be transmitted at the same time (say a ping and lagrq) 
then there is a very good chance that two full frames will be generated 
with the same iseqno and timestamp. This is an event that is unacceptable.
The timestamp of the second packet is raised by 3 ms, to guarantee 


And then I tried Steve K's iaxcli - the command line version.
With this code, both ends in the iax2 call send ping and lagrq packet 
every 10 seconds. qtiax does not send ping and lagrq packets while in a 

If no acknowledgement of the ping or lagrq packet is received, it will be 
sent again. However, the ping/lagrq packets are sent at the next 10second 
For example, a lagrq & ping is sent at 130 seconds into the call, with a 
timestamp of 130000. if these are not replied to, they are resent at 140 
seconds into the call. The act of resending them does not increase the 

I do not understand one thing though. Even though a lagrq, ping or voice 
packet is resent, the retransmit bit is not set. (Retransmit bit is the 
high bit in the 3rd byte of the iax frame.)

Anyhow, after a couple of minutes, qtiax reports the call has ended.
packet dumps report that the remote endpoint has sent INVAL packets, with 
iseqno and oseqno and timestamp of 0  - the call is gone....
I don't understand this - no hangup packet.

My question really is:: what makes qtiax different to iaxcli - that calls 
from qtiax fail after time, but iaxcli succeed. qtiax seems to follow 
exactly the same pattern as iaxcli as far as isenqo, oseqno, and timestamp 
are concerned.

yes, qtiax does not send lagrq/ping packets every 10 seconds, but this 
seems a bit like window dressing. media packets are being received 
(typically every 20ms), so there is good evidence the remote node is 

Derek Smithies Ph.D.                         
IndraNet Technologies Ltd.                
Email: derek at indranet.co.nz         
ph +64 3 365 6485                          
Web: http://www.indranet-technologies.com/  

More information about the asterisk-dev mailing list