[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