You'll escape that by getting specialized hardware. There's just too much broken stuff on the PC. (There was once that thing that become widespread, people used to call them "telephones". Nobody has them anymore, what's a shame.)
Anyway, I don't really get what problem WebRTC solves, except for the non-problem of having to run specialized software on the clients. Instead it adds another set of broken mic settings...
you should try zoom or bluejeans, it's been extremely stable and consistent for us, we do conference calls from behind china's great firewall to palo alto with little to no lag, even has HD video.
Zoom won't really help you with the above situation which is mainly users having their microphones disabled etc.
We're building a virtual classroom solution and we now always force every user to go through a wizard which checks their audio and video, clearly marks when there is no sound being received and connects them to a support person to help them resolve their AV issues before they can join the meeting.
It's a little annoying for the person who wants to join, but the experience for the people already in the meeting/classroom is much better.
We are currently testing with some early customers and now about to go broader. We only sell to universities though, so it's hard to demo. Here's an article with more info from one of our customers that gives you a look into the product: https://awaytolearn.iese.edu/ieses-virtual-room-online-learn...
One interesting part is that, just like in a real classroom, by default everybody is unmuted. So you can have discussions with 80 students and one or multiple teachers. This makes stuff like echo cancellation, reducing the noise floor etc. a big part of the problem we attempt to solve.
Which ISP do you use? I have friends in Beijing who use Zoom for video meetings (including screen sharing), but they still use regular phone to do the audio part, as they've found audio unreliable. (This is with China Unicom.)
China telecom at home and probably china unicom + china telecom for the office. Audio and video work fine for me, even if it's on the 4g network. Note that my company forked over money for enterprise licenses which maybe the difference here, i think the qos is a lot higher with enterprise license.
I'm working on a project that requires consuming a UDP video stream from the browser. Because of the near real time latency requirements, I think a WebRTC is the correct solution, but every time I start reading about it, I get overwhelmed by all these acronyms like STUN, TURN, ICE, etc.
Does anyone have suggestions for good learning paths for WebRTC?
quick summary of the acronyms... STUN/TURN/ICE are all related to NAT traversal (ie. when you are behind a router or firewall of some kind and your computer's IP is different from your public IP). The reason you need this is because UDP is not connection-based like TCP. So STUN is a service that helps your computer find its public IP. ICE is a protocol for finding and reporting peer candidates (after they've learned their public IPs via STUN) so they can establish a peer-to-peer connection. TURN is when you reflect the connection off a public server instead of establishing a peer-to-peer connection.
SDP is session description...basically information on what media formats and other things each client will accept.
RTP is how the media (or other data) packets are framed
RTCP is out of band reporting for things like packet loss and other info so that each side can adjust media properties
The nice thing about WebRTC is it takes care most of this stuff for you. If you're always connecting to a server with a public IP you'll just need a few things:
1) WebRTC server that can accept media data (like janus or aiortc)
2) Some signalling mechanism, Websockets work well for this
3) you _may_ need a STUN server, google has stun servers available but you could also use coturn for this.
The rest you shouldn't need to worry as much about because webrtc handles it all under the hood
"ICE tries to find the best path to connect peers. It tries all possibilities in parallel and chooses the most efficient option that works. ICE first tries to make a connection using the host address obtained from a device's operating system and network card; if that fails (which it will for devices behind NATs) ICE obtains an external address using a STUN server, and if that fails, traffic is routed via a TURN relay server." (1)
Turn just proxies all the data instead of being p2p. p2p has to overcome NAT, which is why ice and stun exists. If it can't be p2p it'll be turn.
"STUN servers live on the public internet and have one simple task: check the IP:port address of an incoming request (from an application running behind a NAT) and send that address back as a response. In other words, the application uses a STUN server to discover its IP:port from a public perspective." (1)
It also took me several years to get up the gumption to actually learn WebRTC after having previously used wrapper libraries...
And it is annoying, but you can get the stab of it within a week or two. The most confusing thing is figuring out setRemoteDescription vs setLocalDescription - that took a bunch of playing around to finally get it to work.
All said and done, we were able to write a WebRTC adapter in less than 100LOC[1], and it is capable of doing inter-network signaling once peers have established connections. And the "signaling servers" that bootstrap non-WebRTC peers, those servers themselves can be decentralized as well.
If you don't want to deal with the fuss of it all, I highly recommend using EasyRTC, and/or studying their code to learn more:
I felt similarly when I’ve looked into it in the past. My suggestion is to just take a day or two and do a deep dive, use tutorials and it will all get better. Maybe not what I would have wanted to hear but after crossing the chasm to where I understand those things now it doesn’t seem like it was too much. It was just more than I expected from what I saw as a simple browser feature. The thing is that there is a lot to p2p communication when you consider local networks sharing the same up address, firewalls etc... Not just that but how to fallback when someone is behind a network that essentially blocks p2p. WebRTC is somewhat of a low level API that lets you navigate these waters but it expects you to do more work than I initially expected.
If you are more interested in a plug and play solution I’ve heard good things about https://tokbox.com/
As for Toolbox, unfortunately there isn't any good competition in the market. Tokbox is "the best" (though I wouldn't say "great").
Their pricing model is better than most. It's not the cheapest, but it's worth the service quality. The low intro price seems deceiving, but I think it's pretty good because a lot of really basic, proof of concept apps can work on that range and not break the bank. You won't find anything much cheaper for the whole kit and caboodle.
A bunch of these vulnerabilities are the result of iterator invalidation in C++. Food for thought for those who claim that iterator invalidation doesn't happen in modern idiomatic C++.
Low latency video streaming in the browser is a mess. it's WebRTC or [insert hack]. WebRTC is kind of a single-purpose black box, so it's difficult to deal with. I Would love to know more about how people are solving this problem (like Zoom).
Works better than LifeSize! I've been relatively non-angry with Zoom which is at least some form of success. I also like that we can download missed meetings that we're recorded and I can play them in my player of choice (yay, 2x speed!).
We've tried several video conference solutions. Google hangout was nice for up to 10 people. Then it get really slow and the quality of the video decrease. It also do not work in China (need a VPN).
By far, the best one is Zoom. It can easily handle with a really great quality 25 people on 1 page, in a conference with 80+ people. It also works smoothly for people in China (without VPN). Anyone has any know the magic behind their tech?
Anybody with the number can join your Zoom meeting and since there's very little indication of their presence you might not even notice. You can also command other people's rooms to join your meeting, if you can figure out how to contact them, and you can force their microphones to turn on, which in my opinion is pretty disturbing.
You'll escape that by getting specialized hardware. There's just too much broken stuff on the PC. (There was once that thing that become widespread, people used to call them "telephones". Nobody has them anymore, what's a shame.)
Anyway, I don't really get what problem WebRTC solves, except for the non-problem of having to run specialized software on the clients. Instead it adds another set of broken mic settings...
you should try zoom or bluejeans, it's been extremely stable and consistent for us, we do conference calls from behind china's great firewall to palo alto with little to no lag, even has HD video.
Zoom won't really help you with the above situation which is mainly users having their microphones disabled etc.
We're building a virtual classroom solution and we now always force every user to go through a wizard which checks their audio and video, clearly marks when there is no sound being received and connects them to a support person to help them resolve their AV issues before they can join the meeting.
It's a little annoying for the person who wants to join, but the experience for the people already in the meeting/classroom is much better.
Zoom actually does some neat things, like detecting audio problems and attempting to fix them automatically (on Mac it restarts CoreAudio I think).
Is the product you are building out already?
We are currently testing with some early customers and now about to go broader. We only sell to universities though, so it's hard to demo. Here's an article with more info from one of our customers that gives you a look into the product: https://awaytolearn.iese.edu/ieses-virtual-room-online-learn...
One interesting part is that, just like in a real classroom, by default everybody is unmuted. So you can have discussions with 80 students and one or multiple teachers. This makes stuff like echo cancellation, reducing the noise floor etc. a big part of the problem we attempt to solve.
Which ISP do you use? I have friends in Beijing who use Zoom for video meetings (including screen sharing), but they still use regular phone to do the audio part, as they've found audio unreliable. (This is with China Unicom.)
China telecom at home and probably china unicom + china telecom for the office. Audio and video work fine for me, even if it's on the 4g network. Note that my company forked over money for enterprise licenses which maybe the difference here, i think the qos is a lot higher with enterprise license.
I'm working on a project that requires consuming a UDP video stream from the browser. Because of the near real time latency requirements, I think a WebRTC is the correct solution, but every time I start reading about it, I get overwhelmed by all these acronyms like STUN, TURN, ICE, etc.
Does anyone have suggestions for good learning paths for WebRTC?
https://github.com/jlaine/aiortc may be a better option than janus. It's a much simpler to use implementation and is python.
quick summary of the acronyms... STUN/TURN/ICE are all related to NAT traversal (ie. when you are behind a router or firewall of some kind and your computer's IP is different from your public IP). The reason you need this is because UDP is not connection-based like TCP. So STUN is a service that helps your computer find its public IP. ICE is a protocol for finding and reporting peer candidates (after they've learned their public IPs via STUN) so they can establish a peer-to-peer connection. TURN is when you reflect the connection off a public server instead of establishing a peer-to-peer connection.
SDP is session description...basically information on what media formats and other things each client will accept.
RTP is how the media (or other data) packets are framed RTCP is out of band reporting for things like packet loss and other info so that each side can adjust media properties
The nice thing about WebRTC is it takes care most of this stuff for you. If you're always connecting to a server with a public IP you'll just need a few things:
1) WebRTC server that can accept media data (like janus or aiortc) 2) Some signalling mechanism, Websockets work well for this 3) you _may_ need a STUN server, google has stun servers available but you could also use coturn for this.
The rest you shouldn't need to worry as much about because webrtc handles it all under the hood
This might be helpful for your project https://janus.conf.meetecho.com/
Yeah, Janus is excellent. Just get it running in a local network and head scratch about ICE, STUN, etc. only if a firewall is needed.
"ICE tries to find the best path to connect peers. It tries all possibilities in parallel and chooses the most efficient option that works. ICE first tries to make a connection using the host address obtained from a device's operating system and network card; if that fails (which it will for devices behind NATs) ICE obtains an external address using a STUN server, and if that fails, traffic is routed via a TURN relay server." (1)
Turn just proxies all the data instead of being p2p. p2p has to overcome NAT, which is why ice and stun exists. If it can't be p2p it'll be turn.
"STUN servers live on the public internet and have one simple task: check the IP:port address of an incoming request (from an application running behind a NAT) and send that address back as a response. In other words, the application uses a STUN server to discover its IP:port from a public perspective." (1)
[1] https://www.html5rocks.com/en/tutorials/webrtc/infrastructur...
It also took me several years to get up the gumption to actually learn WebRTC after having previously used wrapper libraries...
And it is annoying, but you can get the stab of it within a week or two. The most confusing thing is figuring out setRemoteDescription vs setLocalDescription - that took a bunch of playing around to finally get it to work.
All said and done, we were able to write a WebRTC adapter in less than 100LOC[1], and it is capable of doing inter-network signaling once peers have established connections. And the "signaling servers" that bootstrap non-WebRTC peers, those servers themselves can be decentralized as well.
If you don't want to deal with the fuss of it all, I highly recommend using EasyRTC, and/or studying their code to learn more:
https://github.com/priologic/easyrtc
[1] https://github.com/amark/gun/blob/master/lib/webrtc.js
I felt similarly when I’ve looked into it in the past. My suggestion is to just take a day or two and do a deep dive, use tutorials and it will all get better. Maybe not what I would have wanted to hear but after crossing the chasm to where I understand those things now it doesn’t seem like it was too much. It was just more than I expected from what I saw as a simple browser feature. The thing is that there is a lot to p2p communication when you consider local networks sharing the same up address, firewalls etc... Not just that but how to fallback when someone is behind a network that essentially blocks p2p. WebRTC is somewhat of a low level API that lets you navigate these waters but it expects you to do more work than I initially expected.
If you are more interested in a plug and play solution I’ve heard good things about https://tokbox.com/
Looks good but $500/month to enable basic security features for a $9/month service? That's not really how you do either marketing or security...
Here to parrot GP. I had the same experience.
As for Toolbox, unfortunately there isn't any good competition in the market. Tokbox is "the best" (though I wouldn't say "great").
Their pricing model is better than most. It's not the cheapest, but it's worth the service quality. The low intro price seems deceiving, but I think it's pretty good because a lot of really basic, proof of concept apps can work on that range and not break the bank. You won't find anything much cheaper for the whole kit and caboodle.
WebRTC is utter garbage.
Go look into a license for Camfrog Web, if it's still even sold.
> Facebook, WhatsApp, FaceTime and Signal are just a few of the many ways that users can make audio and video calls across networks.
I find it interesting that they don't mention Hangouts, given that they're, well, Google Project Zero…
Maybe they listed the highest market share? I didn't look but I wouldn't be suprised if these have the biggest. In order, too.
Or maybe they just listed the ones they use. If I did the same, it would look _very_ similar.
Maybe they want to be beyond suspicion of self-dealing.
A bunch of these vulnerabilities are the result of iterator invalidation in C++. Food for thought for those who claim that iterator invalidation doesn't happen in modern idiomatic C++.
Low latency video streaming in the browser is a mess. it's WebRTC or [insert hack]. WebRTC is kind of a single-purpose black box, so it's difficult to deal with. I Would love to know more about how people are solving this problem (like Zoom).
Zoom's solution seems to be clunky software that works worse than Jitsi.
Works better than LifeSize! I've been relatively non-angry with Zoom which is at least some form of success. I also like that we can download missed meetings that we're recorded and I can play them in my player of choice (yay, 2x speed!).
We've tried several video conference solutions. Google hangout was nice for up to 10 people. Then it get really slow and the quality of the video decrease. It also do not work in China (need a VPN).
By far, the best one is Zoom. It can easily handle with a really great quality 25 people on 1 page, in a conference with 80+ people. It also works smoothly for people in China (without VPN). Anyone has any know the magic behind their tech?
Zoom doesn't use WebRTC (which the article is about). They use websockets to send media through the pipes and decode using a webgl shader or similar.
I don't work for Zoom, but do work in the WebRTC space and read an article about it recently.
Gotta link for that? Sounds really neat
https://webrtchacks.com/zoom-avoids-using-webrtc/, perhaps?
Zoom has to be using h264 under the covers. Did they recompile the OpenH264 into WASM?
like: https://github.com/kazuki/mediacodec.wasm
It could also be that they are using websockets to deliver MPEG-DASH/HLS segments for low latency.
Anybody with the number can join your Zoom meeting and since there's very little indication of their presence you might not even notice. You can also command other people's rooms to join your meeting, if you can figure out how to contact them, and you can force their microphones to turn on, which in my opinion is pretty disturbing.
> in a conference with 80+ people
are that kind of meetings really useful by videochat ? Even in real life it's a pain.
That use case is primarily one way - think "CFO presents the latest quarterly results to employees".
Like Twitch/Youtube Live, except with access control :)
GSuite customers can use Hangouts Meet, which should be better.
A good testability lesson. The project had used fuzzing, but due to complexity nobody had figured out how instrument it for deep coverage.
(Aside from the obvious one that you shouldn't write protocol implementations in unsafe languages... WebRTC is too new to have a legacy excuse even)
FB Messenger calls work the best for me.
Hangouts and Zoom second best.
Worst has been Skype and WhatsApp.
But Skype has been getting better the last months.