>For example as mumble uses a udp protocol it handles dropped frames badly, like on a spotty wireless connection. WebRTC also uses UDP—as well as virtually eve

>For example as mumble uses a udp protocol it handles dropped frames badly, like on a spotty wireless connection. WebRTC also uses UDP—as well as virtually every other real-time conferencing platform since the internet existed. TCP is too constraining to use for voice because every single packet retransmission only increases delay further. Dropping packets when they don’t arrive on time is necessary in order to minimize delay, which is one of the principal goals of Mumble. The real solution to dropped packets is not TCP—it’s a quality jitter buffer, and if you don’t like mumble’s performance in that respect then you need to look at the JB. A good JB will buffer and reorder packets within some statistical measure of network jitter, but the behavior is very explicitly not to retransmit. https://www.cs.columbia.edu/~hgs/rtp/faq.html#reliable https://www.cs.columbia.edu/~hgs/rtp/faq.html#reliable Google cheated with their implementation of WebRTC by purchasing Global IP Solutions, which gave them the most advanced jitter buffer in the world at the time: NetEQ. http://www.gipscorp.alcatrazconsulting.com/files/english/datasheets/NetEQ.pdf http://www.gipscorp.alcatrazconsulting.com/files/english/dat... https://chromium.googlesource.com/external/webrtc/+/master/modules/audio_coding/neteq/g3doc/index.md https://chromium.googlesource.com/external/webrtc/+/master/m...