[Asterisk-Dev] IAX Calls close after 140 seconds

[tim panton]

On 21 Jun 2005, at 23:51, Derek Smithies wrote:

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

That would be Mark :-)
I have been struggling to understand the RFC myself, and
I'd failed until I was lucky enough to catch Mark at Astricon in
Madrid.

Digium are aware that the lack of IAX2 doc is a problem. They are
hiring someone,who starts next month, to push this forward.

In the meanwhile, here's what I learnt, don't
take it as gospel....

All frames are from the _senders_ prespective,
and remember IAX is a stream oriented protocol
like tcp, not a send-receive protocol like snmp or
http.

Oseq is the current highest seqno sent by the transmitting
agent.

Iseq is the number the transmitting party expects to see
in the oseq field in the next received fullframe.
Note that this isn't the same as +1 for every fullframe or even last +1
The difference relates to missing fullframes. If an inbound packet is  
lost
iseq will remain at the value for that fullframe - even after subsequent
fullframes arrive - until the missing one (or an appropriate retry) has
arrived.

When you recieve any fullframe the recieved iseq tells you that the
transmitter has received _all_ the packets you sent with an oseq
less than this iseq. Any fullframes you have sent with oseqs greater  
than
or equal to the most recent received iseq are candidates for retries.

So all fullframes act as acks, in that they carry an iseq and
that tells the recipient what has been seen by the far end.

Ack frames are just used to send a fresh iseq to the far end when
there is no prospect of an immediate fullframe to carry it.
Acks don't increment the oseq, but they do have the timestamp set
to the value in the packet to which they are an ack.

>
> It appears that the iseqno used at each end is increased by 1 on  
> receiving
> each full frame.

No, it is always highest_contiguously_recieved_oseq+1

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

Not exactly. iseqno on it's own is unique it is an ack of all the
full frames sent upto but not including iseq.
The timestamp is useful in packet traces and filtering
because iseq wraps after a few mins in a typical call, so
the timestamp can be used to differentiate.

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

Why would it be unacceptable ?
They have different oseqs, and they both convey the same implicit
ack info.

I'm close to having a java implementation of IAX2 available, that
will provide a different viewpoint.

Tim.

>
> 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/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20050622/0e8e1f0f/attachment.htm