[asterisk-dev] IAX internet draft (draft-guy-iax-00)

[Derek Smithies]

Hi,
 well, I guess this forum is as good a place as any..

the doc says:

   OSeqno

      The 8-bit OSeqno field is the outbound stream sequence number.
      Upon initialization of a call its value is 0.  It increases
      incrementally as full frames are sent.  When the counter
      overflows, it silently resets to 0. 

  ISeqno

      The 8-bit ISeqno field is the inbound stream sequence number.
      Upon initialization of a call its value is 0.  It increases
      incrementally as full frames are received.  At any time the ISeqno
      of a call represents the next expected inbound stream sequence
      number.  When the counter overflows, it silently resets to 0.


Not quite.
 The iseqno increases by 1 as each full frame is received.
  However, it is not altered by receiving an ACK frame.

  We need this distinction - ack frames are a full frame.

  The iseqno and oseqno of an ack frame are determined by 
         (from memory, something like this)
   oseqno is the same as the iseqno of the iseqno of the packet being 
           acknowledged
   iseqno is the next expected oseqno. Thus, the ack transmission 
           mechanism has to keep track of the oseqnos that have arrived.
           On receiving an ack packet, you can look at the iseqno, and
           know what packets the other end has received.

  the timestamp of the ack frame is the same as that of the frame being 
     acked.
  Consequently, there are times when the timestamp (on the sending side)
   has to be "tweaked" high by 3, to differentiate between two different 
   frames.  A lagrq frame does not increase the oseqno at the sending 
   side.

Kenny Schumard sent me an email on this topic, here is a snippet:
                                                                                                                                            
> If you are sending an ack packet, the outseqno is the same as the 
> inseqno of the packet you are acking.
                                                                                                                                             
This is one of the parts of the protocol that I'm not as comfortable
with. But I know that the ack isn't supposed to send an outseqno as an
echo of the received inseqno -- it maintains its own outseqno and
compares the received inseqno with the ready-to-send outseqno. If they
don't match, then that's a clue that a message has been lost and a
VNAK should be sent to indicate this (as I understand it).
>
> If you are sending an ack packet, the timestamp of the ack packet is the
> same as that of the incoming packet.
                                                                                                                                            
Right, which makes sure that both ends know which packet is being
acked (as the seqnos could be off in the case of a dropped packet).

>
> Exceptions: When you send a new packet, you get an accept back. The
> accept packets is a "ack" like packet. However, the seqnos of the accept
> packet have no relation to the new packet. the timestamp of the accept
> packet has no relation to the new packet.
                                                                                                                                            
This is also right. The accept isn't an explicit ack of a new. There
can be an authreq sent in response to the new instead, in which case
the accept is independent of the new as far as packet-acknowledgment
goes. The accept implicitly acknowledges the new. Timestamp echoing
used as acknowledgment is only necessary for explicit acknowledgments.

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

The sentence::
 A timestamp MUST also be assigned for the
   call, beginning at 0 and incrementing each millisecond
is unclear. 
Incrementing by what value??

In fact::
 The timestamp has  units of milliseconds.
 Thus, the maximum timestamp in a 16bit field is 65.535 seconds.



Derek.


On Sat, 4 Mar 2006, Tim Panton wrote:

> 
> On 4 Mar 2006, at 20:46, Dimitri E. Prado wrote:
> 
> >
> > Hello All,
> >
> > what is the best forum to discuss issues regarding the IAX spec? More
> > specifically, there is some conflicting info on the current spec  
> > ( at least I
> > believe it is the current one) that I would like to clear up. There  
> > is also,
> > some places that I believe it would be usefull for the  
> > specification to be a
> > little bit clearer in order to avoid incompatible IAX  
> > specifications that still
> > comply to the same spec. I am currently implementing a IAX stack  
> > based on the
> > internet draft, and I already took a few different routes that made my
> > implementation not work with asterisk even though I believe it  
> > still follows
> > the spec.
> 
> If you find a suitable forum, please let me know, we'd be happy to  
> contribute
> our views on this draft too.
> 
> Tim Panton
> tim at mexuar.com
> 
> 
> 
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
> 

-- 
Derek Smithies Ph.D.                 Any fool can write code that 
IndraNet Technologies Ltd.                a computer can understand.        
Email: derek at indranet.co.nz         Good programmers write code 
ph +64 3 365 6485                          that humans can understand.
Web: http://www.indranet-technologies.com/            Martin Fowler