janus-plugin-sfu icon indicating copy to clipboard operation
janus-plugin-sfu copied to clipboard

Webinar with listeners only

Open vincentfretin opened this issue 4 years ago • 6 comments

Like I said in https://github.com/mozilla/janus-plugin-sfu/pull/74#issuecomment-777304112 We currently have in the code the process_subscribe to somewhat subscribe to a publisher without being a publisher yourself. This is something I'm interested in to have potentially a webinar with 1-5 publishers and 100 subscribers. Note that process_subscribe is not currently used in naf-janus-adapter, we use instead process_join with {media: occupantId} option to subscribe to occupantId. With https://github.com/mozilla/janus-plugin-sfu/pull/74 we don't count those users anymore for the max_ccu limit (previously based on sessions and not publishers) Hum process_subscribe is not doing all the checks with the jwt token like process_join is doing, it may be an issue. I think process_subscribe is maybe dead code, maybe we used that instead of process_join with {media: occupantId} in a previous version? And we can't currently use process_subscribe without knowing the occupantId that is returned in the response of using process_join as a publisher...

I'll use below "listener" to denote the user. A listener can have several subscription to publishers. A listener don't have a connection as publisher.

To develop the use case of webinar with listeners only, we need I think

  • a way to get the list of publishers' userid without having to join as a publisher, just an api to get the publishers in the room. (we still need to check jwt validity like we do in process_join)
  • be able to get the number of publishers and listeners (we can return it in the process_subscribe response, need to check jwt validity here too).
  • send event to publishers and listeners that a listener joined or left so we can maintain a counter of participants client side.
  • a listener can become a publisher later and come back to listener afterwards (for the case of a Q/A session).

For this case, chat is done via websocket, not datachannel of course.

vincentfretin avatar Feb 11 '21 09:02 vincentfretin

Comparing to the others solutions, this is somewhat similar to janus videoroom plugin I guess, but videoroom plugin is hard coding 5 publishers maximum (was 3 previously). Hubs moved to dialog/mediasoup and is able now to have a lobby with 75 subscribers in the lobby listening to the publishers' audio, and 24 publishers in the room.

vincentfretin avatar Feb 11 '21 10:02 vincentfretin

You're definitely right that currently the code assumes that every user will have a publisher which is sort of the "master" connection for that user, or else things don't make much sense.

This sounds like a fine idea, but I'm kind of hesitant to put a lot of work into it until the Janus multistream changes are live, because everything would change dramatically.

mqp avatar Feb 11 '21 22:02 mqp

(In general, once multistream is in, I'm open to doing a bunch of work to refit the plugin to your needs and to anyone else's needs who is interested in it, now that Hubs moved away from it -- it will depend on how much demand there is and how cool I think your projects are. But until then I am not really motivated to make big changes. Of course, in the meantime, I am happy to answer questions, help review any changes you make, etc.)

mqp avatar Feb 11 '21 22:02 mqp

I'm not asking you to do all the work @mqp :-) I'm glad you did all the changes recently and answered my questions. A big thanks for that! I want mainly to start a conversation here and see if there is an interest for others. If I really need it, I'll start to learn rust more seriously. ;-) I agree this use case can include some important changes. It depends of the use case, but having a publisher broadcasting in several rooms may have simpler changes and others are interested in it https://github.com/mozilla/janus-plugin-sfu/issues/55

vincentfretin avatar Feb 12 '21 09:02 vincentfretin

About my comment "And we can't currently use process_subscribe without knowing the occupantId that is returned in the response of using process_join as a publisher..." Not entirely true if you use an external users source like Phoenix Presence like it was the case for Hubs.

If you use an external users source, you can already use process_subscribe to have listeners only in the room and without security check if I understand it correctly.

vincentfretin avatar Feb 16 '21 08:02 vincentfretin

I confirm you can use today the subscribe message that will call process_subscribe and it doesn't check security, see my comment https://github.com/mozilla/janus-plugin-sfu/pull/81#issuecomment-822468168

vincentfretin avatar Apr 19 '21 13:04 vincentfretin

More detailed thinking about this use case in the PR https://github.com/networked-aframe/janus-plugin-sfu/pull/6

vincentfretin avatar Oct 23 '22 10:10 vincentfretin