[Wish] Lecturing and WebRTC

[Juliusz Chroboczek <[e-mail]>]

Hi,

At today's meeting, I made a few comments about the difficulties we
encountered at the Université de Paris (formerly Paris-Diderot) when
trying to teach during lockdown.  I was asked to give a few details on the
list.

Every lecture is different, but I have found that our online activities
can be roughly categorised in 4 groups:

1. Recorded lectures

   The lecturer records a video that they put on a web server.  No
   protocol beyond HTTP and the HTML video element is required.

2. Large online lectures

   The lecturer is streaming their lecture to 60 to 400 students.  The
   students interrupt to ask questions over textual chat.

3. Small online lectures

   A dozen students in a videoconference

4. Practicals

   Students distributed in groups of 2 to 4 people, with the lecturer
   moving from group to group.

It seems to me that (2) is almost within the scope of the WISH working
group.  Until now, we've been mostly using Zoom, BigBlueButton and Galène
(https://galene.org) for this use case (for some reason, Jitsi doesn't
seem popular); a WISH protocol would be a welcome addition to this kind of
software, especially if native WISH clients are readily available.

We encountered the following requirements which might or might not be
similar to the requirements that the other participants in this WG are
familiar with.

1. Multiple streams

Most lecturers like to stream multiple media at the same time.  I, for
one, tend to stream no less than three video streams:

  - my webcam;
  - my slides (PDF);
  - a virtual blackboard (I use a painting program, while a lot of my
    colleagues use dedicated virtual blackboard software).

Note that the different streams might have different lifetimes: the
lecturer might start with just their slides, then switch their virtual
blackboard on when they get asked an interesting question.

2. Firewalls

A lot of undergrad networks were built in the 1990s, and while the
hardware and software have been rotated multiple times, the firewall
policies are still adapted to Windows 95.  In extreme cases, the networks
are not connected to the Internet at all, and all traffic to the Internet
must go through a manually configured HTTP proxy (Squid, usually).  In
some cases, there's a transparent HTTP proxy.  It is sometimes possible to
get an (IP, port) whitelisted, it is generally not possible to get a whole
IP whitelisted.

As to the WiFi networks available to the students, they usually allow
traffic to just a few outgoing ports.  In practice, I have found the
firewalls to be configured to comply with the minimum requirements of the
Eduroam service definition -- please see page 32 of

  https://www.eduroam.org/wp-content/uploads/2016/05/GN3-12-192_eduroam-policy-service-definition_ver28_26072012.pdf

To me, this implies the requirement that either TCP TURN or ICE-TCP be
supported.

3. NAT

A lot of students use 4G or the university WiFi, and are therefore behind
multiple layers of NAT.  While these NAT devices are fine for checking
wikipedia, their behaviour wrt. UDP tends to be erratic.  For example,
I have seen a single media session roam over 5 different externally
visible IP addresses (!) while the associated WebSocket remained stable.

This, to me, implies the requirement that media transports be
renegotiated, using either an ICE restart or some other mechanism.

Regards,

-- Juliusz