Telegram generally handles low-bandwidth scenarios better than Jitsi for teleconferencing, particularly in practical real-world use on consumer devices and variable mobile networks.

Core Comparison on Low-Bandwidth Handling

Both platforms use adaptive mechanisms to cope with poor connections (dynamic bitrate adjustment, resolution scaling, audio prioritization), but their design priorities and implementation differ significantly:

• Telegram (native app video/voice calls, including group calls):

  • Built as a mobile-first messaging platform with aggressive optimization for emerging-market networks (intermittent 2G/3G/EDGE, congested Wi-Fi, metered data).
  • Very effective adaptive quality: drops to low-resolution video or audio-only quickly and smoothly when bandwidth drops below ~300–800 kbps.
  • Audio remains intelligible longer than most competitors even at very low bitrates.
  • Lower baseline overhead → calls stay connected and usable on connections where many WebRTC-based tools start freezing or dropping.
  • Group video calls (up to ~30 participants) degrade gracefully by reducing quality across the board rather than collapsing entirely.

• Jitsi Meet (WebRTC-based, browser or app):

  • Excellent theoretical bandwidth adaptation via simulcast, scalable video coding (SVC), and last-N forwarding (when using a videobridge).
  • In practice, especially on public instances (meet.jit.si) or lightly tuned self-hosted servers, it is more sensitive to packet loss, jitter, and upload limitations.
  • Users frequently report freezing, rapid quality drops to near-unusable levels, high latency, or disconnections on connections below ~1–2 Mbps symmetric, particularly with multiple video participants.
  • Browser-based nature adds overhead (CPU + decoding inefficiency on low-end devices).
  • Mobile app is better than browser, but still not as aggressively optimized for very constrained networks as Telegram.

Quick Reference: Low-Bandwidth Winner by Scenario

Practical Tuning Tips for Each

• Telegram: Usually "it just works" on low bandwidth. If needed, disable video early or use voice-only.
• Jitsi: Force lower defaults (e.g., via config: start with 180p, disable HD, enable "low bandwidth mode" if available, use speaker view instead of tile view, mute non-speakers). Self-host + tune videobridge helps a lot more than public servers.

If your typical teleconferencing happens on mobile data, spotty hotel Wi-Fi, or developing-region networks, Telegram is the safer bet for staying intelligible and connected. For privacy-focused or highly customizable group meetings where you can control the server and educate participants to turn off video early, Jitsi can be made to perform acceptably — but it requires more effort.

If you're designing monitoring/logging around this (bandwidth spikes, packet loss patterns, adaptive bitrate decisions), Telegram's proprietary nature makes deep RF/spectral analysis harder, while Jitsi (open WebRTC) lets you capture and dissect negotiation/RTCP reports much more precisely with tools like Wireshark or custom WebRTC stats logging.