Various wrote:
And this represents a very big sacrifice of resources in the connection? My problem with jitsi so far has been that it does not work very well if either end has a bad internet connection, which is more or less common in Latin America.
We hope to be layering on end-to-end encryption features, and would happily take community contributions.
I don’t believe the encryption/decryption is all that resource intensive in comparison to the encoding and decoding of the video and audio streams themselves.
We have a few features to try to deal with this, including audio-only mode and the ability to send lower-quality video (Low bandwidth mode)
One thing many voice and video apps get wrong is shipping with defaults set to what in bandwidth terms effectively amounts to 4kHDR 60fps video + CDDA audio. It cannot be made any more clear that this is completely unnecessary for servicable comms, and does not establish good thinking or expectations. Even just a fraction of 160x120 4-bit video and 8k audio works fine. Wannabe conferencers today are brainwashed by BluRay and Gaming out of what is actually possible within a 56kbps channel or less... https://en.wikipedia.org/wiki/CU-SeeMe All you need is just enough to lip and ear sync to the video and audio. Cranking your codecs way down also saves you much needed bandwidth for more peers, file transfers, messaging, signaling, integration, crypto, other applications, etc... making world a happier place. With as little as 1Mbps you could be conferencing 8 fully meshed (no hub) independently encrypted peers. If sensible defaults, and crazy minimums, aren't offered, the promising freedoms of non-third-party-in-the-middle P2P conferencing are that much harder to meet.
I do know we suffer from poor performance on connections for which packet loss/packet drops are common.
It is nature of beasts, of time, of being confined to intermediate MAC+PHY layers, choose your evil... TCP imparts pauses, UDP zaps the gap... physics deny a general solution. Explore random encrypted ultra wideband spread spectrum guerrilla RF via SDR if you want to make use of some interesting and alternative channel physics. Also consider routes over I2P, Phantom, Tor, and other overlay networks. CU-SeeMe... "The predominant objective here was to devise algorithms that would be fast enough for real time videoconferencing on the typical Macintosh platforms that were available in mid-1992, which mainly consisted of 68020 and 68030 based machines." -- Tim Dorcey, Cornell University.
From Connexions, Volume 9, No.3, March 1995
"Milazzo, Paul. Informal demonstration of dvc at the December 1991 meeting of the IETF in Santa Fe." https://www.youtube.com/watch?v=o4h6oElcOtI https://www.youtube.com/playlist?list=PL96B30F6A04A29427 https://www.youtube.com/watch?v=Rz-YHbQ2dA4 https://www.youtube.com/watch?v=HDBOIdmkdEw