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

[Steve Kann]

Adrian Sietsma wrote:

> Tim Panton wrote:
>
>>
> ...
> (amended)
>
>>
>> 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
>>
>>
>>> -SteveK
>>>
>>> You're right, Dimitri.  I'm guessing he meant to type the sequence 
>>> 1,2,4,5,3 which would be illustrative of what happens when you 
>>> receive out-of-order full frames.
>>
>
> surely 1,2,4,5,3 would stick at 3, according to the def'n above ?


No, it would go to 4 -- I guess the definition isn't clear.

Here's what happens for each frame:

1: OK, acked
2: OK, acked
4: this is out-of-order, ignored (vnak could be sent, but it doesn't 
really matter)
5: same as 4.
3: This is OK, and gets acked.

The point is, the receiver only ever acks or acts upon full frames when 
they are the "expected" sequence number.  So, when you start the call 
both sides expect 1 (or zero, I forget).  From there on, they only act 
upon the expected frames, and each time they get one (and act upon it), 
they expect the next one.

So, frame 3 is still expected when it's received, even though frames 4,5 
have already arrived.

I suppose a receiver _could_ store frames 4,5, and then, as soon as it 
gets frame 3, it could act upon frame 4, then frame 5.  This would be an 
optimization it could make, but which libiax2/chan_iax2 don't presently 
make.

>
> but if 1,2,3,5,4 then it is 4
>
> If that is so,then how do frames 4 & 5 ever get acked ?

They would be retransmitted, because they are not acked the first time 
they're sent, and eventually, the retransmits would be acked.

-SteveK