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