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? -- [EMAIL PROTECTED] "The avalanche has already started, it is too Rod Dorman late for the pebbles to vote." - Ambassador Kosh _______________________________________________ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
