26 karma · joined August 2, 2016
Lorenzo and his colleagues are doing a really great job.
In the space of SFU/MFU, one really needs to decide beforehand what kind of solution is suitable for which requirement. I have chosen Janus because we could integrate it by 100% in our software. For example, I was also looking into Jitsi. But compared to Janus it feeled so much more complicated and not suited for that specific job.
However, it is important to point out, that this is no a ready-to-go solution. There is a long list of things you will have to dig into:
- ICE (a way to connect if you switch between WIFI and LAN or to punch a hole into your fw) [2]
- Cross-browser compatibility (Thank you iOS [4])
- TURN/STUN (Which matrix of udp/tcp and ports is needed for Hole Punching?), I recommend coturn.
- Scalability: How many clients are planned? In my experience, CPU and bandwith are bottlenecks, we went with horizontal scaling
- How do you gonna test your WebRTC application? So far great results with https://testrtc.com, but you probably also could accomplish a lot with Selenium.
- Simulcast/Bitrate or Unified Plan (Use available bandwith and adapt on-the-fly) [3][5]
But once you got it running, it is an amazing feeling. We are in 2020 and it is possible for an SMB to offer video conferencing to customers via a web-browser using your own infrastructure while being compliant to GPDR and other stuff.
[0] https://webrtchacks.com/slack-webrtc-slacking/
[1] https://janus.conf.meetecho.com/demos.html
[2] https://webrtcglossary.com/ice/
[3] https://webrtcbydralex.com/index.php/2018/03/14/extending-ja...
[4] https://webrtchacks.com/guide-to-safari-webrtc/
[5] https://www.callstats.io/blog/what-is-unified-plan-and-how-w...
Oh well, you probably should use the rest api for generating credentials on the fly and think about scaling (depending on your needs).
From their background section: It is a fork of iText version 4, more specifically iText svn tag 4.2.0, which was hosted publicly on sourceforge with LGPL and MPL license headers in the source code, and lgpl and mpl license documents in the svn repository. Beginning with version 5.0 of iText, the developers have moved to the AGPL to improve their ability to sell commercial licenses.
I rather question, why do they store their binaries in mongodb? imho, s3 would be the perfect fit for that requirement.
I mean, it's just a plain server. No "cloudish" stuff, but I see people too often using expensive storages without really needing it...
The absolutely most basic advice is probably: "-Xmx" does not represent the actual upper limit for memory usage. We actually most often only set 50% of the assigend memory for the jvm.
Somebody mentioned https://github.com/cloudfoundry/java-buildpack-memory-calcul... which seems pretty interesting.
At least in my experience that is not true. I quite often run into this issue and the OOM-killer will only kill one of the processes inside the container, not the entire container.
>> The same is true for default memory limits. The JVM looks at the host overall memory and uses that to set its defaults.
Well, I guess if you launch a JVM anywhere without setting appropriate memory settings, you are doing something fundamentally wrong.
Anyways, thanks for your hint.