On May 19, 2008, at 4:27 PM, Brett Tate wrote: > The following are few comments and questions concerning > draft-sparks-sip-invfix-01. > > > Section 8.2: > > The "MUST NOT" is rather strict. Depending upon interpretation, it > can > interfere with a stateful proxy choosing to temporarily act like a > stateless proxy for a short interval after a restart. > It's that strong on purpose - it's closing a fairly large security hole. 16.7 in 3261 (which is what this section is touching) is explicitly about transaction stateful proxies. If a proxy is being transaction stateless, it does not apply.
> > Section 8.4: > > Concerning timer D and "zero seconds for reliable transports", is > "reliable" obtained from INVITE or ACK. > > Concerning timer D being zero, at first glance it looks like the state > machine text no longer ensures ACK will be sent for extra 2xx or > 300-699. The same applies, to ensuring ACK resent in situations where > transport not reliable end-to-end. Per 7.2 paragraph 2, this might be > intentional; if so, the motivation and flexibility in handling from > section 7.2 should potentially also be included within 8.4. If I'm > misinterpreting the fix, where does it say the ACK MUST, SHOULD, or > MAY > still be (re-)sent for the extra responses when timer D is 0? Well, the main requirement you're looking for is (still) on the TU. But I see your point in wondering if a retransmitted 200 will still _get_ to the TU if it came over UDP. Let me look at it for awhile. To carve that away from some of the other questions you ask above: You're talking about receiving a response over a reliable transport (like TCP). Over such a transport, there won't _be_ any additional 300-699 responses unless the thing on the other end is violating the specification - remember those are hop-by-hop messages, and the thing sending them is required to hand reliability to the reliable transport (it won't retransmit - timer G is not set for reliable transports). The path through the machines when a 300-699 occurs hasn't changed from 3261. For a 200 class response, the transaction state machine doesn't send the ACK - that is still the TU's job and this draft doesn't change that. What we need to make sure is that we're leaving the path for a retransmitted (or a 200 from another branch) to _get_ to the TU. I thought we had, but its possible that's messed up. I'll look at it some more. RjS > > > > Thanks, > Brett _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
