3000 concurrent users?

1,110 views
Skip to first unread message

Guillermo Castillo

unread,
Oct 1, 2019, 10:18:24 AM10/1/19
to discuss-webrtc
Hypothetically speaking, if I wanted to broadcast by webrtc from one to many viewers, with 3000 concurrent users listening with a smartphone.
What characteristics should my infrastructure have?

Harald Alvestrand

unread,
Oct 1, 2019, 10:25:28 AM10/1/19
to discuss...@googlegroups.com
What's your delay budget? Do you require <low number of milliseconds> delay, or can you tolerate delay of minutes?
What's your bandwidth availability? What's the geographical distribution of the viewers?
What's your tolerance for costs?

There's no one answer for all cases.


On Tue, Oct 1, 2019 at 2:13 PM Guillermo Castillo <gis...@gmail.com> wrote:
Itectically speaking, if I wanted to broadcast by webrtc from one to many viewers, with 3000 concurrent users listening with smartphone.
What characteristics should my infrastructure have?

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/29737e69-8bcd-4fd8-81cb-ade69e599ec3%40googlegroups.com.

Guillermo Castillo

unread,
Oct 1, 2019, 10:50:15 AM10/1/19
to discuss-webrtc
for example considering a hypothetical stage of a concert, with 5GB bandwidth on a local network, using WebRTC for a minimum delay,
Remember that users will use their compatible smartphone.

El martes, 1 de octubre de 2019, 11:25:28 (UTC-3), Harald Alvestrand escribió:
What's your delay budget? Do you require <low number of milliseconds> delay, or can you tolerate delay of minutes?
What's your bandwidth availability? What's the geographical distribution of the viewers?
What's your tolerance for costs?

There's no one answer for all cases.


On Tue, Oct 1, 2019 at 2:13 PM Guillermo Castillo <gis...@gmail.com> wrote:
Itectically speaking, if I wanted to broadcast by webrtc from one to many viewers, with 3000 concurrent users listening with smartphone.
What characteristics should my infrastructure have?

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss...@googlegroups.com.

Silvia Pfeiffer

unread,
Oct 1, 2019, 8:34:29 PM10/1/19
to discuss...@googlegroups.com
You might want to check out:
https://www.wowza.com/low-latency/webrtc-streaming-software
https://www.pubnub.com/blog/webrtc-live-video-stream-broadcasting-from-one-to-many/
and a couple more companies that are offering these services.

Cheers,
Silvia.
> To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/160fdde9-1fed-4f3c-87cf-8ebc7d0e53e0%40googlegroups.com.

Alexandre GOUAILLARD

unread,
Oct 2, 2019, 4:29:28 AM10/2/19
to discuss...@googlegroups.com
maybe not wowza, as they advertise "less-than-3-seconds" and they do not support most of webrtc in their implementation, 
but companies like millicast.com or phenix real-time systems propose PaaS for the use case you seem to be looking for. 

there are also server companies if you want to go down the route of building a platform and operating it yourself, but as harald say, there are a lot of use cases, and without answers to the questions he asked, it s difficult to guide you.

Give us more info / answers to harald question, and we will point you to the best match we know.





--
Alex. Gouaillard, PhD, PhD, MBA
------------------------------------------------------------------------------------
President - CoSMo Software Consulting, Singapore
------------------------------------------------------------------------------------

Neil Young

unread,
Oct 2, 2019, 4:32:55 AM10/2/19
to discuss...@googlegroups.com
I can suggest Kurento.


We have it running here


It is not your use case (one to many) and 640x480 is for sure not your target resolution, but behind all that is a free KMS server in the Amazon cloud. 



Lorenzo Miniero

unread,
Oct 2, 2019, 4:41:00 AM10/2/19
to discuss-webrtc
I addressed this scenario in my (Janus-related) presentation at CommCon last year, so linking it FYI:


Lorenzo
> To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/160fdde9-1fed-4f3c-87cf-8ebc7d0e53e0%40googlegroups.com.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss...@googlegroups.com.


--
Alex. Gouaillard, PhD, PhD, MBA
------------------------------------------------------------------------------------
President - CoSMo Software Consulting, Singapore
------------------------------------------------------------------------------------


