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

"Hutton, Andrew" <andrew.hutton@siemens-enterprise.com> Wed, 10 November 2010 03:13 UTC

Return-Path: <andrew.hutton@siemens-enterprise.com>
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 A7CC93A67AE for <bliss@core3.amsl.com>; Tue, 9 Nov 2010 19:13:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 NSvDj9fEo2zs for <bliss@core3.amsl.com>; Tue, 9 Nov 2010 19:13:39 -0800 (PST)
Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 658E83A6452 for <bliss@ietf.org>; Tue, 9 Nov 2010 19:13:39 -0800 (PST)
Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-2242174; Wed, 10 Nov 2010 04:13:54 +0100
Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 131231EB82AB; Wed, 10 Nov 2010 04:13:54 +0100 (CET)
Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 10 Nov 2010 04:13:53 +0100
From: "Hutton, Andrew" <andrew.hutton@siemens-enterprise.com>
To: "Martin.Huelsemann@telekom.de" <Martin.Huelsemann@telekom.de>
Date: Wed, 10 Nov 2010 04:13:51 +0100
Thread-Topic: [BLISS] WGLC for draft-ietf-bliss-call-completion-07
Thread-Index: ActrXnBRVlSZi1rZQVePKrV5OtKl7gLIePoQADIECMACTuy2IA==
Message-ID: <101C6067BEC68246B0C3F6843BCCC1E307E07C1013@MCHP058A.global-ad.net>
References: <46705063-0A81-4DE5-927A-C74FC13AF6C9@agnada.com> <101C6067BEC68246B0C3F6843BCCC1E307DE1D0102@MCHP058A.global-ad.net> <BABF50A5EDD33C42A96DA535F1C8AA8003BF7747@S4DE9JSAAIL.ost.t-com.de>
In-Reply-To: <BABF50A5EDD33C42A96DA535F1C8AA8003BF7747@S4DE9JSAAIL.ost.t-com.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "bliss@ietf.org" <bliss@ietf.org>, "R.Jesske@telekom.de" <R.Jesske@telekom.de>, "shida@agnada.com" <shida@agnada.com>
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: Wed, 10 Nov 2010 03:13:40 -0000

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.