OpenVidu: Open-source, multi-platform, WebRTC videoconferences | Hacker News Reader

OpenVidu: Open-source, multi-platform, WebRTC videoconferences

openvidu.io

187 pointssupdatecron24 comments

I wonder how these compare to Jitsi and BigBlueButton. I've been using the hosted Jitsi instance at "meet.jit.si" and have been self-hosting bigbluebutton and both have been rock solid.

Since twilio acquihired the kurento team, it barely got any updates, while the webrtc spec and implementations move fast. So I'd definitely stick with a jitsi based solution, which is way more modern and getting regular updates.

can you build a new app on top of jitsi?

That's very nice to hear, it must mean that we're doing a good job in Kurento, given that BigBlueButton internally uses Kurento for media streaming ([1]), just like OpenVidu does :-)

[1]: https://docs.bigbluebutton.org/2.2/architecture.html#kurento...

The open-source variant does not support P2P sessions if I understand it correctly, which is weird since that is half the point of WebRTC.

Yeah, I'm a little confused about this as well. It's also not clear if the demos can be used as is. I would use this for an ad-hoc meeting with friends if there's no restrictions. Given that they don't mention it maybe that's fine? I'd be willing to go through the steps to set this up on my own server, but why do I need to if this site already provides everything I need?

The demos run over a shared instance of a server with fixed resources, so I wouldn't count on it being the most stable experience, especially if it becomes popular enough to saturate the machine's resources.

The intention of these demos is just to provide a showcase of the types of applications that a developer might be able to build, using OpenVidu.

It says "without a media node", when you hover over the info or "i" icon next to P2P.

Yeah, which implies that the free version routes all media over the server (a media node), hence it not being P2P.

Not sure if you are agreeing with what I said or not?

I am just as confused honestly.

even for P2P, WebRTC most often still requires outside servers for STUN/TURN, because everyone's behind a NAT of firewall.

IIRC most large scale deployments have it at around 75-95% of traffic that only requires STUN (which is only used for the handshake & holepunching, not for the actual traffic). TURN is used for the remaining 25%-5%.

STUN is cheap, easy and does not require a lot of traffic. TURN on the other hand requires a lot of bandwidth, which can be expensive.

Thing is, while WebRTC per-se is a nice standard for p2p, the actual limitations of technology (i.e. bandwidth) in the real world mean that sessions with 4 or more participants become unusable very quickly as the number of people increments.

So, 99% of "serious" use cases end up requiring a centralized relay, anyway.

Tsahi Levent-Levi covered this topic: https://bloggeek.me/how-many-users-webrtc-call/

The problem with all of these is that different browsers such as firefox and safari have trouble with negotiating connections.

For example we built the software we use on https://intercoin.org/meeting or any website. It works across safari on ios and chrome and we even made a workaround for webviews:

https://mobile.twitter.com/qbixapps/status/11564841564250398...

But the sdp connections between the browsers fail and A can hear B but C can’t. Weird.

Zoom or Google Hangouts doesn’t have such issues because they always assume one specific environment. Cross browser videoconferencing is not easy

But hey ours is open source and not locked into Twilio or these guys:

https://github.com/Qbix/Platform

Search for the string WebRTC

Can you describe why in some cases one cant hear the other peer? There are different sdp versions if i remember correctly but if you only use audio and video without changing the tracks later on it should work perfectly i guuess.

Here is what our developers said a week ago:

Hi. I learned logs of your meeting where there were problems with peer connections. I couldn't reproduce the bug in real-time for now, I'll continue to debug tomorrow. Some conclusions: - problems with peer connection were happening between Firefox <-> Safari ("Mikki" was using Firefox); - first time (on the beginning of meeting) bug was caused by error In Safari while adding video to peer connection - this interrupted negotiation process: Failed to execute 'setLocalDescription' on 'RTCPeerConnection': Failed to set local offer sdp: Failed to set local video description recv parameters So, Firefox-user didn't receive any video from two Safari users. I googled error, there are very few explanations like a problem with codecs, but I think the bug depends on who was the initiator of peer connection as next time (after reconnections) this error wasn't happening (the similar bug is between Chrome and Firefox). - the second time, the bug was happening only between Firefox (Mikki) and Mobile Safari (Alexandra). This case is less clear for me as the negotiating process wasn't interrupted, but peer connection between these users was failing int several seconds after it was established.

This looks perfect for a project I've been planning for a while, but the way the pricing works seems dangerous to base a small company on. They're pricing it per minute per core (even if idle), as if it's a service - except that they're not providing the service, I am. I'd much rather pay a flat fee than never know how much I'll have to pay.

If they want to charge for use, fine, charge ACTIVE time, not UPtime. Running a single dual-core EC2 instance should be no different than running a 10-core dedicated server at 20% load.

This has been our first approximation to pricing, and I agree with you, it has its shortcomings. We are aware of it and recognize it's not the ideal method of charging users.

Changes on the pricing are on the table now, we'll keep studying different options and change if something makes more sense than what we have right now.

Hi there, I'm Juan, main developer of Kurento Media Server. I'll try to contextualize here what is OpenVidu and where it comes from.

Kurento [1] is a WebRTC server which you deploy in your cloud and then control through another application server, of which OpenVidu is one. While Kurento tries to provide generic building blocks to allow creating multiple types of applications, OpenVidu started as a project that builds on top of those capabilities and focuses on the most commonly requested use case: videoconference rooms.

From that initial premise, the amount of tasks to do in order to achieve a professional solution seems endless: easy configuration of producers and consumers, with roles and permissions; automatic scaling when the load requires it; dynamic distribution of media flows according to the needs; recording of the sessions; compatibility with different browsers, and also why not, with apps on mobile platforms; filtering the media to apply video effects; the list goes on.

Then, problems will happen. And troubleshooting WebRTC issues is difficult, because information is all disperse and nebulous, so one is expected to have all the tools in place beforehand to inspect logs and be able to have an explanation of why something went bad.

OpenVidu aims to provide an easy to use framework that can cover all those needs and then some. Its open-source part covers all the basics, and for the last months we've been working on the Pro offering, which tackles the targets of automatic scalability, session monitoring, and automatic instantiation of Kurento Media Server nodes to handle different amounts of sessions (i.e. "elasticity"), among other things. Some of the features listed in the Pro page [2] are ready for prime time, and some are a work in progress.

We just released OpenVidu version 2.12.0 [3], which is where a new license version for the Pro tier sees the light. Our team has been for quite a long time in the game of WebRTC, working and learning together with the open-source community while developing Kurento, and now I hope you find that OpenVidu is a nice value proposition and it helps you build your dream application!

It's late here but tomorrow morning I'll be hanging around here to answer any questions. See you!

[1]: https://www.kurento.org/

[2]: https://openvidu.io/docs/openvidu-pro/

[3]: https://medium.com/@openvidu/openvidu-2-12-0-a-new-chapter-f...

Please, please fix https://github.com/OpenVidu/openvidu-call/issues/26 as this is the only thing blocking us from actively using it or even thinking about "going" pro.

Hi, we have just set this on top of the OpenVidu Call roadmap. We'll fix it soon.

Another interesting open source software is Jami https://jami.net/

I'm using it and I'm quite happy with it.

How ready is this? I'm asking because a friend who volunteers in a charity is looking for something that would allow her to have a large video conferencing group, perhaps around 20-40 people. With it being a charity, their budget is usually zero. I don't really have any experience with this kind of thing and couldn't really give her a recommendation, but perhaps this is a possible solution.

Either I misunderstood the calculations or this is much more expensive than Twilio

Reply on news.ycombinator.com