Subject: [rtcweb] Use-case document

From: Stefan Hakansson LK <[email-masked]>
Date: Tue, 6 Mar 2012 10:28:31 +0100

Hi!

The Use-case document
(<http://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requirements/?include_text=1>)
will expire in early April.

The editors propose to add a new use-case when updating to -07. The new
use-case is about large sessions and is inspired by input made earlier
by Arno Bakker
(http://www.ietf.org/mail-archive/web/rtcweb/current/msg00530.html) and
recently by Harald Alvestrand
(http://lists.w3.org/Archives/Public/public-webrtc/2012Feb/0066.html).

Proposed text for the new use-case:

On-line lecture
===============

A lecture is given on-line by a very popular lecturer. The attendance is
very large. Because of this it is not really feasible to have
direct audiovisual feedback (for e.g. questions) for every participant,
instead participants can request the floor by clicking a button, and
gets a signal when audio and video has been set up (and the lecturer is
ready to take the question). The question is heard by all participants
(not only the lecturer).

Participants can join and leave the lecture at any time (i.e. they do
not need to be there at the start to be able to connect).

The service is operated by the university of the lecturer. It is set up 
such that all participants connect to a central node. The university can 
not invest much in HW, so the processing required (per participant) must 
be minimized.

New requirement:

- It must be possible to set up media streams and encryption in such a
way that processing in a central node is minimized (no transcoding
required, no decryption/re-encryption for every outgoing flow - just
simple forwarding).

Let us know what you think. If there is support we will add this 
use-case, if not we will just make a new revision of the document (with 
no major changes to the content).

Stefan for the editors

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 6 Mar 2012 05:01:12 -0800

Obviously, this is an interesting use case, but it's not clear to me that
it's something you would want to address entirely via WebRTC

1. It seems likely that the lecturer will be using something
rather more sophisticated than a Web browser in many cases
(often these lecturers are actually joint on-line and in-person
so you need microphone control in the room as well; see for
instance the popular Sandel Justice lecturers out of Harvard).

2. You also probably want to actually support not just real-time
viewing but also podcasting, time-shifting, etc., as well as
support for people who don't have WebRTC.

When you put these together, it might well be natural to have
a one-way stream via Flash, HTML5 video, etc., and then individual
WebRTC uplinks which get mixed into that single stream as necessary.
That makes questions about transcoding, re-encryption, etc. a lot
simpler.

-Ekr

On Tue, Mar 6, 2012 at 1:28 AM, Stefan Hakansson LK
<[email-masked]> wrote:
> The service is operated by the university of the lecturer. It is set up such
> that all participants connect to a central node. The university can not
> invest much in HW, so the processing required (per participant) must be
> minimized.
>
>
> New requirement:
>
> Let us know what you think. If there is support we will add this use-case,
> if not we will just make a new revision of the document (with no major
> changes to the content).
>
> Stefan for the editors
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Stefan Hakansson LK <[email-masked]>
Date: Thu, 8 Mar 2012 16:12:53 +0100

> That makes questions about transcoding, re-encryption, etc. a lot

I agree to that the use-case proposed was perhaps not that well selected 
for the reasons you give above.

What we were really after was to enable multi-party with really low cost 
for the central node (given that you're not doing a mesh). If you have 
to decrypt, alter RTP parameters, and then re-encrypt you quickly get 
into a situation where the central node needs a lot of processing power.

If the packets simply can be forwarded you're much better off - and this 
is what we wanted to capture. It is also a way to in the use-case and 
requirement document reflect a bit of what JSEP enables; if the 
application can *set* certain parts of the media settings used by the 
browser, the app can set it up such that central node would not have to 
alter anything - just forward. We thought it would be nice to have a 
JSEP related req in the document!

Stefan

---

From: Stefan Hakansson LK <[email-masked]>
Date: Tue, 20 Mar 2012 11:59:49 +0100

> JSEP related req in the document!

I hear no support for this, and will not add it to the use-case document 
at this stage.

Stefan