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

["Brett Tate" <brett at broadsoft.com>]

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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip