Hi,
The main issue here is that you are probably running out of juice in your machine for that. Nevertheless, as we have quite often commented, that tutorial is flawed: concurrency issues mainly, probably not the best handling of resources, no duplicated user control... As a tutorial/demo, it fulfills the requirement to showcase the capability of multiconference. As a tutorial, it's not a production-ready app.
Just for the sake of curiosity, I ran this demo on my machine, with 5 clients in the same browser (which add more load to the CPU), and KMS local. It's an i7-quad core, with 8GB of RAM. I left it running for about 1h, and after that checked the load, which was oscillating between 50%-60% in all cores. Curiously enough, htop reports that most of the CPU is consumed by Chrome, which could be expected, as there are 25 RTCPeerConnections in there right now. Here are the results, with the KMS process sitting comfortably in the 6th place, behind the five tabs that are running 5 peer connections each. Actually, using 5%-10% CPU less than those threads. I've also attached a screen recording, so that you see that the video is still working fine (there is a spike at the end, probably produced by the screen recording itself)

Taking both aspects into account (processor and application), I don't think that saying "video calling is not working in KMS6" is accurate, just because a tutorial in a consumer-grade PC doesn't meet the specs of a full-grade production-ready app. It's simply not fair. There are many factors involved, and the main one in your case, as we've also commented in many other threads, is CPU. WebRTC is a quite CPU-hungry thing, since it has to encrypt-decrypt the media streams, so you've probably reached the limits of your hardware.
So how could reports be helpful?
- Please use headlines that describe the problem (as you would do with bug reports): something of the like "Video freezes in dual-core i3 with 3 clients in group-call" would be more accurate.
- Test it on a different machine: i3 probably does not have the juice to handle more clients. Take into account that you'll be having n^n streams, where n is the number of clients. That's probably a lot to handle your dual-core processor. If you've seen reports from other similar servers in the market, tests are run over quad core Intel Xeon, dedicated servers. Kurento can do many things, but certainly not turn a consumer PC into a server-grade machine.
- What else is running in the system?
- How is the system connected? Is it wifi or ethernet? Are all clients in the same network?
- How long ago did it start to happen? Which version where you using? You say that you are facing the problem since last couple of weeks. What changed then? Was it an update of the package, or something changed in your setup? Maybe updates in other packages in the system?
- Know the limits of your system. Build a test app that stresses the environment where you are going to install your solution. Check how much load each webrtc adds to your system, and then you'll know what the limits are.
- Prepare a testbed for other users to be able to test the limits of their systems.
- Profile the process during a period of time, and report the load when there are problems.
Some of this information might be already on the thread, but it's a bit scattered. Providing an accurate bug report from the beginning will help us analyze and diagnose the problem faster, as keeping track of different threads with information scattered in it is quite hard, and sometimes we can mix things up, or skip important parts as it was in this case with the i3 processor.
Cheers,