Re: [BLISS] WGLC for draft-ietf-bliss-call-completion-07

<Martin.Huelsemann@telekom.de> Mon, 27 December 2010 15:27 UTC

Return-Path: <Martin.Huelsemann@telekom.de>
X-Original-To: bliss@core3.amsl.com
Delivered-To: bliss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A11F3A688B for <bliss@core3.amsl.com>; Mon, 27 Dec 2010 07:27:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.39
X-Spam-Level:
X-Spam-Status: No, score=-1.39 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1]
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 mo98UM-KUxpn for <bliss@core3.amsl.com>; Mon, 27 Dec 2010 07:27:40 -0800 (PST)
Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id 9F0F63A686D for <bliss@ietf.org>; Mon, 27 Dec 2010 07:27:38 -0800 (PST)
Received: from he111296.emea1.cds.t-internal.com ([10.125.90.14]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 27 Dec 2010 16:29:39 +0100
Received: from HE111543.emea1.cds.t-internal.com ([169.254.4.241]) by HE111296.EMEA1.CDS.T-INTERNAL.COM ([fe80::19ac:3fb4:a382:6df4%16]) with mapi; Mon, 27 Dec 2010 16:29:40 +0100
From: <Martin.Huelsemann@telekom.de>
To: <kpfleming@digium.com>, <andrew.hutton@siemens-enterprise.com>
Date: Mon, 27 Dec 2010 16:29:38 +0100
Thread-Topic: [BLISS] WGLC for draft-ietf-bliss-call-completion-07
Thread-Index: AcuJnwzDy2fAQ2oHRdCkfa3yrQNKSQcO3SdQ
Message-ID: <9762ACF04FA26B4388476841256BDE0201127D06BA87@HE111543.emea1.cds.t-internal.com>
References: <46705063-0A81-4DE5-927A-C74FC13AF6C9@agnada.com> <101C6067BEC68246B0C3F6843BCCC1E307DE1D0102@MCHP058A.global-ad.net> <BABF50A5EDD33C42A96DA535F1C8AA8003BF7747@S4DE9JSAAIL.ost.t-com.de> <101C6067BEC68246B0C3F6843BCCC1E307E07C1013@MCHP058A.global-ad.net> <4CE95289.9090405@digium.com>
In-Reply-To: <4CE95289.9090405@digium.com>
Accept-Language: de-DE
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: de-DE
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: bliss@ietf.org
Subject: Re: [BLISS] WGLC for draft-ietf-bliss-call-completion-07
X-BeenThere: bliss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" <bliss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/bliss>, <mailto:bliss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/bliss>
List-Post: <mailto:bliss@ietf.org>
List-Help: <mailto:bliss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bliss>, <mailto:bliss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Dec 2010 15:27:41 -0000

Hi,

I tried to rephrase it:


"The caller's UA sends an INVITE to a request URI. One or more forks of this request reach one or more of the callee's UAs. If the call-completion feature is available, the callee's monitor (note there can be a monitor for each of the callee's UAs) inserts a Call-Info header with its URI and with "purpose=call-completion" in appropriate non-100 provisional or final response messages to the initial INVITE and forwards them to the caller. On receipt of a non-100 provisional or a final response with the indication that the call-completion feature is available, the calling user can invoke the feature. The reason for invoking usually is a situation where the INVITE fails and the resulting dialog(s) are terminated, or a 200 OK to the INVITE was received from some other UA (e.g. the callee's voicemail)."



Regards, Martin






> -----Urspr√ľngliche Nachricht-----
> Von: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org]
> Im Auftrag von Kevin P. Fleming
> Gesendet: Sonntag, 21. November 2010 18:11
> An: bliss@ietf.org
> Betreff: Re: [BLISS] WGLC for draft-ietf-bliss-call-completion-07
>
> On 11/09/2010 08:13 PM, Hutton, Andrew wrote:
> > Hi Martin,
> >
> > See below.
> >
> > Regards
> > Andy
> >
> >>> Hi,
> >>>
> >>> The following comments are based on feedback I obtained from some
> >>> developers. Sorry that they are sent last minute.
> >>>
> >>> 1. Section 4.2 "Call-Completion procedures" (1st Para.). The text
> >>> indicates that call completion procedures are not required if the
> >>> callee's UAs return a success response. This is incorrect and in
> >>> conflict with the definition of "Failed Call" in the definitions.
> >>> The requirement for call completion is independent of the
> >>> success/failure of the SIP INVITE request.
> >>>
> >>>
> >>> 2. Section 4.2. (2nd para.) Again it is implied that the call
> >>> completion procedures seems tied to the state of the preceding
> >>> INVITE initiated dialog with the statement "Eventually,
> the INVITE
> >>> fails, or the resulting dialog(s) are terminated".
> However it is not
> >>> the case that the call completion procedures are
> independent of the
> >>> state any proceeding dialog. For example it should be possible to
> >>> initiate call completion even before the original INVITE
> dialog is
> >>> terminated.
> >>
> >> I've tried to combine the 2 paragrapgs:
> >>
> >> "The caller's UA sends an INVITE to a request URI. One or
> more forks
> >> of this request reach one or more of the callee's UAs.
> However there
> >> might be the situation that the calling user considers the
> result of
> >> the call insufficient to satisfy his needs, e.g. the
> INVITE fails and
> >> the resulting dialog(s) are terminated, or the INVITE
> might succeed
> >> at some other UA."
> >>
> >
> > [AndyHutton] - I think it needs to be made clear that the
> SUBSCRIBE for call completion can be initiated whatever the
> state of the original INVITE dialog. For example a 180 or
> 200OK response could be received to the original INVITE
> request and the user decides to invoke call completion before
> terminating the INVITE dialog. Maybe a statement to this
> effect could be made in section 4.2 and/or section 6.2.
>
> I agree. When the UAS sends any response that includes the
> call-completion information, the UAC is free to SUBSCRIBE for
> call completion services.
>
> --
> Kevin P. Fleming
> Digium, Inc. | Director of Software Technologies
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
> skype: kpfleming | jabber: kfleming@digium.com Check us out
> at www.digium.com & www.asterisk.org
> _______________________________________________
> BLISS mailing list
> BLISS@ietf.org
> https://www.ietf.org/mailman/listinfo/bliss
>