[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] New version (-04) of draft-ietf-sip-199
Hi John,
>>>>"When a forking proxy receives a non-2xx final response which
>>>>terminates one or more (if forking has occured downstream a final
>>>>response received by the forking proxy MAY terminate multiple early
>>>>dialogs), and the proxy does not intend to forward the final
>>>>response immedialetly (due to the rules for a forking proxy),
>>>>and the UAC has indicated support of the 199 response code, the
proxy
>>>>SHOULD generate and send a 199 response upstream for the early
dialog
>>>>on which the non-2xx final response was received, unless the proxy
has previously
>>>>recieved and forwarded a 199 response for the dialog."
>>>
>>>WFrom sip-bounces at ietf.org Wed Jan 7 11:37:03 2009
Return-Path: <sip-bounces at ietf.org>
X-Original-To: sip-web-archive at optimus.ietf.org
Delivered-To: ietfarch-sip-web-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 035E33A6999;
Wed, 7 Jan 2009 11:37:03 -0800 (PST)
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 D4B183A6932
for <sip at core3.amsl.com>; Wed, 7 Jan 2009 11:37:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.201
X-Spam-Level:
X-Spam-Status: No, score=-6.201 tagged_above=-999 required=5 tests=[AWL=0.048,
BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
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 pRPKmKyxUnPg for <sip at core3.amsl.com>;
Wed, 7 Jan 2009 11:36:55 -0800 (PST)
Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60])
by core3.amsl.com (Postfix) with ESMTP id 746B43A6843
for <sip at ietf.org>; Wed, 7 Jan 2009 11:36:55 -0800 (PST)
Received: from mailgw3.ericsson.se (unknown [127.0.0.1])
by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
D083820692; Wed, 7 Jan 2009 20:36:40 +0100 (CET)
X-AuditID: c1b4fb3c-aaf58bb00000304c-87-496504484334
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.125])
by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
A70DA2025B; Wed, 7 Jan 2009 20:36:40 +0100 (CET)
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by
esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
Wed, 7 Jan 2009 20:36:40 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 7 Jan 2009 20:36:39 +0100
Message-ID: <CA9998CD4A020D418654FCDEF4E707DF05C0FA5D at esealmw113.eemea.ericsson.se>
In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0016B395D at GBNTHT12009MSX.gb002.siemens.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Sip] New version (-04) of draft-ietf-sip-199
thread-index: AclwpMa2gVaTl0oqRZ+oKLyml2UY7wAEccgwAAJTriAACo7ZIAAE4Evw
References: A
<CA9998CD4A020D418654FCDEF4E707DF0A392F09 at esealmw113.eemea.ericsson.se>
<0D5F89FAC29E2C41B98A6A762007F5D00167DF83 at GBNTHT12009MSX.gb002.siemens.net>
A
<CA9998CD4A020D418654FCDEF4E707DF0A3D592E at esealmw113.eemea.ericsson.se>
<0D5F89FAC29E2C41B98A6A762007F5D0016B395D at GBNTHT12009MSX.gb002.siemens.net>
From: "Christer Holmberg" <christer.holmberg at ericsson.com>
To: "Elwell, John" <john.elwell at siemens.com>,
<sip at ietf.org>
X-OriginalArrivalTime: 07 Jan 2009 19:36:40.0286 (UTC)
FILETIME=[432E77E0:01C970FF]
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [Sip] New version (-04) of draft-ietf-sip-199
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
Hi John,
>>>>"When a forking proxy receives a non-2xx final response which
>>>>terminates one or more (if forking has occured downstream a final
>>>>response received by the forking proxy MAY terminate multiple early
>>>>dialogs), and the proxy does not intend to forward the final
>>>>response immedialetly (due to the rules for a forking proxy),
>>>>and the UAC has indicated support of the 199 response code, the
proxy
>>>>SHOULD generate and send a 199 response upstream for the early
dialog
>>>>on which the non-2xx final response was received, unless the proxy
has previously
>>>>recieved and forwarded a 199 response for the dialog."
ow! We really must shorten this sentence. In particular I don't like
>>>including a second normative sentence in parentheses within the main
>>>sentence.
>>
>>I can try to think of more simple wording.
>>
>>And, text suggestions are of course always welcome :)
>>
>How about:
>"When a forking proxy receives a non-2xx final response that terminates
one or more early dialogs, if the proxy does not intend to forward the
final response immediately (in accordance with rules for a
>forking proxy) and the UAC has indicated support for the 199 response
code, the proxy SHOULD generate and send a 199 response upstream for
each early dialog terminated on the downstream side by the
>non-2xx final response, except for any early dialog for which the proxy
has previously received and forwarded a 199 response. Note that if
forking has also occurred downstream of the forking proxy, a
>final response received by the forking proxy can terminate multiple
early dialogs."
>
>I have removed the normative statement that was in parentheses and
created a separate sentence at the end. However, I believe it does not
need to be normative - it is just a statement of something that
>arises because of the normative provisions of RFC 3261.
>
>I believe the proxy should send a 199 response on EACH affected early
dialog (unless 199 already sent). This too is reflected in my proposed
rewording.
That is covered in the existing text:
"If the forking proxy generates a 199 response, and if the forking proxy
is able to
identify additional early dialogs which are terminated by the same
non-2xx final response, it MUST also generate and send a 199 response
upstream for each of those early dialogs, except for any dialog on
which the proxy has previously received and forwarded a 199 response."
I don't mind working with your proposal, but I think it important to
keep the "IF the forking proxy is able to identify additional early
dialogs" part, because the forking proxy may not be able to associate
other early dialogs with the non-2xx response.
One proposal would be the following:
"When a forking proxy receives a non-2xx final response that terminates
one or more early dialogs, if the proxy does not intend to forward the
final response immediately (in accordance with rules for a
forking proxy) and the UAC has indicated support for the 199 response
code, the proxy SHOULD generate and send a 199 response upstream for
each early dialog terminated (if the forking proxy is able to identify
additional early dialogs that are terminated by the non-2xx final
response) on the downstream side by the non-2xx final response, except
for any early dialog for which the proxy has previously received and
forwarded a 199 response. Note that if forking has also occurred
downstream of the forking proxy, a final response received by the
forking proxy can terminate multiple early dialogs. Based on
implementation policy, the proxy MAY wait before sending the 199
response, e.g. if the proxy expects to receive a 2xx final response on
another dialog shortly after it received the non-2xx final response
which triggered the 199 response."
Regards,
Christer
_______________________________________________
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
>>>
>>>Wow! We really must shorten this sentence. In particular I don't like
>>>including a second normative sentence in parentheses within the main
>>>sentence.
>>
>>I can try to think of more simple wording.
>>
>>And, text suggestions are of course always welcome :)
>>
>How about:
>"When a forking proxy receives a non-2xx final response that terminates
one or more early dialogs, if the proxy does not intend to forward the
final response immediately (in accordance with rules for a
>forking proxy) and the UAC has indicated support for the 199 response
code, the proxy SHOULD generate and send a 199 response upstream for
each early dialog terminated on the downstream side by the
>non-2xx final response, except for any early dialog for which the proxy
has previously received and forwarded a 199 response. Note that if
forking has also occurred downstream of the forking proxy, a
>final response received by the forking proxy can terminate multiple
early dialogs."
>
>I have removed the normative statement that was in parentheses and
created a separate sentence at the end. However, I believe it does not
need to be normative - it is just a statement of something that
>arises because of the normative provisions of RFC 3261.
>
>I believe the proxy should send a 199 response on EACH affected early
dialog (unless 199 already sent). This too is reflected in my proposed
rewording.
That is covered in the existing text:
"If the forking proxy generates a 199 response, and if the forking proxy
is able to
identify additional early dialogs which are terminated by the same
non-2xx final response, it MUST also generate and send a 199 response
upstream for each of those early dialogs, except for any dialog on
which the proxy has previously received and forwarded a 199 response."
I don't mind working with your proposal, but I think it important to
keep the "IF the forking proxy is able to identify additional early
dialogs" part, because the forking proxy may not be able to associate
other early dialogs with the non-2xx response.
One proposal would be the following:
"When a forking proxy receives a non-2xx final response that terminates
one or more early dialogs, if the proxy does not intend to forward the
final response immediately (in accordance with rules for a
forking proxy) and the UAC has indicated support for the 199 response
code, the proxy SHOULD generate and send a 199 response upstream for
each early dialog terminated (if the forking proxy is able to identify
additional early dialogs that are terminated by the non-2xx final
response) on the downstream side by the non-2xx final response, except
for any early dialog for which the proxy has previously received and
forwarded a 199 response. Note that if forking has also occurred
downstream of the forking proxy, a final response received by the
forking proxy can terminate multiple early dialogs. Based on
implementation policy, the proxy MAY wait before sending the 199
response, e.g. if the proxy expects to receive a 2xx final response on
another dialog shortly after it received the non-2xx final response
which triggered the 199 response."
Regards,
Christer
_______________________________________________
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