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

[Tim Panton]

On 5 Mar 2006, at 21:46, Derek Smithies wrote:

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

Comments in line...

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

Yes. Quite right, there is a problem here, The way we've implemented  
this
is that iseq is set to the highest value+1 of all contiguously  
received frames.
So if we see a frame sequence
1,2,4,5 then iseq sticks at 3
but if we get 1,2,3,4,5 then it is 4
if we get 1,2,2,3,3,4,5 then it is 6
(The duplicates are Acks,  but this still works right)

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

I don't see why you say that. I think the +3 stuff is a work around  
for a
specific implementation problem, not a protocol requirement.
The combination of oseqno with ack'ness makes a packet unique.


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

The distinction here is that

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

No, you _must_ not ack a packet _after_ a dropped packet, untill you  
have filled
the gap via the retry mechanism.

Many of the actions in IAX only make sense in the right order
(new and hangup are a trivial example, but think of the way codecs
are negociated, it only works if you follow the correct sequence)

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

It is an implicit ack (think of TCP acks piggybacking on outgoing  
packets).
Your code has to treat every packet as an ack, and accept that some
frames will be acked more than once.
You don't need the timestamp to know which packet it is an ack for.  
The Iseq
tells you that.

I am basing this on a 5 min discussion I had with Mark, which clear  
things
up enormously for me.

The quick summary is :

The iseq value in any incomming fullframe represents an  
acknowlegement of
_every_ outgoing packet with an oseq less than this iseq value.



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

No, timestamp is either a 32 bit field (fullframe) or a 15 bit field
(miniframes).

If you wrap a 32 bit counter in a single call, you have other  
problems.......


Hope that helps....

Tim Panton
tim at mexuar.com