[Asterisk-Dev] IAX Spec online

[Steve Kann]

Kenny Shumard wrote:

>>The term reliable / unreliable is wrong. If it is sent reliable,
>>the sender guarantees that the packet arrives. I would replace it
>>with:
>>
>>   All full frames must be immediate acknowledged upon receipt.
>>   This acknowledgment can be explicit via an 'ACK' message (see
>>   Section 8) or implicit based upon receipt of an appropriate
>>   response to the full frame issued.
>>
>>Note the RFC version of "must".
>>    
>>
>
>Duly noted, I'll change it per your suggestion. Thanks.
>  
>
>>Same with 4.2:
>>
>>    4.2  Mini frames
>>
>>       Mini Frames are so named because their header is a minimal 4 octets.
>>       Mini frames carry no control or signaling data; their sole purpose is
>>       to carry a media stream on an already-established IAX call.  They are
>>       sent unreliably.  This decision was made because VOIP calls typically
>>       can miss several frames without significant degradation in call...
>>
>>I would replace it with::
>>
>>       to carry a media stream on an already-established IAX call.
>>       Mini frames should not need to be acknowledged upon receipt.
>>       This decision was made because VOIP calls typically...
>>
>>Note the RFC version of "should not". That indicates that they *can*
>>be acknowledged if wanted, but it is not necessary. Is that the
>>expected behaviour? If not, it should be replaced with "must not
>>be".
>>
>>    
>>
>I don't know that this has ever been considered. I lean toward saying
>mini frames "must not" be acknowledged, in order to prohibit excessive
>bandwidth usage. After all, if you're using mini frames you're passing
>media and I can't think of any reason to acknowledge receipt of it
>anyway.
>  
>

mini frames have no sequence number, therefore there's no way to 
acknowledge them.  You couldn't acknowledge them if you really, really 
wanted to.

-SteveK



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20050427/be0dda1b/attachment.htm