--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss...@googlegroups.com.

Guillermo Castillo

unread,
Oct 2, 2019, 5:58:59 AM10/2/19
to discuss-webrtc
What's your delay budget? 
It's just curiosity, there's no hurry, I was wondering if you could do a silent concert, with this technology (webrtc)

Do you require <low number of milliseconds> delay, or can you tolerate delay of minutes?
A minimum delay since it is a live show (100 to 300 milliseconds)

What's your bandwidth availability? 
Available bandwidth will be 5Gbps

What's the geographical distribution of the viewers?
the viewer will be in a space of 2000 m2

What's your tolerance for costs?
Regarding the budget, as an example I would like some estimate on this.

I have used wowza webrtc and I have reached only 180 concurrent users, the others experience signal cuts or simply disconnect.

I hope I have answered your questions well.

regards

El martes, 1 de octubre de 2019, 11:25:28 (UTC-3), Harald Alvestrand escribió:
What's your delay budget? Do you require <low number of milliseconds> delay, or can you tolerate delay of minutes?
What's your bandwidth availability? What's the geographical distribution of the viewers?
What's your tolerance for costs?

There's no one answer for all cases.


On Tue, Oct 1, 2019 at 2:13 PM Guillermo Castillo <gis...@gmail.com> wrote:
Itectically speaking, if I wanted to broadcast by webrtc from one to many viewers, with 3000 concurrent users listening with smartphone.
What characteristics should my infrastructure have?

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss...@googlegroups.com.

Tsahi Levent-Levi

unread,
Oct 2, 2019, 6:29:26 AM10/2/19
to discuss...@googlegroups.com
Hi,

My thoughts on this:

  • WebRTC is usable for your requirements
  • With 5 Gbps, I'd aim for 600-800kbps per participant if you plan on reaching 3,000. Networks are finicky and trying to get the most out of them usually backfires
  • If this is audio only, then you're fine (you'll be at 30-60kbps range without any video)
  • I'd suggest against using Wowza. Their WebRTC solution is partial at best and fails miserably in the real world over live networks
  • For an "in-room" experience, install your own servers at the location. Going from the cloud to a concert place and pumping all that data in after sending the data towards the cloud to begin with seems unhealthy to me
  • If you're after an open source alternative, then look at Janus (mentioned here already), Kurento (mentioned here already) and mediasoup
  • If you're after a commercial off the shelf server, like Wowza, but with better WebRTC support for broadcast, I'd go with either Ant Media or Red5 Pro
  • Millicast is cloud based, but I am sure Alex (who suggested it) will be happy to customize and install it for you locally if needed
  • If you're still going with cloud, then also look at TokBox and Agora.io
  • For cloud, Phenix, Ant Media, Millicast, Red5 Pro, TokBox and Agora are all possible alternativs. Each has its own advantages and downsides

  --
Regards,
Tsahi Levent-Levi
Analyst & Consultant

Want to get more of your WebRTC sessions effectivly connected? Enroll to my free video course: http://bit.ly/32Y3qZK





To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/1c6759ad-3d5a-4bc5-ba1e-7830ee7a7d5a%40googlegroups.com.


--
Regards,
Tsahi Levent-Levi
Analyst & Consultant

Want to get more of your WebRTC sessions effectivly connected? Enroll to my free video course: http://bit.ly/32Y3qZK

Harald Alvestrand

