Hi Brett -
I got to go through this very carefully today. You found a real bug
here.
Timer D is going to have to be set to 64*T1 without regard to transport.
It needs to balance what's potentially happening on the server side with
either Timer H or Timer L.
I'll also go through the whole text again to see if this was an
isolated bug
or a class-of bug that has other instances, and will issue an update
to the
draft shortly.
RjS
On May 27, 2008, at 10:01 AM, Brett Tate wrote:
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
