[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] draft-sparks-sip-invfix-02 (was Re:draft-sparks-sip-invfix-01: comments and questions)
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: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On Behalf Of
Robert Sparks
Sent: Thursday, July 03, 2008 7:32 PM
To: Robert Sparks
Cc: SIP at ietf.org 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 cFrom sip-bounces at ietf.org Wed Jul 23 08:27:08 2008
Return-Path: <sip-bounces at ietf.org>
X-Original-To: sip-archive at optimus.ietf.org
Delivered-To: ietfarch-sip-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id DD3E73A6900;
Wed, 23 Jul 2008 08:27:08 -0700 (PDT)
X-Original-To: sip at core3.amsl.com
Delivered-To: sip at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 9161D3A69FC
for <sip at core3.amsl.com>; Wed, 23 Jul 2008 08:27:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.25
X-Spam-Level:
X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5
tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id iFXVss3ljiNX for <sip at core3.amsl.com>;
Wed, 23 Jul 2008 08:27:06 -0700 (PDT)
Received: from mail.strom.cz (mail.strom.cz [80.95.102.231])
by core3.amsl.com (Postfix) with ESMTP id EB0393A6900
for <sip at ietf.org>; Wed, 23 Jul 2008 08:27:05 -0700 (PDT)
Received: from exalfa.stromtelecom.cz ([172.16.16.10]) by mail.strom.cz with
Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Jul 2008 17:27:46 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 23 Jul 2008 17:27:45 +0200
Message-ID: <C756BE639CE70040B64A183F46B6AA3F92FEA6 at exalfa.stromtelecom.cz>
In-Reply-To: <906A9DC6-4BA4-4C41-BE74-ABD799B9E33C at nostrum.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Sip] draft-sparks-sip-invfix-02 (was
Re:draft-sparks-sip-invfix-01: comments and questions)
Thread-Index: AcjdMxcrBdP5Bqc7RcOyysPOjlP9UQPoWQSw
References: <BBE61D1553D8A34F812FF87377B2935F038F0F73 at ATL1VEXC020.usdom003.tco.tc><CFE48150-62DD-465B-937F-110C9D56588A at nostrum.com><89B3083B-309D-41D2-99CE-62803C9D8AA1 at nostrum.com>
<906A9DC6-4BA4-4C41-BE74-ABD799B9E33C at nostrum.com>
From: "Kolomaznik Jan" <Jan.Kolomaznik at sitronicsts.com>
To: "Robert Sparks" <rjsparks at nostrum.com>
X-OriginalArrivalTime: 23 Jul 2008 15:27:46.0700 (UTC)
FILETIME=[A8AC14C0:01C8ECD8]
Cc: "SIP at ietf.org List" <sip at ietf.org>
Subject: Re: [Sip] draft-sparks-sip-invfix-02 (was
Re:draft-sparks-sip-invfix-01: comments and questions)
X-BeenThere: sip at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip>,
<mailto:sip-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:sip at ietf.org>
List-Help: <mailto:sip-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip>,
<mailto:sip-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: sip-bounces at ietf.org
Errors-To: sip-bounces at ietf.org
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: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On Behalf Of
Robert Sparks
Sent: Thursday, July 03, 2008 7:32 PM
To: Robert Sparks
Cc: SIP at ietf.org 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 trlient 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 transporansaction 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). Thts). 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
>
_______________________________________________
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
_______________________________________________
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
e 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
>
_______________________________________________
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
_______________________________________________
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