[asterisk-dev] The New CDR system

Tim Panton tim at mexuar.com
Mon Apr 2 03:09:41 MST 2007


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...)

Tim.






More information about the asterisk-dev mailing list