Subject: [Sip] draft-sparks-sip-invfix-01: comments and questions

From: "Brett Tate" <[email-masked]>
Date: Mon, 19 May 2008 17:27:32 -0400

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.

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?

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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Robert Sparks <[email-masked]>
Date: Thu, 22 May 2008 18:11:54 -0500

> 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.

> 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

---

From: "Brett Tate" <[email-masked]>
Date: Tue, 27 May 2008 11:01:53 -0400

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.

> 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.

> thought we had, but its possible that's messed up. I'll look at it  

Okay.

---

From: "孙永光" <[email-masked]>
Date: Wed, 28 May 2008 09:11:48 +0800

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