[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Draft submission: draft-ietf-sip-199-00
Hi,
>>>>One option, as proposed by Paul, is to say that a UAC shall be able
to RECEIVE reliable 199 responses.
>>>Based on my comments above, I am reconsidering the advisability of
that.
>>
>>Well, I guess it wouldn't affect the complexness in the UAC, since it
will have to be able to handle reliable
>>provisional responses anyway (if it indicates support of it, that is).
>
>Yes, I think it does increase the complexity in the implementation of
199 handling.
>
>You are right that theFrom sip-bounces at ietf.org Wed Jun 25 08:39:12 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 EF20628C104;
Wed, 25 Jun 2008 08:39:11 -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 9123F28C0F5
for <sip at core3.amsl.com>; Wed, 25 Jun 2008 08:39:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.219
X-Spam-Level:
X-Spam-Status: No, score=-6.219 tagged_above=-999 required=5 tests=[AWL=0.030,
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 kCfz2tKw2mq3 for <sip at core3.amsl.com>;
Wed, 25 Jun 2008 08:39:09 -0700 (PDT)
Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62])
by core3.amsl.com (Postfix) with ESMTP id 62DFE28C104
for <sip at ietf.org>; Wed, 25 Jun 2008 08:39:09 -0700 (PDT)
Received: from mailgw4.ericsson.se (unknown [127.0.0.1])
by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
C30CF2064C; Wed, 25 Jun 2008 17:39:06 +0200 (CEST)
X-AuditID: c1b4fb3e-af99bbb000004ec0-29-4862669a8aeb
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123])
by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
A9BE2205C5; Wed, 25 Jun 2008 17:39:06 +0200 (CEST)
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by
esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
Wed, 25 Jun 2008 17:39:34 +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:39:34 +0200
Message-ID: <CA9998CD4A020D418654FCDEF4E707DF06DBDDB9 at esealmw113.eemea.ericsson.se>
In-Reply-To: <4861347C.8020100 at cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Sip] Draft submission: draft-ietf-sip-199-00
thread-index: AcjWIxt9fMrJV+vKSPGXLzdJLoAhSwAtkGcQ
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> <4860E783.3070008 at cisco.com> <CA9998CD4A020D418654FCDEF4E707DF06D5E2AD at esealmw113.eemea.ericsson.se> <4860EC06.6080104 at cisco.com>
<CA9998CD4A020D418654FCDEF4E707DF06D7AE90 at esealmw113.eemea.ericsson.se>
<4861347C.8020100 at cisco.com>
From: "Christer Holmberg" <christer.holmberg at ericsson.com>
To: "Paul Kyzivat" <pkyzivat at cisco.com>
X-OriginalArrivalTime: 25 Jun 2008 15:39:34.0845 (UTC)
FILETIME=[AB316ED0:01C8D6D9]
X-Brightmail-Tracker: AAAAAA==
Cc: 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: sip-bounces at ietf.org
Errors-To: sip-bounces at ietf.org
Hi,
>>>>One option, as proposed by Paul, is to say that a UAC shall be able
to RECEIVE reliable 199 responses.
>>>Based on my comments above, I am reconsidering the advisability of
that.
>>
>>Well, I guess it wouldn't affect the complexness in the UAC, since it
will have to be able to handle reliable
>>provisional responses anyway (if it indicates support of it, that is).
>
>Yes, I think it does increase the complexity in the implementation of
199 handling.
>
>You are right that the PRACK i PRACK itself would be handled by the standard
machinery for reliable provisionals. But then
>tearing down the dialog, which is what the 199 is supposed to trigger,
can't be done upon receipt of a reliable 199.
>Rather it must wait until the after the PRACK is at least send, and
perhaps until the 200 for the prack is received. And >this is different
than for the unreliable 199. This isn't rocket science, but it is more
complexity. And of course it
>requires something that sends reliable 199s in order to test the UAC.
It is true that the PRACK transaction must be "alive" until the 200 OK
is received, but I assume all other "resources" can be released once the
199 is received.
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
tself would be handled by the standard
machinery for reliable provisionals. But then
>tearing down the dialog, which is what the 199 is supposed to trigger,
can't be done upon receipt of a reliable 199.
>Rather it must wait until the after the PRACK is at least send, and
perhaps until the 200 for the prack is received. And >this is different
than for the unreliable 199. This isn't rocket science, but it is more
complexity. And of course it
>requires something that sends reliable 199s in order to test the UAC.
It is true that the PRACK transaction must be "alive" until the 200 OK
is received, but I assume all other "resources" can be released once the
199 is received.
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