mumble-voip/mumble

Murmur's reaction on bandwidth limit violation

Open

#3784 opened on Sep 9, 2019

View on GitHub
 (2 comments) (1 reaction) (0 assignees)C++ (5,642 stars) (1,062 forks)batch import
feature-requestgood first issueserver

Description

Currently, murmur silently discards any packets from a client if the client has already used all its available bandwidth. This leads to interruptions of the audio from the client with no clue to the user about what is going on.

If a client does not behave well and ignores server's suggestion regarding the maximum allowed bandwidth (like Plumble does) the user will experience very lousy quality of audio and is likely to blame the overall technology while the real problem is just wrong client configuration.

I believe it'd be better to somehow inform the user that something wrong is happening.

There are two options I can think of:

  1. Send a text message to the user that bandwidth limit has been exceeded and the problem is probably with the configuration of the user's client software and maybe audio bitrate needs to be decreased manually.
  2. Disconnect the user with such a message.

Unfortunately, neither of the options is ideal. The first one will require some kind of rate limiting not to overwhelm the user with warnings. While the second, since there is no burst handling in BandwidthRecord, is probably prone to false positives that will also result in bad user experience if a user gets disconnected just because of network hiccups.

I personally like the second one better because otherwise a text message can pass unnoticed, but it surely needs to be implemented in some reliable way to avoid false positives.

Contributor guide

Tech stack
cpp
Domain
backendperformance
Issue type
feature
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
3
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
half day
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
stale
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
needs investigation
Prerequisites
C++ knowledgeUnderstanding of Mumble's bandwidth recordFamiliarity with audio packet handling
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
30
Research direction
Investigate the BandwidthRecord class in the server code to understand current burst handling and bandwidth limit enforcement. Consider implementing a rate limited text message warning or a reliable disconnect mechanism as discussed in issue comments. Evaluate false positive risks for disconnection during network hiccups. The issue has no linked PRs; a solution requires maintainer input on preferred approach.