search

max-mapper / screencat

:cat2: webrtc screensharing electron app for mac os (Alpha)
http://maxogden.github.io/screencat
BSD 2-Clause "Simplified" License
3.01k stars 383 forks source link

WebRTC signalling improvements #12

Open max-mapper opened 9 years ago

max-mapper commented 9 years ago

right now we use trickle-less SDP swapping through a custom lobby signalling server.

it would be better to use ICE/STUN, but in general I was displeased with the state of many of the signalling servers on npm, which is the main reason I made https://github.com/maxogden/cat-lobby. if someone can recommend a simple signal lobby that can do ICE/STUN then I would be happy to swap out the backend

it would be cool to use TURN, though I need to figure out a way to measure failure metrics first before investing in higher bandwidth infra like that

DamonOehlman commented 9 years ago

It's not that you aren't using ICE it's just that when you are using a trickle-less solution, you need to wait for all the candidates to be gathered before you can exchange the SDP. So you can definitely specify STUN/TURN servers as needed, it will just take longer to negotiate a connection.

I completely get what you are saying re signalling servers, as I think one of the things that we are all getting wrong is going straight to using websockets as the transport layer. Only very recently did I pull the internals out of rtc-switchboard into pretty much a lighter implementation of what it means to have peers exchanging messages in a room: rtc-switch.

I'm certainly not offended that cat-lobby was created, and I doubt that &yet folks are either, but I'm sure we are all interested in what it is that you would like out of a signalling server to better meet your needs (and those of your feline companions).

/cc @fippo

max-mapper commented 9 years ago

@DamonOehlman great points! I am on my phone now but will try and do some thinking about ideal API. also @feross let me know that his module simple-peer has a hardcoded STUN server in it, so screencat is already using STUN (which explains why it works at all lol)

fippo commented 9 years ago

@DamonOehlman there is a number of reasons we switched away from socket.io, node and non-existent json-signaling protocols for the talky beta. Such things are cool if you want to build a demo, but for running things in production...

fippo commented 9 years ago

@maxogden signaling servers have nothing to do with STUN, TURN and ICE. At most, they can vend temporary credentials. See http://hancke.name/webrtc/berlinjs/#/ for some pointers from a talk I gave at berlinjs last year.

You'll also soon notice that @janl is always behind a firewall :-)

DamonOehlman commented 9 years ago

@fippo Yep, scalable, production-ready signalling is a different beast entirely, and definitely a conversation for another thread - probably in the @webrtcftw org :)

max-mapper commented 9 years ago

@fippo ah, thanks for the clarifications, it seems I conflated relay and signaling. So "signaling" is just an arbitrary word people use to describe a 'lobby'? there isn't a spec/protocol for 'signaling'? Just trying to get my jargon correct :D

fippo commented 9 years ago

signaling is what people use for the two sides of the signaling triangle (shown in http://hancke.name/webrtc/berlinjs/#/24) that are connected to the signaling server.

signaling (or session establishment) is part of what happens there, but there might be alot more things happening here (such as chat). Basically it's an exchange of structured text in some kind of "chat" protocol. Problem solved since 1990.

ICE (and all things stun/turn) happens on the bottom side of the triangle that connects the two peers. That is the hard part (https://docs.google.com/presentation/d/17mVv6_eKqLkKkG-pwx_p-NOrYl2CK02OAtAtcHKJgHU/edit#slide=id.p4 shows how complex it can get) but ideally you don' t have to worry about the details. It is a big concern for UX in the end, but I can't show the slides until I gave a talk on that ;-)