Re: [Wish] Lecturing and WebRTC

Adam Roach <adam@nostrum.com> Tue, 09 March 2021 17:15 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: wish@ietfa.amsl.com
Delivered-To: wish@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB363A1415 for <wish@ietfa.amsl.com>; Tue, 9 Mar 2021 09:15:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.081
X-Spam-Level:
X-Spam-Status: No, score=-2.081 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com
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 hV0ciqOTk5j1 for <wish@ietfa.amsl.com>; Tue, 9 Mar 2021 09:15:43 -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 EE78F3A1117 for <wish@ietf.org>; Tue, 9 Mar 2021 09:15:42 -0800 (PST)
Received: from Zephyrus.local (76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 129HFdpc036174 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 9 Mar 2021 11:15:39 -0600 (CST) (envelope-from adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1615310140; bh=UFKRdqj+Ujw69KbCBhUHN3/pXjlUPftiOX12bSJZfYM=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=iDO+0d248ahUCtpFh8z07XGoWUEh19RKFn6TI3JeQO0xvl6ve1MzFGNXAsxHaZzGo PvApEYAc4pVyUoReFQ4e5wcdcBoq/4kA0BQxSCejxx9SdtTWPANiD2jLfTzOjbzLQF rsoiv6q4t8aWQHOf0geiAKzTeunMFS6GmqHB6FHk=
X-Authentication-Warning: raven.nostrum.com: Host 76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253] claimed to be Zephyrus.local
To: Lorenzo Miniero <lorenzo@meetecho.com>, Juliusz Chroboczek <jch@irif.fr>
Cc: wish@ietf.org
References: <874khktijl.wl-jch@irif.fr> <20210309173757.576dea4e@lminiero>
From: Adam Roach <adam@nostrum.com>
Message-ID: <e70f461e-b895-e656-09e0-7388d87bd28b@nostrum.com>
Date: Tue, 09 Mar 2021 11:15:33 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0
MIME-Version: 1.0
In-Reply-To: <20210309173757.576dea4e@lminiero>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/wish/gRYQhHwKnlcNqNdSYnuAvr01WTo>
Subject: Re: [Wish] Lecturing and WebRTC
X-BeenThere: wish@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: WebRTC Ingest Signaling over HTTPS <wish.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/wish>, <mailto:wish-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/wish/>
List-Post: <mailto:wish@ietf.org>
List-Help: <mailto:wish-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/wish>, <mailto:wish-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Mar 2021 17:15:46 -0000

On 3/9/21 10:37, Lorenzo Miniero wrote:
> In this case, it seems simpler to push streams which are supposed to
> have different lifetimes as separate "broadcasts", that the application
> layer can tie together, even though this means losing the ability of
> having everything on the same PeerConnection. I don't have an answer or
> an opinion here: just pointing out that it looks like renegotiations
> will need to be discussed.


This is actually closely related to a number of the use cases that I 
have in mind, where I want to be able to tie multiple sessions together, 
both for the kinds of scenarios that Juliusz lays out, as well as 
sessions originating from entirely different endpoints. From that 
perspective, having a way to associate different sessions with each 
other somehow seems far more flexible (this is in large part why the 
"conferencing" analogy comes to mind when thinking about extensions). I 
was going to leave this off as something we can define in a future 
extension; but if we're trending towards including it as base 
functionality, I don't have any objections to adding it in.

/a