Subject: Re: [Sip] draft-sparks-sip-invfix-02

From: Robert Sparks <[email-masked]>
Date: Fri, 5 Sep 2008 15:15:34 -0500

(sorry for the lag)

All fixes incorporated

On Jul 17, 2008, at 8:20 AM, Michael Procter wrote:

> Hi Robert,
>
> On Thu, July 3, 2008 6:32 pm, Robert Sparks wrote:
>> Please review this carefully. (We really need a _lot_ of people to
>> think about it, not just a few).
>
> I've been through this draft recently, and it broadly matches up to  
> the
> changes we have been using successfully for a while now (modulo some
> implementation details).  I only have a few minor comments:
>
> Figure 2:
> This might be a minor typo, or I may have completely misunderstood the
> draft.  Should the state labelled 'Completed' actually be labelled
> 'Accepted'?
>
> 8.4 para 7:
> The first sentence is a little awkward.  It currently contains
>   'the "Accepted" state, The client'
>
> Obvious fixes are either
>   'the "Accepted" state.  The client'
> or
>   'the "Accepted" state, the client'
> but both end up with the sentence sounding a bit clumsy.
>
> You could replace the entire sentence with something like this:
>   When in either the "Calling" or "Proceeding" states a 2xx response  
> is
>   received, the client transaction MUST transition to the "Accepted"
>   state, and Timer M MUST be started with a value of 64*T1. The 2xx
>   response MUST be passed up to the TU.
>
> Minor typos
> ===========
> 7.1 para 2:
> "transisition" should be "transition"
>
> 7.3 para 1:
> "any response SIP response" should be "any SIP response"
>
> Figure 3:
> "Timer B fired" should be "Timer B fires" (and used to be)
>
> 8.10 Timer M:
> "retranmission" should be "retransmission"
>
> Best regards,
>
> Michael
>

_______________________________________________
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: Fri, 5 Sep 2008 15:17:04 -0500

Nits fixed.

For your suggestion 4 below:

It would not be the right thing to transition to Terminated - we want  
the transaction state to still be around to receive any  
retransmissions of the INVITE, but it might make sense to tell the TU  
that its 2xx's aren't going anywhere. I'll work that into the figure  
and text unless someone objects here quickly.

RjS

On Jul 23, 2008, at 10:27 AM, Kolomaznik Jan wrote:

> I have just a couple of nits:
>
> 1. State labeled Completed on Figure 2 should be labeled Accepted
>
> 2. section 7.3 paragraph 1 contains "... receiving any response SIP
> response ..."
>
> 3. While whole section 18 in RFC 3261 deals with SIP transport layer
> regardless transaction stateful or stateless behavior, it could be
> explicitly clarified that suggested change of section 18.1.2 (in  
> invfix
> section 8.8) tells just about stateful behavior.
>
> 4. INVITE server state machine doesn't react to transport error in
> Accepted state. It could contain transition from Accepted to  
> Terminated
> state conditioned by transport error - analogy to transitions from
> Proceeding and Completed states.
>
> Jan
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Robert Sparks
> Sent: Thursday, July 03, 2008 7:32 PM
> To: Robert Sparks
> Cc: [email-masked] List; Brett Tate
> Subject: [Sip] draft-sparks-sip-invfix-02 (was
> Re:draft-sparks-sip-invfix-01: comments and questions)
>
> 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.
>
> 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.
>>>

---

From: "Kolomaznik Jan" <[email-masked]>
Date: Mon, 8 Sep 2008 10:05:36 +0200

OK, but if we want to receive and mask all request retransmissions on transaction layer, this problem is more general. Than we probably need to inform TU about transport error, create a new state, and stay there enough time to absorb all retransmissions of INVITE request.  And this is needed for transport error reaction not only in Accepted state, but also for transport error in Proceeding and Completed states. There also may be a question whether to inform TU about transport error in Proceeding and Completed states while there is probably no state of TU in these states of transaction layer.

Please note that if we accept that the SIP transaction layer has to receive and mask all request retransmissions when it detects a transport error, then also non-INVITE server transaction should be changed - reaction to transport error in Proceeding and Completed states.

