Real Time Communications Bits

Last week there were many messages in the coturn issue tracker about TURN instances being blocked by some cloud providers because it was detected that those servers were being used to attack other hosts. This is not new as Wire had already reported it and even suggested a mitigation some months ago. The attacks being carried out in this case are based on two properties of TURN servers: Reflection : A TURN server, by design, sends the responses to the TURN messages to the source IP of the Request. If an attacker is able to change his source IP address (spoofing) then it can direct the response of his TURN request to any other host he wants. Amplification : TURN responses are usually bigger than the corresponding requests. This is especially problematic for authentication error responses that must include a NONCE value to be used to attempt authentication properly based on the standard authentication defined in the protocol. We can see a real example of the second property in a commer...

Google Meet has consistently delivered superior quality among WebRTC applications (at least for web applications). This is especially true compared with typical open-source solutions, but it stands even for most commercial solutions. The reason is that Google has the team that understands the media stack they have built very well and can make it behave in ways that solve their problems in the browser with knobs hidden in WebRTC that only they are aware of. Some of us still remember how simulcast support was added to WebRTC approximately 12 years ago with SDP munging and without any documentation or note behind the x-google-conference flag, or how “Audio Network Adaptation” was added with a secret string encoding an undocumented protobuf schema to tune settings to improve audio quality. Today I was trying to debug why a WebRTC application had a less stable bandwidth estimation than Google Meet. The scenario was quite simple: in a perfect network with plenty of bandwidth, add 50ms of ex...