Closed vincentfretin closed 1 year ago
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.
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.
(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.)
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
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.
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
More detailed thinking about this use case in the PR https://github.com/networked-aframe/janus-plugin-sfu/pull/6
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 thatprocess_subscribe
is not currently used in naf-janus-adapter, we use insteadprocess_join
with{media: occupantId}
option to subscribe tooccupantId
. 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) Humprocess_subscribe
is not doing all the checks with the jwt token likeprocess_join
is doing, it may be an issue. I thinkprocess_subscribe
is maybe dead code, maybe we used that instead ofprocess_join
with{media: occupantId}
in a previous version? And we can't currently useprocess_subscribe
without knowing the occupantId that is returned in the response of usingprocess_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
process_join
)process_subscribe
response, need to check jwt validity here too).For this case, chat is done via websocket, not datachannel of course.