Re: [Wish] Lecturing and WebRTC

[Lorenzo Miniero <[e-mail]>]

Hi Juliusz,

a few more notes inline.


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

> Hi Lorenzo,
> 
> May I have an autograph, please?
> 


:-)


> > shared the slides for a presentation you did on Galene [...]  I'll
> > have to see if the video of the presentation is available
> > somewhere.  
> 
> The slides are here:
> 
>   https://galene.org/galene-20210222.pdf
> 
> The raw video footage is here, but it's a mess (400MB tarfile, one
> unseekable WebM per stream):
> 
>   https://galene.org/galene-20210222.tar
>


Thanks! Unseekable works for me, I plan to watch it all :-)

 
> > but the different lifetimes for different streams assumes support
> > for renegotiations [...] In this case, it seems simpler to push
> > streams which are supposed to have different lifetimes as separate
> > "broadcasts",  
> 
> Yes, you could carry each stream within a separate session.  But it
> does still imply the need to renegotiate something, either the set of
> streams or the set of sessions.
> 


Yes, in this case I was talking about renegotiations on a specific
ongoing session: if you're creating a new one to start slides after you
already started your webcam, this is not touching other sessions that
existed already, but will be a completely separate one. As such, an
easier problem to solve than actually updating an existing session.


> > this means losing the ability of having everything on the same
> > PeerConnection  
> 
> You lose a few UDP ports, and exchange a few extra packets with your
> STUN server.  Am I missing anything?
> 


There may be more resources used on both client and server side in
general, but yes, more ports needed and additional overhead would be
the main "issues".


> > I think the main point discussed today was whether or not, as a WISH
> > client, you should be supposed to advertise [relayed] 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.  
> 
> I'm not sure I follow.  Suppose you're on an Eduroam network, so the
> only outgoing traffic allowed is TCP/443 and TCP/1194.  You run your
> signalling server on 443, your TURN server on 1194.
> 
> Since the client cannot reach any UDP ports, how is it going to learn
> about the TURN server on port 1194 if it's not signalled explicitly?
> 
> -- Juliusz


No matter how you talk to the TURN server (TCP or TLS), the TURN server
itself will normally talk to the WebRTC server via UDP (once you tell
it which address to interact with, which you'll know from the SDP
answer in this case), acting as a media relay for you. As such,
assuming the server is publicly reachable, your client doesn't need to
do any UDP, it just needs to talk to the TURN server somehow: even if
you don't advertise those relay candidates, the TURN server will send
connectivity checks to the WebRTC server on your behalf, and since the
credentials in the STUN message are correct, the server will know that
the address it just received the check from is a potential candidate
for communication. These candidates discovered at runtime are called
"peer reflexive candidates", and are what would make the session work
even without any candidate in SDP/trickle.

Lorenzo

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