It is pretty easy to get a one way trip time for packets that is sub-second! You see it with conferencing and other real-time communication things.

If you are curious on the 'how' of WebRTC I wrote a Free/Open Source book that goes into the details https://webrtcforthecurious.com/. Happy to answer any particular questions you have.

Man... I've been up all night, traveling all day, trying to adjust to the new timezone. Boy, I swear I read "sub-millisecond". Lol. Makes sense :) Thanks for the resource!

Bookmarked.

I added WebRTC support (audio, video, chat) to my already existing application a couple of years ago and felt the technology wasn't exactly ready for primetime. To me, it felt like the out of the box developer experience wasn't exactly great.

I am only saying this because I got to see exactly how much effort is required to get things going. Your work is greatly appreciated

You are a legend.

Why shouldn't it be possible? Screen share on a Zoom/Teams meeting is basically a stream with sub-second latency.

most connections today are subsecond... a second is a lot of time.

also this is probably only taking California as the whole world, like everyone does.

I have less latency to California than most Bluetooth headsets have to your ears.

WebRTC attempts to set up a direct connection between the streamer and the receiver so packets are being sent over directly. This doesn't always work out, say if there's bad connectivity (e.g. NAT) somewhere so the connection uses a TURN server or if there's a conference call situation where an SFU is involved, but usually it works.

I ran into a situation yesterday where it doesn’t even work between two devices on the same wifi network. It very much depends on the particulars of your connection.

SFU?

SFUs, or Selective Forwarding Units, receive media streams from multiple participants but only forward a subset of those streams to certain participants. For example, if you're in a Webinar of 20 people, instead of opening up direct connections to all 19 other participants (and having every other participant do so as well), you can open up a direct connection to the presenter and an SFU which will send you an aggregated, downsampled stream of all the other participants. It reduces direct connections across large calls and saves on processing power across all participants by aggregation.

Then there’s STFU, which mutes all participants to save data on audio.

It just means the overhead is smaller for the feature set it offers. It’s not faster than bare MJPEG over UDP, but not way slower than that either.