[Asterisk-Dev] IAX Calls close after 140 seconds

[Derek Smithies]

Hi,
  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 
answer..

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 
  packet.

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 
packet, 
 the iseqno of the ack packet is from the counter of endpoint sending the 
           ack
 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 
uniqueness.

====================================================================

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 
call.

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 
timeperiod.
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 
oseqno.

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 
alive.

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