IETF Logo Mail Archive

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

Paul Kyzivat <pkyzivat@alum.mit.edu> Tue, 20 November 2018 20:15 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 2601B130E2A; Tue, 20 Nov 2018 12:15:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 tHbKZE1paVTL; Tue, 20 Nov 2018 12:15:21 -0800 (PST)
Received: from alum-mailsec-scanner-5.mit.edu (alum-mailsec-scanner-5.mit.edu [18.7.68.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9479B130E70; Tue, 20 Nov 2018 12:15:18 -0800 (PST)
X-AuditID: 12074411-57bff70000007049-1d-5bf46b552dc0
Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id A4.77.28745.55B64FB5; Tue, 20 Nov 2018 15:15:17 -0500 (EST)
Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id wAKKFFqE024673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 20 Nov 2018 15:15:16 -0500
To: Ben Campbell <ben@nostrum.com>
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
References: <154273841271.29820.17924219884246634745.idtracker@ietfa.amsl.com> <977036c6-db84-cb8e-c317-46d008e9a81b@comcast.net> <065E26A1-EDB6-4487-804F-882DF4F7101A@nostrum.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <e1321782-7904-c904-93cc-5036880ef195@alum.mit.edu>
Date: Tue, 20 Nov 2018 15:15:15 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <065E26A1-EDB6-4487-804F-882DF4F7101A@nostrum.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA02Sb0gTcRzG+d2d2zl2cp7KflnOHPRmNrVSGWnlC6FBfzClXswwT3duw+1m d5tor0SFVKLMKOaUDFKh6RsVw5FiLiZpIZhIf6BSGolCxKYjrWndudS9e+D5PM/Dj98XR6mB mGTczNoZjqUtKokMo6SFaZqr1RulWUuNR7U9rW+k2lBHr0Q7ObuAaoc86dqf74YRrTN8H9X6 mzfRAqnO4/os1fX2biG6sZGlGJ3L48eKML0s38BYzLUMl3m2XGZq+OWX1jjJuq/BMGgAQXkb wHFIZsOHXn0biMUpcgqBQz5TRC8jsCVQJOoEUg9Xx1elok4kVXClaRQTNUp+BDAQPNMGZAI/ BuDc6gAQDQmpht3ev7sQQZ6DjZODElFj5DEYbn+/yySRVXC7tRdEmHg40+nf5WMFfu7HChoZ yIWPR5b/awX85O9BIjoVNo12oe2AdEXFXVERV1TEFRV5AjA3UNIWh1Vjpc0WnqnU8JU0yzKc JifDarZnMAbHMIj8QPwYcM4ovYDEgUpOlCdslFIxdC1fb/WCQziiSiIK+tdLqbgKm6HeRPOm G5zDwvBeAHFUlUjMqQWcMND1txjOtmcdxjGVgkCzJ/QUaaTtTDXD1DDcnnsEx1WQWL4kBOM5 xsjUVZkt9gMbwWPFcrlQ7hMZgq+hrbzZGPFnwSl8PNToRHG3s8WJUhhrY5lkBZEkoqSImhzs ftveja0BhfC4BCLlskDJhQvc71sTphBhKuXtujhlpw+s5AZw8rSP6kr13NseU1+bd8fkFlqf 9zU/Nd+ZyTQOdiBU907mVr5k6mbw0eYIQnwJcp0t4fmAr2x69OXEYmHW99fedD2tTJWFTPLF Z/3D35T0Dnu8ONYie5WTJ9u8GHchwNptodt5D6Z/X6fdxQsv7vaVfaiY0v1BPSVXSvLSzqsw 3kSfUKMcT/8D4vjujD4DAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/clue/OzoFhp4Frx00HKHRTFudw5neEDo>
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:15:28 -0000

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.

	Thanks,
	Paul

v2.23.0 | Report a Bug | By Email