[Asterisk-Dev] IAX Calls close after 140 seconds
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
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
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
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
More information about the asterisk-dev