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

From: Robert Sparks <[email-masked]>
Date: Thu, 19 Jun 2008 15:59:06 -0500

fixed
On May 27, 2008, at 8:11 PM, 孙永光 wrote:

> 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

_______________________________________________
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, 19 Jun 2008 16:42:46 -0500

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.

---

From: Robert Sparks <[email-masked]>
Date: Thu, 19 Jun 2008 16:57:38 -0500

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