Re: [Wish] Lecturing and WebRTC

[Lorenzo Miniero <[e-mail]>]

On Tue, 09 Mar 2021 17:10:06 +0100
Juliusz Chroboczek <[e-mail]> wrote:

> 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.
> 


Hi Juliusz,

thanks for this very interesting overview and insight! I've added a
couple of notes inline.


> 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.
> 


Oh, I didn't know you were the author of Galene! Sean DuBois, the author
of Pion, shared the slides for a presentation you did on Galene on
Twitter a few days ago, which as a WebRTC server developer myself I
found quite interesting to read: I'll have to see if the video of the
presentation is available somewhere.


> 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.
> 


This last point is quite important, I think, and it also popped to my
mind while discussions on streams ordinality were going on during the
session. Being able to support multiple streams at the same time is
indeed desirable (Sergio made a compelling example there, with the
multiple languages), but the different lifetimes for different streams
assumes support for renegotiations. This means being able to update a
session after it has been started (however that will happen), and
something that can't be done on the client side alone (e.g., with a
replaceTrack). I'm not sure this is envisaged in Adam's proposal,
unless it should become part of the extensible mechanisms that have to
be defined? Assuming we want support for ICE restarts, some form of
renegotiations will need to be supported anyway (at the very least, a
new offer/answer round), but adding/removing media may go beyond the
simpler scope of this effort.

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.


> 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.
> 


I agree, and I don't think the spec will prevent you from doing that. I
think the main point discussed today was whether or not, as a WISH
client, you should be supposed to advertise those candidates, either
via trickle or as part of your SDP offer. Even if they're not, if your
WebRTC server is publicly reachable then it should still be able to make
use of them nevertheless, by discovering them via prflx candidates. 


> 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
> 


Thanks,
Lorenzo

-- 
I'm getting older but, unlike whisky, I'm not getting any better
https://twitter.com/elminiero