[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] INFO Framework - one pakage per INFO
See below.
Keith
> -----Original Message-----
> From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On
> Behalf Of Hadriel Kaplan
> Sent: Saturday, November 29, 2008 4:50 AM
> To: Anders Kristensen
> Cc: SIP List
> Subject: Re: [Sip] INFO Framework - one pakage per INFO
>
>
> > -----Original Message-----
> > From: Anders Kristensen From sip-bounces at ietf.org Mon Dec 1 02:59:52 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 D06993A69C1;
Mon, 1 Dec 2008 02:59:52 -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 1880D3A6944
for <sip at core3.amsl.com>; Mon, 1 Dec 2008 02:59:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.466
X-Spam-Level:
X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133,
BAYES_00=-2.599]
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 K0Rqw1dZn8Yp for <sip at core3.amsl.com>;
Mon, 1 Dec 2008 02:59:50 -0800 (PST)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33])
by core3.amsl.com (Postfix) with ESMTP id 42FA43A68D2
for <SIP at ietf.org>; Mon, 1 Dec 2008 02:59:49 -0800 (PST)
Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50])
by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id mB1Axgea022743;
Mon, 1 Dec 2008 04:59:42 -0600 (CST)
Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by
ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830);
Mon, 1 Dec 2008 04:59:42 -0600
Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by
DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830);
Mon, 1 Dec 2008 11:59:40 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 1 Dec 2008 11:59:39 +0100
Message-ID: <5D1A7985295922448D5550C94DE2918002559F16 at DEEXC1U01.de.lucent.com>
In-Reply-To: <E6C2E8958BA59A4FB960963D475F7AC31374B1F189 at mail>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Sip] INFO Framework - one pakage per INFO
Thread-Index: AclRzFN5YL+PuibDRr26ZRipcW1+BQADhGWwAHI8FbA=
References: <94081CC4-F9BE-4651-BE3D-9D5CEDC3CA8D at standardstrack.com><CA9998CD4A020D418654FCDEF4E707DF05C0F98E at esealmw113.eemea.ericsson.se><F779DAF0-507D-4BB0-BA8C-C687F1C7BB30 at standardstrack.com><CA9998CD4A020D418654FCDEF4E707DF05C0F9E2 at esealmw113.eemea.ericsson.se><E6C2E8958BA59A4FB960963D475F7AC31374B1F09C at mail><CA9998CD4A020D418654FCDEF4E707DF05C0F9E8 at esealmw113.eemea.ericsson.se><E6C2E8958BA59A4FB960963D475F7AC31374B1F0DE at mail><CA9998CD4A020D418654FCDEF4E707DF05C0F9EB at esealmw113.eemea.ericsson.se><5FD627EF-B1CB-4F03-A79B-8D75E9CA0B65 at standardstrack.com><49306F15.5020905 at cisco.com><E6C2E8958BA59A4FB960963D475F7AC31374B1F161 at mail><4930AC7C.8040406 at cisco.com>
<E6C2E8958BA59A4FB960963D475F7AC31374B1F189 at mail>
From: "DRAGE, Keith \(Keith\)" <drage at alcatel-lucent.com>
To: "Hadriel Kaplan" <HKaplan at acmepacket.com>,
"Anders Kristensen" <andersk at cisco.com>
X-OriginalArrivalTime: 01 Dec 2008 10:59:40.0175 (UTC)
FILETIME=[E87869F0:01C953A3]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
Cc: SIP List <SIP at ietf.org>
Subject: Re: [Sip] INFO Framework - one pakage per INFO
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
See below.
Keith
> -----Original Message-----
> From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On
> Behalf Of Hadriel Kaplan
> Sent: Saturday, November 29, 2008 4:50 AM
> To: Anders Kristensen
> Cc: SIP List
> Subject: Re: [Sip] INFO Framework - one pakage per INFO
>
>
> > -----Original Message-----
> > From: Anders Kristensen [mailto:[mailto:andersk at cisco.com]
> > Sent: Friday, November 28, 2008 9:44 PM
> >
> > In any event (no pun intended) I don't think the draft adequately
> > deals with the implications of this model. If errors occurring at
> > higher layers aren't reported as failure of the INFO
> request itself,
> > it pretty much follows that the 200 response to the INFO
> must include
> > a payload that carries info (sorry, pun not intended here
> either) on the error.
>
> No I think the logic that Eric's arguing for is "you asked
> for delivery of this package, and I'm responding with 200 ok
> because it was delivered". In other words treat INFO as a
> delivery vehicle, like MESSAGE, and as long as the package
> was delivered you send a 200 ok, with no correlation to
> if/when the package was opened and read successfully or not
> by a higher-layer info-package "consumer".
>
Correct. And why do something different when MESSAGE already does it
that way.
>
> > The alternatives would be:
> > 1) Don't report app-level errors. Perhaps OK for simple packages.
> > 2) Report outcome in separate INFO requests going in the opposite
> > direction. Seems wasteful and requires additional app-level
> correlation.
>
> Yeah, I think Eric's argument is for (2). If they need it,
> they pay for it.
Correct
A 3xx to 6xx indicates failure to deliver the info package to the
application above.
The simplest error recovery case which seems to apply in existing usage
is no information is sent in the reverse direction regarding application
error handling, or it is handled as part of the application protocol,
i.e. there is a message embedded in the package which in any case
generates a response within the application.
_______________________________________________
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
andersk at cisco.com]
> > Sent: Friday, November 28, 2008 9:44 PM
> >
> > In any event (no pun intended) I don't think the draft adequately
> > deals with the implications of this model. If errors occurring at
> > higher layers aren't reported as failure of the INFO
> request itself,
> > it pretty much follows that the 200 response to the INFO
> must include
> > a payload that carries info (sorry, pun not intended here
> either) on the error.
>
> No I think the logic that Eric's arguing for is "you asked
> for delivery of this package, and I'm responding with 200 ok
> because it was delivered". In other words treat INFO as a
> delivery vehicle, like MESSAGE, and as long as the package
> was delivered you send a 200 ok, with no correlation to
> if/when the package was opened and read successfully or not
> by a higher-layer info-package "consumer".
>
Correct. And why do something different when MESSAGE already does it
that way.
>
> > The alternatives would be:
> > 1) Don't report app-level errors. Perhaps OK for simple packages.
> > 2) Report outcome in separate INFO requests going in the opposite
> > direction. Seems wasteful and requires additional app-level
> correlation.
>
> Yeah, I think Eric's argument is for (2). If they need it,
> they pay for it.
Correct
A 3xx to 6xx indicates failure to deliver the info package to the
application above.
The simplest error recovery case which seems to apply in existing usage
is no information is sent in the reverse direction regarding application
error handling, or it is handled as part of the application protocol,
i.e. there is a message embedded in the package which in any case
generates a response within the application.
_______________________________________________
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