Re: [clue] Ben Campbell's No Objection on draft-ietf-clue-signaling-14: (with COMMENT)

Ben Campbell <ben@nostrum.com> Tue, 20 November 2018 20:19 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: clue@ietfa.amsl.com
Delivered-To: clue@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E363E130DDA; Tue, 20 Nov 2018 12:19:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Level:
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3TZwiOVXtZK5; Tue, 20 Nov 2018 12:19:26 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B57DA130DE0; Tue, 20 Nov 2018 12:19:26 -0800 (PST)
Received: from [10.0.1.24] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id wAKKJJmR049290 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 20 Nov 2018 14:19:20 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.24]
From: Ben Campbell <ben@nostrum.com>
Message-Id: <A998E94D-D0B6-47F4-822D-265A87EA49B2@nostrum.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_638552CE-707F-47DE-AFD8-169FB9913B59"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
Date: Tue, 20 Nov 2018 14:19:19 -0600
In-Reply-To: <e1321782-7904-c904-93cc-5036880ef195@alum.mit.edu>
Cc: The IESG <iesg@ietf.org>, draft-ietf-clue-signaling@ietf.org, "Daniel C. Burnett" <danielcburnett@gmail.com>, Roni Even <roni.even@mail01.huawei.com>, clue-chairs@ietf.org, clue@ietf.org
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
References: <154273841271.29820.17924219884246634745.idtracker@ietfa.amsl.com> <977036c6-db84-cb8e-c317-46d008e9a81b@comcast.net> <065E26A1-EDB6-4487-804F-882DF4F7101A@nostrum.com> <e1321782-7904-c904-93cc-5036880ef195@alum.mit.edu>
X-Mailer: Apple Mail (2.3445.101.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/clue/pZ48fQbR59wFqC_TGPVSYk3DpFs>
Subject: Re: [clue] Ben Campbell's No Objection on draft-ietf-clue-signaling-14: (with COMMENT)
X-BeenThere: clue@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: CLUE - ControLling mUltiple streams for TElepresence <clue.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/clue>, <mailto:clue-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/clue/>
List-Post: <mailto:clue@ietf.org>
List-Help: <mailto:clue-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/clue>, <mailto:clue-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Nov 2018 20:19:28 -0000


> On Nov 20, 2018, at 2:15 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
> 
> On 11/20/18 2:39 PM, Ben Campbell wrote:
>>> On Nov 20, 2018, at 1:34 PM, Paul Kyzivat <paul.kyzivat@comcast.net> wrote:
>>> 
>>> On 11/20/18 1:26 PM, Ben Campbell wrote:
>>> 
>>>> §4.5.1:
>>>> - What sort of user experience is expected when a CLUE device talks to a
>>>> non-CLUE device? Is this a realistic use case? (I'm not saying it's not; I'm
>>>> just asking.)
>>> 
>>> If the non-clue device is audio-only then you will get an audio call. If it is an audio/video device then you will get a basic audio/video call.
>>> 
>>> This can be entirely reasonable. For instance, if you have a clue-capable device on your desktop, you can use it for all of your calls. If the call is being originated from a clue-based conference room, inviting multiple clients, somebody in their car can be included in the call.
>> Okay, that makes sense. I wasn’t thinking about “desktop” CLUE devices, I guess.
>>> 
>>>> - "If the device has evidence that the receiver is also CLUE-capable,
>>>> for instance due to receiving an initial INVITE with no SDP but
>>>> including a "sip.clue" media feature tag,"
>>>>  Is it reasonable to remember CLUE support from previous sessions? I suspect
>>>>  the answer is  "no", due to SIP forking issues, but I think it's worth
>>>>  guidance one way or the other.)
>>> 
>>> This doesn't have to be from a prior session. The initial call may be an offerless invite (e.g., from a 3pcc controller). If the caller indicates support for clue then the callee can respond with an offer of a clue session.
>>> 
>> To be clear, I was wondering if remembering past sessions was an _additional_ way to “know” a peer is clue capable. In particular, if it’s not a good idea it would be worth mentioning that, because I suspect implementors might get creative in that particular direction.
> 
> There isn't any real harm in doing this. The worse that will happen is that the clue stuff is included in the offer and then rejected in the answer. So I have no problem with implementors getting "creative" here.

Okay. I am fine leaving things as is, unless the authors see value in mentioning the possibility.