Ok, I've just submitted -02 of the INVITE fix draft.
There is one really big change to correct the bug Brett found in the
thread below.
There's a new state in the INVITE client transaction and an associated
new timer.
The attempt to reuse Completed as in the previous draft didn't work
out -
Setting Timer D to 0 for TCP caused the wrong things to happen if we
were in
that state waiting for additional 2xxs. So, instead of always setting
Timer D to 64*T1,
regardless of transport, this draft uses a new "Accepted" state
instead. This way
transactions that get a 3xx or greater response over TCP can still go
away quickly.
There's a smaller related change - 3261 had setting Timer D at SHOULD
strength.
I can't remember why that wasn't a MUST (and neither can anyone I've
asked), and
it _really_ breaks things if it doesn't get set when using UDP, so
I've changed that
to a MUST in this draft.
Please review this carefully. (We really need a _lot_ of people to
think about it, not
just a few).
http://www.ietf.org/internet-drafts/draft-sparks-sip-invfix-02.txt
RjS
On Jun 19, 2008, at 4:57 PM, Robert Sparks wrote:
Hrm.
While working this over, it occurs to me that this might not be the
right thing to do.
It would force the client transaction to continue to exist for 32
seconds(ish) after acknowledging
a >=300 response over TCP. There's no reason to do so in this case
since there will never be
a retransmission of the response to absorb (failure responses are
hop-by-hop and the hop is TCP,
so this client would not have retransmitted the request).
It probably makes more sense to use another state in the client,
matching the new state in the server
instead of just trying to reuse this existing state. This new state
would be where the client transaction
sits waiting for multiple (or retransmitted) 2xx responses. The
Completed state would, then, be
completely unchanged from what's in 3261.
Anyhow, the next rev will have a concrete proposal.
RjS
On Jun 19, 2008, at 4:42 PM, Robert Sparks wrote:
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
_______________________________________________
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