Kolomaz

-----Original Message-----
From: Robert Sparks [mailto:[email-masked]] 
Sent: 5. září 2008 22:17
To: Kolomaznik Jan
Cc: [email-masked] List
Subject: Re: [Sip] draft-sparks-sip-invfix-02 (was Re:draft-sparks-sip-invfix-01: comments and questions)

Nits fixed.

RjS

---

From: Robert Sparks <[email-masked]>
Date: Mon, 8 Sep 2008 15:31:01 -0500

Inline.

On Sep 8, 2008, at 3:05 AM, Kolomaznik Jan wrote:

> OK, but if we want to receive and mask all request retransmissions  
> on transaction layer, this problem is more general. Than we probably  
> need to inform TU about transport error
the next version of the draft (hopefully out later today) will do this.
> , create a new state,
I don't see the need fo rthis

> and stay there enough time to absorb all retransmissions of INVITE  
> request.
The existing Accepted state does this.

>  And this is needed for transport error reaction not only in  
> Accepted state, but also for transport error in Proceeding and  
> Completed states.
Those states already transition to Terminated on transport error -  
(they did so in 3261).

I think I see what you're getting at on keeping state after this  
transport error is noticed though - I don't know about Proceeding, but  
if you're in Completed, throwing away the state when you try to send  
your final response and the transport complains may not be the right  
thing to do. Let me poke at that for a little while.

> There also may be a question whether to inform TU about transport  
> error in Proceeding and Completed states while there is probably no  
> state of TU in these states of transaction layer.

That TU has decided to send a provisional or failure-final response in  
those cases. There's a chance there is application state being  
maintained as a result (or precondition) to those decisions, so  
letting the TU know is important. Again, this was 3261 behavior already.

>
>
> Please note that if we accept that the SIP transaction layer has to  
> receive and mask all request retransmissions when it detects a  
> transport error, then also non-INVITE server transaction should be  
> changed - reaction to transport error in Proceeding and Completed  
> states.
Will look.

Its probably worth pulling up and asking if trying to address this  
kind of edge-condition failure is worth the effort.
The changes we're talking about here won't make something succeed  
later - its not going to help the network or application repair/ 
recover from whatever transport error is being reported. What it will  
do is help prevent an application from re-performing some work based  
on a retransmission (possibly causing different resulting end-states).  
That might be enough justification on its own, but its worth asking if  
this is really a big enough problem to take on the fix?

---

From: "Kolomaznik Jan" <[email-masked]>
Date: Thu, 11 Sep 2008 17:01:38 +0200

I agree, a change of reaction to transport error is a "game" with edge-conditions. I also agree that issuing of a new special and only transport error fixing RFC makes no sense - but what about in situation when a new fixing RFC is in progress to address another error? I think it makes sense to think about it in INV server transaction case.

As you responded, the change of reaction to transport error in Completed and Accepted states (saving current states) solves possible different final response(s) and due to this it may be important accept this change. I have tried to think about it also for Proceeding state, but I don't see any important reason for this change. I have found out only these (just improving) minor reasons:

1) if the TU receives transport error notification, and the TU successfully initiate repair of transport layer, how the TU may send a response when the transaction layer is in the Terminated state? Note there is no sure that retransmission(s) of INV request will happen (especially in case when a 1xx response has been already successfully received by a UAC and there is no NAT between UAC and UAS).

2) I am not sure (it is not clearly specified) who (transaction layer or TU) behaves according to RFC 3263, section 5, page 12, paragraph 1. If this is the job of TU, and a transport error happens, and the transaction layer is destroyed, how the TU can send a response to a new IP:port pair?

Kolomaz

-----Original Message-----
From: Robert Sparks [mailto:[email-masked]] 
Sent: 8. září 2008 22:31
To: Kolomaznik Jan
Cc: [email-masked] List
Subject: Re: [Sip] draft-sparks-sip-invfix-02 (was Re:draft-sparks-sip-invfix-01: comments and questions)

Inline.

Will look.