Webinar with listeners only

[vincentfretin]

Like I said in #74 (comment)
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 #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]

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.

[mqp]

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]

(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.)

[vincentfretin]

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 #55

[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]

I confirm you can use today the subscribe message that will call process_subscribe and it doesn't check security, see my comment
#81 (comment)

[vincentfretin]

More detailed thinking about this use case in the PR networked-aframe#6