videoroom participants (especially listener) management

[Steven Tang]

Hi all,

  How do you guys manage the participants in the videoroom? it looks like there is no efficient way to kick a listening only participant as the listeners do not really have any identity, except an id. i.e. if one listener joins, admin would have no idea who that is (and is not even notified as of now, I filed issue https://github.com/meetecho/janus-gateway/issues/1030 for that) . Shouldn't the listeners also have a display or maybe an optional field to link with the publisher id?

Thanks,

Steven

[Lorenzo Miniero]

Kick is supported, as long as you use some additional fields and configure a room accordingly. Check the PRs where we added the feature:

https://github.com/meetecho/janus-gateway/pull/745

https://github.com/meetecho/janus-gateway/pull/856

L.

[Steven Tang]

Thanks Lorenzo,

  I know it is supported, but admin cannot easily manage the listeners without any identity. All the admin could know by manually polling the listparticipants is a list of ids (listeners do not really have display), which have no way of tracing who it is.

Steven

[Steven Tang]

BTW, I still think the issue I filed is worth addressing, whether it is a code bug, or a feature request. Give it a second thought. It isn't really working as expected, as the admin simply has no way of knowing if someone joins the room if there is no event, and cannot possibly kick someone in time. 

On Thursday, October 12, 2017 at 10:18:27 AM UTC-4, Lorenzo Miniero wrote:

[Lorenzo Miniero]

If you're forcing private_id and listeners to have a corresponding participant, it works. If you're circulating the publisher ID out of band and letting listeners join out of context, then there's nothing we can do: it's up to you to track listeners somehow (e.g., by handle, or by wrapping the Janus API) and close their connections.

L.

[Steven Tang]

That's not exactly what I need. The admin would like to be able to manage participates already joined, legitimately, whether via a token or private id. i.e. currently, all we have is a list of legitimate users joined, but when an admin wants to kick one of them, for whatever reasons, the admin currently cannot due to 1, listeners can join silently without any event posted to the admin, i.e. it has no way of knowing anyone joined, except polling. 2. even if the admin gets the list, it has no idea who is who.

[Lorenzo Miniero]

I understand that, and, as explained in my previous post and those two PRs, there's nothing we can do in that situation. Wrapping the Janus API will give you all the control you need (it's what we do ourselves in a lot of different contexts).

L.

[Steven Tang]

Hi Lorenzo,

  Again, thanks for the explanation, using private_id as you suggested, does solve the identity problem of the listener, as we have to create a publisher before creating a listener. That's great! I still would like to introduce a flag to allow sending the joining event for the videoroom, as that will allow a listening only user to be seen by the admin. Do you have objection on that? if not I can work on a pull request.

Thanks,

Steven

[Lorenzo Miniero]

I've personally been against advertising listeners for a long time. Listeners/lurkers are always going to be the vast majority (they duplicate each time a publisher joins) and advertising them too is going to result in a storm of events and overly verbose text. I'd much rather keep the API clean and leaner, and encourage using the existing mechanisms for solving the issue. Notice that you can also use the Event Handlers for async notifications about listeners attaching to a stream, as they were meant exactly for monitoring/admin purposes.

L.