Re: [Wish] Lecturing and WebRTC

Adam Roach <adam@nostrum.com> Tue, 09 March 2021 17:53 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 7C1CA3A14AA for <wish@ietfa.amsl.com>; Tue, 9 Mar 2021 09:53:41 -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 N0qXoiXUdYWS for <wish@ietfa.amsl.com>; Tue, 9 Mar 2021 09:53:40 -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 E83733A14A8 for <wish@ietf.org>; Tue, 9 Mar 2021 09:53:39 -0800 (PST)
Received: from [172.17.121.48] (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 129Hrc23044743 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 9 Mar 2021 11:53:39 -0600 (CST) (envelope-from adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1615312419; bh=NjeKynYQGdlxUHA/I133/VLo8VDNiCK8spJD4qEqogo=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=HnKpUiT5VF0nQPNjE9PlmZ4i4yejB04xaVJS2RRhnNHfqVrCO99CsTPmQZ3YqCb4C ZawHQgmECYUx5jgTnT7vhRXF6BAlpdngotq43ZHBvWivEUVdEw54NdeWAjKKqMtOzT SXWzOZLGCZny5tI3RkpdPrVICr3C2Das85Vg1tJU=
X-Authentication-Warning: raven.nostrum.com: Host 76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253] claimed to be [172.17.121.48]
To: Juliusz Chroboczek <jch@irif.fr>
Cc: wish@ietf.org
References: <874khktijl.wl-jch@irif.fr> <20210309173757.576dea4e@lminiero> <e70f461e-b895-e656-09e0-7388d87bd28b@nostrum.com> <87tupkrzyk.wl-jch@irif.fr>
From: Adam Roach <adam@nostrum.com>
Message-ID: <4f89511a-2304-ada6-4e6d-5f485e4c6828@nostrum.com>
Date: Tue, 09 Mar 2021 11:53:31 -0600
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1
MIME-Version: 1.0
In-Reply-To: <87tupkrzyk.wl-jch@irif.fr>
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/8Rzewfqj5jovYaff8-Ku7MgyHOs>
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:53:42 -0000

On 3/9/2021 11:36 AM, Juliusz Chroboczek wrote:
>> 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'm rather fond of concrete use cases, so I try to think about it in the
> following terms: will I be able to usefully broadcast a lecture over WISH?
> If the feature is just convenience, it can go into an extension; if the
> lack of the feature prevents me from doing my broadcast, then I'd like it
> to be mandatory.
>
> If the lecturer adds a stream to their lecture, and some WISH clients
> don't support the functionality, then I'm pretty much stuck, amn't I?


Your described use case includes three streams, which is one more than I 
would have imagined necessary. From that perspective, the chance that 
the broadcast client of your choice will support all the streams that 
you might want seems a bit slim -- for example, I can't imagine OBS 
including support for sending three video streams in the near future, 
since it's fundamentally different than how it's architected today.

On the other hand, if we take Sergio's proposed direction -- where the 
ingest network provides you, as a broadcaster, with multiple endpoints 
-- then it provides you the ability to fire up multiple broadcast 
clients, on different devices if you want, and to direct them to the 
different endpoints as you see fit. Even better, this saves us from the 
difficulty of having to map each video stream in the SDP to its intended 
semantics: you, as the broadcaster, get to hook your whiteboard up to 
the whiteboard endpoint, your camera up to the camera endpoint, and your 
slides up to the slide endpoint.

To make this concrete, for the lecturer service you've described, I 
would imagine that each lecturer is given three URLs. Yours would look 
something like this:

https://example.org/jch/whiteboard

https://example.org/jch/camera

https://example.org/jch/slides

Then you could start up three broadcasting clients, each configured with 
the correct of these three URLs.

Even better: assuming a certain level of success for WISH, maybe you 
have a hardware whiteboard that supports WISH output, and maybe your 
preferred slide generation tool (e.g., OpenOffice, Powerpoint, Keynote) 
lets you do a "share via WISH" option. If we divide things up how Sergio 
has described, then you can just put the correct URL in the correct 
thing, and they all go to the right place, without having to somehow 
coordinate through the tool that you're using for your camera broadcast.

The more I think about it, the more appealing this simplified approach 
is to me.

/a