[kwindla]

We're fans of webrtc-rs, but interop considerations pretty much mean that building on top of libwebrtc is necessary for our client libraries for now.

`daily-core` is signaling, the (always evolving) low-level trickery needed to scale calls to 10,000+ participants, state management, and an opinionated internal API that lets us efficiently maintain public-facing API features like track management, and device selection.

[mwcampbell]

Have you considered releasing your Rust bindings for libwebrtc separately, either as open source or as another commercial product? I could have really used that for a desktop application I started developing a few months ago. In the absence of such bindings, I went with Electron instead, reluctantly. And no, I don't think your high-level API would be a good fit; what I'm doing with WebRTC is too custom.

Edit: Also, webrtc-rs doesn't work for me either; AFAIK, it doesn't yet have enough of the media stack, including hard stuff like echo cancellation.

[Sean-Der]

You should help out with the gaps in the media stack! That is the only way it will get better :) I don't believe echo cancellation is a hard problem either. I don't know the specific details, but I have heard this argument so many times.

People told me that unless you were a developer at a big company you can't build DTLS, SCTP and RTP Congestion Control either. Maybe the community implementations aren't as good yet, but I think it is a tortoise vs hare.

[regexident]

> You should help out with the gaps in the media stack! That is the only way

As it happens I am the author of the audio-buffer and constraint-algorithm implementations in webrtc-rs/media: https://github.com/webrtc-rs/media/commits?author=regexident

So even though we are not using webrtc-rs in Daily today, we are (or at least I am) contributing to it, in hopes of it becoming a feasible option at some point.

[yolo3000]

Are there use cases for calls with so many participants?

[vr000m]

One thing to consider is if you would have One API and a few knobs to control the experience and not have to worry about the underlying protocol-, reliability-, latency- aspects to build that experience. (particularly not worry about the shenanigans around tuning RTMP, RTP, HLS, or webrtc)

There are some use-cases in every industry. * Finance/Company: earnings calls as mentioned before, all-hands meetings at companies (with several people queuing for questions and answers) * Live Events (music or talkshows) * Tutoring or education in general. * Healthcare and education -- Surgeries which are broadcast to several schools and have active collaboration from some doctors. The large-scale interaction can begin much earlier before the surgery.

[VWWHFSfQ]

People have started turning to webrtc for broadcast streaming (1->many) instead of hls/dash because of the lower glass-to-glass latency. But it has scalability problems which makes it enormously expensive comparatively. There are low-latency variants of HLS and DASH emerging now though

[dgunay]

WebRTC is some of the lowest latency streaming you can get, so I would imagine any realtime event with a large broadcasting audience would benefit. Interactive/2-way though, that's another story.

[tebbers]

Company earnings calls with analysts? Livestreams?