H i All 7.1. UAS Impacts
If the *UAC's *TU issues a 2xx response for this transaction while the state machine is in the "Proceeding" state, it MUST transisition to the "Accepted" state and set Timer L to 64*T1. the UAC should be UAS 2008/5/27, Brett Tate <[EMAIL PROTECTED]>: > > Thanks for the response. Reply inline. > > > > 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. > > Okay. > > > > 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. > > By extra 300-699, I was mainly referring to 1) race conditions with 2xx > and 2) interoperability with pre-rfc3261 devices. > > 1) This should be rare since usually only results from connection > issues, threading issues, or stateless proxy issues causing the > reordering. > > 2) Unfortunately this is not as rare as everyone would like. However it > is likely not much of an issue if the invfix chooses not to remain > backwards compatible with rfc2543 concerning resending the ACK. > > > > 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. > > Okay. > _______________________________________________ > 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 >
_______________________________________________ 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
