[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Draft submission: draft-ietf-sip-199-00
Hi Jeroen,
Forgive me if I don't understand what you are trying to say, but if you have an early dialog it means that you have received a non-100 provisional response with a to-tag.
Are you asking that I should indicate which state the eFrom sip-bounces at ietf.org Wed Jun 25 08:47:50 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 F2D7128C104;
Wed, 25 Jun 2008 08:47:49 -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 BB1383A67AB
for <sip at core3.amsl.com>; Wed, 25 Jun 2008 08:47:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.221
X-Spam-Level:
X-Spam-Status: No, score=-6.221 tagged_above=-999 required=5 tests=[AWL=0.028,
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 OYCVxZOXNVyy for <sip at core3.amsl.com>;
Wed, 25 Jun 2008 08:47:47 -0700 (PDT)
Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62])
by core3.amsl.com (Postfix) with ESMTP id 0B1DC28C0F9
for <sip at ietf.org>; Wed, 25 Jun 2008 08:47:47 -0700 (PDT)
Received: from mailgw4.ericsson.se (unknown [127.0.0.1])
by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
AFBC921284; Wed, 25 Jun 2008 17:47:11 +0200 (CEST)
X-AuditID: c1b4fb3e-ad997bb000004ec0-d0-4862687ff16a
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
8F3D620F8C; Wed, 25 Jun 2008 17:47:11 +0200 (CEST)
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by
esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
Wed, 25 Jun 2008 17:47:30 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 25 Jun 2008 17:47:28 +0200
Message-ID: <CA9998CD4A020D418654FCDEF4E707DF06DBDE04 at esealmw113.eemea.ericsson.se>
In-Reply-To: <48613B9F.5020307 at zonnet.nl>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Sip] Draft submission: draft-ietf-sip-199-00
thread-index: AcjWJ33OOqHXx3jdTxWGs7bycJB7RgAsxEYA
References: <CA9998CD4A020D418654FCDEF4E707DF06435093 at esealmw113.eemea.ericsson.se><200806130255.m5D2t0gC031044 at dragon.ariadne.com><CA9998CD4A020D418654FCDEF4E707DF06AF22CF at esealmw113.eemea.ericsson.se> <200806202237.m5KMbcuk008312 at dragon.ariadne.com><CA9998CD4A020D418654FCDEF4E707DF06D3A423 at esealmw113.eemea.ericsson.se><4860A45F.9020001 at zonnet.nl>
<CA9998CD4A020D418654FCDEF4E707DF06D3A629 at esealmw113.eemea.ericsson.se>
<F86B91A10B14744E88408E80B8A30EF3032FF5B0 at xmb-hkg-412.apac.cisco.com>
<CA9998CD4A020D418654FCDEF4E707DF06D5DC69 at esealmw113.eemea.ericsson.se>
<F86B91A10B14744E88408E80B8A30EF3032FF5F1 at xmb-hkg-412.apac.cisco.com>
<48613B9F.5020307 at zonnet.nl>
From: "Christer Holmberg" <christer.holmberg at ericsson.com>
To: "Jeroen van Bemmel" <jbemmel at zonnet.nl>,
"Rockson Li (zhengyli)" <zhengyli at cisco.com>
X-OriginalArrivalTime: 25 Jun 2008 15:47:30.0337 (UTC)
FILETIME=[C69BC110:01C8D6DA]
X-Brightmail-Tracker: AAAAAAÌ: sip at ietf.org
Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00
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-Archive: <https://www.ietf.org/mailman/private/sip>
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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: sip-bounces at ietf.org
Errors-To: sip-bounces at ietf.org
Hi Jeroen,
Forgive me if I don't understand what you are trying to say, but if you have an early dialog it means that you have received a non-100 provisional response with a to-tag.
Are you asking that I should indicate which state the entity isntity is in when it sends the 199? Do you have some wording proposal?
Regards,
Christer
-----Original Message-----
From: Jeroen van Bemmel [mailto:jbemmel at zonnet.nl]
Sent: 24. kesäkuuta 2008 21:23
To: Rockson Li (zhengyli)
Cc: Christer Holmberg; sip at ietf.org
Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00
Christer,
My point was to formalize the moment a 199 is sent by relating it to the
RFC3261 ICT state machine (BTW we're all silently assuming non-INVITE requests don't use provisional responses here) So associated with PROCEEDING-->COMPLETED, but indeed only if a to-tag was received before (so not only 100)
Regards,
Jeroen
PS perhaps an idea to explicitly disallow 199 for non-INVITE requests?
Rockson Li (zhengyli) wrote:
> Yes, it's a typo, 100 does not establish early-dialog.
> -Rockson
>
> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmberg at ericsson.com]
> Sent: Tuesday, June 24, 2008 6:32 PM
> To: Rockson Li (zhengyli); Jeroen van Bemmel
> Cc: sip at ietf.org
> Subject: RE: [Sip] Draft submission: draft-ietf-sip-199-00
>
>
> Hi,
>
>
>>> Should the 199 response contain a Contact header? And if yes, in
>>> case a proxy sends it, should it contain the address of that proxy (since the UAS already sent a final response)?
>>>
>> IF the 199 is sent reliably be the proxy must contain a Contact header containing the address of the proxy, yes.
>>
>>
>>> Should we say that a proxy may only generate and send a 199 when it
>>> receives a final error response on an INVITE client Transaction
>>> which was in the PROCEEDING state? (i.e. 1xx response was received
>>> before, so conceptually sending the 199 response is an action
>>> associated with the transition from PROCEEDING to COMPLETED)
>>>
>> I am not sure I understand. The idea IS to send 199 when a final
>> error response is received by the forking proxy, if a 18x has previously been received.
>> [Rockson] PROCEEDING does not mean early-dialog is established, 100
>> Trying also move INVITE client Transaction to PROCEEDING state.
>>
>
> [Christer] 199 is only sent when an early dialog has been established. 100 Trying does not establish an early dialog.
>
> Regards,
>
> Christer
>
>
>
>
>
>
> Also, a forking proxy with multiple INVITE client Transaction may receive/forward 180 from one of them, and receive no provisional resp and final resp directly from the other one, so INVITE client Transaction's state is not dependable. The decision making must be done in TU.
>
>
>
>
>
> Christer Holmberg wrote:
>
>> Hi,
>>
>> I agree it may be a good idea to not forbid sending it reliably.
>>
>> I do think it would be good to have text, saying that it can be sent unreliable even if reliable responses are required, though, so that proxies aren't forced to terminate PRACKs etc.
>>
>> Regards,
>>
>> Christer
>>
>>
>> -----Original Message-----
>> From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On Behalf Of
>> Dale.Worley at comcast.net
>> Sent: 21. kesäkuuta 2008 1:38
>> To: sip at ietf.org
>> Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00
>>
>> From: "Christer Holmberg" <christer.holmberg at ericsson.com>
>>
>> [CHH] Whether the text should be in the document at all depends on if we
>> allow 199 to be sent reliably in the first place. Based on the comments
>> received so far we should not mandate 199 to be sent reliably, even if
>> 100rel is required by the UAC. But, the question if whether we want to
>> FORBID sending it reliably.
>>
>> If we ever might allow 199 to be used for HERFP, we should admit the possibility of sending it reliably in the first draft. Otherwise, we'll be locked out of sending it reliably in the future.
>>
>> Dale
>> _______________________________________________
>> 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
>
>
_______________________________________________
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
in when it sends the 199? Do you have some wording proposal?
Regards,
Christer
-----Original Message-----
From: Jeroen van Bemmel [mailto:jbemmel at zonnet.nl]
Sent: 24. kesäkuuta 2008 21:23
To: Rockson Li (zhengyli)
Cc: Christer Holmberg; sip at ietf.org
Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00
Christer,
My point was to formalize the moment a 199 is sent by relating it to the
RFC3261 ICT state machine (BTW we're all silently assuming non-INVITE requests don't use provisional responses here) So associated with PROCEEDING-->COMPLETED, but indeed only if a to-tag was received before (so not only 100)
Regards,
Jeroen
PS perhaps an idea to explicitly disallow 199 for non-INVITE requests?
Rockson Li (zhengyli) wrote:
> Yes, it's a typo, 100 does not establish early-dialog.
> -Rockson
>
> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmberg at ericsson.com]
> Sent: Tuesday, June 24, 2008 6:32 PM
> To: Rockson Li (zhengyli); Jeroen van Bemmel
> Cc: sip at ietf.org
> Subject: RE: [Sip] Draft submission: draft-ietf-sip-199-00
>
>
> Hi,
>
>
>>> Should the 199 response contain a Contact header? And if yes, in
>>> case a proxy sends it, should it contain the address of that proxy (since the UAS already sent a final response)?
>>>
>> IF the 199 is sent reliably be the proxy must contain a Contact header containing the address of the proxy, yes.
>>
>>
>>> Should we say that a proxy may only generate and send a 199 when it
>>> receives a final error response on an INVITE client Transaction
>>> which was in the PROCEEDING state? (i.e. 1xx response was received
>>> before, so conceptually sending the 199 response is an action
>>> associated with the transition from PROCEEDING to COMPLETED)
>>>
>> I am not sure I understand. The idea IS to send 199 when a final
>> error response is received by the forking proxy, if a 18x has previously been received.
>> [Rockson] PROCEEDING does not mean early-dialog is established, 100
>> Trying also move INVITE client Transaction to PROCEEDING state.
>>
>
> [Christer] 199 is only sent when an early dialog has been established. 100 Trying does not establish an early dialog.
>
> Regards,
>
> Christer
>
>
>
>
>
>
> Also, a forking proxy with multiple INVITE client Transaction may receive/forward 180 from one of them, and receive no provisional resp and final resp directly from the other one, so INVITE client Transaction's state is not dependable. The decision making must be done in TU.
>
>
>
>
>
> Christer Holmberg wrote:
>
>> Hi,
>>
>> I agree it may be a good idea to not forbid sending it reliably.
>>
>> I do think it would be good to have text, saying that it can be sent unreliable even if reliable responses are required, though, so that proxies aren't forced to terminate PRACKs etc.
>>
>> Regards,
>>
>> Christer
>>
>>
>> -----Original Message-----
>> From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On Behalf Of
>> Dale.Worley at comcast.net
>> Sent: 21. kesäkuuta 2008 1:38
>> To: sip at ietf.org
>> Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00
>>
>> From: "Christer Holmberg" <christer.holmberg at ericsson.com>
>>
>> [CHH] Whether the text should be in the document at all depends on if we
>> allow 199 to be sent reliably in the first place. Based on the comments
>> received so far we should not mandate 199 to be sent reliably, even if
>> 100rel is required by the UAC. But, the question if whether we want to
>> FORBID sending it reliably.
>>
>> If we ever might allow 199 to be used for HERFP, we should admit the possibility of sending it reliably in the first draft. Otherwise, we'll be locked out of sending it reliably in the future.
>>
>> Dale
>> _______________________________________________
>> 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
>
>
_______________________________________________
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