[asterisk-dev] The New CDR system

[Rod Dorman]

On Monday, April 2, 2007, 06:09:41, Tim Panton wrote:
> On 1 Apr 2007, at 18:07, Rod Dorman wrote:
>> On Sunday, April 1, 2007, 04:15:16, Tim Panton wrote:
>>> On 31 Mar 2007, at 17:17, Rod Dorman wrote:
>>>> On Saturday, March 31, 2007, 09:43:53, critch wrote:
>>>>> On Sat, 2007-03-31 at 10:59 +0300, Tzafrir Cohen wrote:
>>>>>>    ...
>>>>>> What you do is re-implement TCP (or TCP/with a bit of SSL).  
>>>>>> While it might work, ,it is not as good as the original.
>>>>  ...
>>>> I can understand Tzafrir's point of view. The IAX2 protocol draft
>>>> states
>>>>      "Full frames are sent reliably, so all full frames require an
>>>>      immediate acknowledgment upon receipt"
>>>> whereas  TCP  utilizes a sliding window protocol that doesn't
>>>> require an ACK for every individual transmission.
>>>
>>> Actually if you cared to it would be legitmate for an IAX
>>> implementation to ACK a number of fullframes by just acking the
>>> _last_ one, this implicitly acks all the earlier full-frames in that
>>> call.
>>
>> I'm  having  difficulty  finding  where  in  the  IAX2  draft that is
>> specified.  Its  not  stated in "6.11.1. ACK acknowledgement Message"
>> where I would expect to find it.
>>
>> The closest thing I can find is in "7. Message Transport" where it  
>> says:
>>    " ... And if the message is a reliable message, the incoming
>>     message counter MUST be used to acknowledge all the messages
>>     up to that sequence number which have been sent."
>>
>> But the way I interpret that it requires that each reliable message
>> MUST be individually acknowledged.
>
> Not the way I read it, here's the section on ACKs
>
>     When the following messages are received, an ACK MUST be sent in
>     return: NEW, HANGUP, REJECT, ACCEPT, PONG, AUTHREP, REGREL, REGACK,
>     REGREJ, TXREL.  ACKs SHOULD not be expected by any peer and their
>     purpose is purely to force the transport layer to be up to date.
>
> Implicitly for any other FullFrame the ACK is optional, so the the CDR
> frame type would be able to make it's own rules.
>
> In implementation terms you have to be able to treat ACKs as optional
> because for some messages they are - NEW for example may be 'acked'
> with either an ACK, an ACCEPT a REJECT, AUTHREQ depending on the
> situation.
>
> (I admit, I'm cheating - I got the clue from a helpful comment from  
> Mark a couple of years back...)

I'm not picky about where enlightenment is obtained :-)

It does point out that some wordsmithing would be helpful.

If any of the authors are reading this could you take this as a request
for clarification on when ACKs are required?

-- 
rodd at polylogics.com     "The avalanche has already started, it is too
Rod Dorman              late for the pebbles to vote." - Ambassador Kosh