[asterisk-dev] IAX internet draft (draft-guy-iax-00)
Steve Kann
stevek at stevek.com
Mon Mar 6 13:08:49 MST 2006
Rod Dorman wrote:
>On Monday, March 6, 2006, 14:26:59, Steve Kann wrote:
>
>
>>Adrian Sietsma wrote:
>>
>>
>>> ...
>>>This would imply that _all_ frames received subsequently would be
>>>ignored, until frame #4 re-arrives, and resets the sequence ?
>>>
>>>
>>That's correct. That's how it works presently, and the way it would
>>have to work, unless the receiver stored out-of-order frames (which
>>would be a worthwhile optimization to make for the lossy link case, as
>>you note below). I think that such an "out-of-order" reciever store
>>could be done without changing the specs, though -- as long as it
>>doesn't _act_ on frames out-of-order, it could probably defer processing
>>them until it got the missing frame.
>>
>>
>
>Is it worth stating that explicitly by saying something along the lines
>of:
> "The receiver MAY store out-of-order frames but MUST NOT process
> them until it receives the missing frame."
>
>
It wouldn't hurt to put that in there, so it's clear that clients may do
this, and it's a good hint to implementors about how they can improve
their implementation. I don't think there's a strong need for this in
current practice, where there are few full frames sent in a typical
call. I also don't think it would change anything, because as far as the
sender is concerned, it can't really tell that a client does this,
because the effect is basically the same as would happen if there was or
wasn't reordering in the network.
-SteveK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20060306/91f27cec/attachment.htm
More information about the asterisk-dev
mailing list