Disconnect/leave publisher in videoroom

[Mikael Boman]

I got stuck; how does the message(s) (from external websocket client) look like to disconnect a publisher/leave videoroom?

/M

[Lorenzo Miniero]

What do you mean by disconnecting a publisher? unpublishing? unsubscribing?

The easiest way to do both is to just detach the Janus handle.

L.

[William MANCON]

want  to kick or ban someone ?

[Mikael Boman]

Yes, want to kick out a participant temporarily.

To be able to detach, I think I need session_id and handle_id for this participant.

I have these for my "external" client but I need to detach the right one. 

Do I get this data in listparticipants?

To ban someone forever I presumed I could simply delete its authentication token - at least this was the plan.

/M

[Lorenzo Miniero]

listparticipants gives you videoroom-level identifiers, not what you want; session_id and handle_id are core level info, and you must have that already since you're sending Janus messages for each of those participants.

L.

[Mikael Boman]

What I do is "rtp_forward" for a participant but here I am using "my" session_id/handle_id + participant id and not the session_id/handle_id used by the participant's browser client. Perhaps I am not fully understanding the use if these ids.

/M

[Lorenzo Miniero]

Time to study the docs and demos again, then ;-)

L.

[Mikael Boman]

OK - you don't make it easy for me...I have instances of these IDs since I do create and attach in my "external" client but assumed wrong ones for detach of room participant - anyhow, I will investigate a little more then...;-)

/M 

[Mikael Boman]

...and to clarify, "rtp_forward" works fine using "my" session_id, handle_id.

/M

[Lorenzo Miniero]

I didn't want to sound stern, but the docs provide the best description of how Janus based communication works. Any explaination I could write here would basically be the same text you see in the docs, as it's me who wrote them to try and be as clear as possible.

It's always the same:

1. users create a session with Janus (session_id)
2. they might create one or more handles to talk to plugins (handle_id)
3. users send messages to a specific plugin by specifying session_id+handle_id (and that's why I said you have to know those)
4. within the communication with a plugin, you exchange JSON messages, and different identifiers that ONLY make sense to the plugin (Janus has no idea what they are, payload is opaque) may be involved; that's the case, for instance, of VideoRoom publisher IDs, which is what a listparticipants would return (Janus has no clue about what a "listparticipants" is, it's a plugin-specific request).

Since you want to detach a handle, just stay at the core level and use those identifiers. When you detach a handle, the plugin-related status for that handle is automatically removed by the plugin, which is the same thing as removing a user from the plugin (in case of a publisher, kicking him out). Of course, within the context of a videoroom a user may be publishing AND viewing other streams, which means that if you want to completely kick a user you'll have to detach both their publisher/manager channel and all the handles they're using to watch other people.

I can't be clearer than that: if this is still unclear, then you REALLY have to study the docs/demos again :-)

L.

[Mikael Boman]

Yes, I think I understand and my problem was exactly this: as an "external" client I do not know the session_id nor the handle_id used by the particular publisher (which actually is a publisher only - not a listener).

Without having knowledge about these to IDs, I cannot detach nor unpublish, so my conclusion is that in such environment there are no means to let an "external" client kick a publisher in the videoroom plugin.

Well this is also good information to have.

So I will either ask the browser client for the IDs or update the plugin/extend the API with the option to kick out a publisher (similar as "rtp_forward" message). However, intercepting a browser/publisher-Janus session from

an external "client" (first alt. mentioned) does also not look like a clean solution, but now I know what options I have to consider. Thanks for the clarification and help.

/M