unread,
Oct 2, 2019, 7:20:31 AM10/2/19
to discuss...@googlegroups.com
You're probably also looking for a hierarchical redistribution solution, so that you don't have a single computer pumping out 3000 streams of audio. Might want to have one redistributor per access point in your 5G network (I'm assuming that you're using 5G, since I don't think you can get 5 gig of bandwidth inside a single enclosed space on any wifi-based technology).

Radio spectrum management is probably going to be your most fun challenge.


Alexandre GOUAILLARD

unread,
Oct 2, 2019, 7:57:21 AM10/2/19
to discuss...@googlegroups.com
As mentioned, we have a commercial PaaS solution called millicast.com and we have been actively pushing the boundaries of streaming for a couple of years now. As far as we know, we are the only ones who have benchmarked most of the existing solutions out there, and published some results. With Phenix RTS, we are the only ones with a PaaS based on webrtc and solely design for the streaming use case. Our infrastructure is based on the Medooze media server, but single server, or naive clustering of webrtc servers do not work for streaming at scale.

@ neil
Kurento does seems to behave much worse under load than the others. The project also seems to be less active than one would like:

@guillermo
That study above was done in the Video conferencing use case (many to many). We also did the benchmarking for the streaming use case, and we seem to get the same results you did with wowza. Specifically, you can see on the slide #32 of our presentation at the Live streaming West 2018 conference that when wowza server gets saturated, instead of adapting like it should (slide #31), it is just dropping connections.
https://www.slideshare.net/alexpiwi5/streaming-media-west-webrtc-the-future-of-low-latency-streaming

If you want a state of the art of webrtc in streaming, you have the more recent presentation at Live Media East:

in short:

= services =
- you have traditional video conferencing services that can be used for streaming even though they will be suboptimal for that especially in terms of scalability. For limited number of viewer, and if you re not on premises, it can be a choice: tokbox, agora.io, twillio, ....
- you have specialised streaming services, with dedicated design, and features (server-side ad-insertion, DRM, RTMP ingest, HLS egress,  ...): phenix RTS and millicast.com
- you have non-webrtc based low latency services (based on websocket mainly): nano cosmos.

= Servers =
- you have traditional VoIP servers that support webrtc: kamailio, opens, free switch, asterisk, ....
- you have "webrtc native" video conferencing servers (as opposed to flash): jitsi, Janus, [Kurento], [licode], Mediasoup, OpenWebrtcToolbox (intel), ...
- you have hybrid media server toolbox: medooze
- you have traditional flash servers that supports webrtc:  wowza, red5, and ant5.

Note that for the traditional flash servers, red5 is using a modified version of jitsi, and ant5 is using a modified version of red5. They also do clustering and not smart routing / streaming, so their capacity to scale is somehow limited. (That touches on harald comment on hierarchical topology of media servers.). Janus and its RTP-forwarding feature works better out of the box.

for delays between 0 and 1 second, prefer a webrtc solution; 1 to 3 seconds, websocket or wowza's webrtc (as per their marketing material), more than 3 seconds, you might want to use flash or HLS/MPEG-DASH if possible with a CMAF container.

for an on-premises, a few thousands viewers, small resolution, on a single location, almost everything will work. red5 and ant5 servers have an on-premises free version, an on-premises paid version, and a hosted version as well. If you're OK with Java, they are usually the starting point for streaming to small audience.

While the media servers will be adequate, beware of the delivery network, as harald mentioned. Test on site with someone wireshark-proficient :-)

hope this helps. 

On Wed, Oct 2, 2019 at 12:29 PM Tsahi Levent-Levi <tsahi.le...@gmail.com> wrote:

Maffin Tosh

unread,
Oct 2, 2019, 8:33:39 AM10/2/19
to discuss...@googlegroups.com
Actually as mentioned here I am loking for an audio-only solution but not constraint geographically as the owner of the posts cade but global, so, keeping everything same as the original post case but those what would be the situation?

Alexandre GOUAILLARD

unread,
Oct 2, 2019, 10:40:49 AM10/2/19
to discuss...@googlegroups.com
audio is simpler,
bandwidth will not be  problem, but throughput can (as harald said, managing that many small packets can be challenging for your NIC).
any of the server mentioned in the previous post, on a recent machine should do.

If you look at  the load testing study on webrtc hacks, it's organised by rooms of 7 people. Each full room generates 49 streams (let s take 50 for simplicity). So if you take the inflexion point in the load testing bitrate per number of participants curve, you will see it happens when the number of participants is roughly 280. 280 participants means 40 rooms, which in turn means the media server is handling 40 * 50 = 2000 streams.

That is with audio + video, so audio only should not be a problem as far as CPU and Bandwidth is concerned. 

happy benchmark.

Reply all
Reply to author
Forward
0 new messages