41–49 of 49 posts
Some signaling strategies for WebRTC: - WebSockets - XHR and other Comet options - SIP over WebSockets - XMPP/Jingle - WebRTC's Data Channel Obviously, one would want the data channel (last option). There's some work done in this area. However, it's still not full featured.
Whoops turtles..
Whenever these threads pop up I always ask: is there an erlang/elixir implementation anyone knows about? I check every couple of months and come up empty (there is one closed source one.) Being able to speak WebRTC natively to a Elixir/Phoenix cluster would be a pretty killer app, but the hurdle to get there is quite high.
Whenever these threads pop up I always ask: is there an erlang/elixir implementation anyone knows about? I check every couple of months and come up empty (there is one closed source one.) Being able to speak WebRTC natively to a Elixir/Phoenix cluster would be a pretty killer app, but the hurdle to get there is quite high.
In terms of communications between client and server, I'm not sure what you get with WebRTC that you don't get with websockets? What's your intended application?
Earlier quoted context omitted.
Yeah, that is possible but my point is that it sorta breaks how people are used to join these kinds of meetings. The back and forth required is not the expectation most people have. If you have more people then you'd need to do this once per person, (after that they can gossip the SDP over data channels to find the other participants). Usual flow: 1. I and other people go to meet.example/DiscussImportantStuff Your pr…
Indeed that makes sense! Curious though if the "signalling server" can be abstracted away the same way STUN servers are: put a few URLs of signalling servers in the client app and it would choose whichever. They would all need the same echo'ing capabilities. Point is to not maintain or have to spin up any servers for developing WebRTC apps, but making them fully autonomous. Something like this could also be pushed fo…
1. How can you trust trust if it is established over an untrusted channel and you have no previous store of trust?
2. How can you verify identity when you have no trust and it is communicated over an untrusted proxy (the signaling server)?
STUN/TURN plays no part in establishing the trust between the parties, they just facilitate it by acting as an lookup service or a forwarding service. The signaling has to be trusted for the communication to be trusted.
--- Original comment: ---
One problem is that signaling is pretty specific to the app using it, for example how a meeting is determined and how it is used is very different between zoom, google meet, slack and so on. There is also a question of trust, in a P2P webrtc flow you can have end-to-end encryption, but it still requires you to trust the signaling (since you have no way to communicate trust before signaling).
For purposes where you have a previous channel to communicate trust you probably don't need signaling via a third party and for purposes where you don't have a channel you probably couldn't trust the signaling party if it was just an open relay on the net.
For the "free signaling server" to be a good solution it would first have to handle the problem of proven identity, which is something that even facebook with billions of users have a problem with.
DHT solves a very different problem than identity, the problem is not being able to speak/address to a user, the problem is being able to speak to the right user. WebRTC provides a channel to do that if you point it to the right user. Our problem is finding that right user in a secure, smooth way.
What are the best resources to learning WebRTC at the minute? It seems to be a pretty fast moving area, a lot of what I find out there is outdated.
https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API
For landscape, I also like the webrtchacks.com blog, and a very smart consultant runs a blog at bloggeek.me.
I'd like to stream high-quality, low-latency audio from a C++ app alongside webcam/mic from chrome/firefox. The receiver should get video and a mixed blended audio. Maybe even screenshare and mouse/keyboard control. Is this possible?
Earlier quoted context omitted.
In terms of communications between client and server, I'm not sure what you get with WebRTC that you don't get with websockets? What's your intended application?
For game-related use cases, we need to be able to specify which data is reliable and which isn't. Websockets use TCP which doesn't give you that control.