Optional forcing of private IDs for subscriptions for better kick in VideoRoom

[lminiero]

This PR addresses the discussion we had in #745.

The motivation comes from the fact that, when you kick a user, normally their subscriptions still live in the room and they keep on getting media: that's expected as we kick a publisher, but listeners don't necessarily have a context, as we don't mandate them to be associated to any publisher at all.

This PR allows for this association to be optionally mandated, based on the private_id property we introduced recently. The idea is the following:

1. When you join as a publisher, you're returned a unique private_id by the plugin: you're not supposed to share this.
2. When you start subscribing to another participant, you can pass this private_id as part of the request, to allow the plugin to know this was originated by you. The VideoRoom demo already does that. Anyway, this parameter is entirely optional, for reasons explained in ACL and kick support in AudioBridge, VideoRoom and TextRoom #745 (we still want to support listeners that are created out of context or with no associated publisher handle present).
3. If the room was created with a require_pvtid:true, then the private_id part when subscribing is mandatory, and it must match one of the existing publishers: if it's missing, or it's invalid, the subscription fails.
4. When a user is kicked, we check his private_id, and so close all listeners with the same private_id too. Of course, this is only guaranteed to succeed if require_pvtid:true, as otherwise nothing prevents listeners to be created without a private_id.

Tested briefly with three participants and seems to work. Please test carefully to check if it works and if it doesn't introduce any regression or problem/crash.

[izemize]

Hi,

I tested this, it's work.. so listener dropped correctly, but after user kicked and kicked user trying to reconnect, janus crashed.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffd4bd6700 (LWP 28004)]
0x00007ffff714f2e5 in g_mutex_lock () from /lib/x86_64-linux-gnu/libglib-2.0.so.0


#0  0x00007ffff714f2e5 in g_mutex_lock () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#1  0x00007ffff70dfd7b in g_async_queue_push () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x000000000042b394 in janus_ice_webrtc_hangup (handle=handle@entry=0x7fff94002f90) at ice.c:1169
#3  0x0000000000439d54 in janus_plugin_close_pc (plugin_session=<optimized out>) at janus.c:3078
#4  0x00007fffec01e77a in janus_videoroom_handle_message (handle=0x7fff6c001410, transaction=0x7fffc00048e0 "aZyTm4YNALNb", message=0x7fff64007c70, jsep=0x0) at plugins/janus_videoroom.c:1959
#5  0x0000000000440286 in janus_process_incoming_request (request=0x7fff64001900) at janus.c:1339
#6  0x00000000004444b5 in janus_transport_task (data=0x7fff64001900, user_data=<optimized out>) at janus.c:2582
#7  0x00007ffff71321d8 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#8  0x00007ffff7131845 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#9  0x00007ffff59f2064 in start_thread (arg=0x7fffd4bd6700) at pthread_create.c:309
#10 0x00007ffff572762d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

[lminiero]

Ack, thanks for testing, I'll look into this.

[lminiero]

Can't seem to be able to replicate this: what do you mean by reconnecting the kicked publisher? If I try a new publish I get an unauthorized error, and if I refresh the page and try again it seems to work for me.

[lminiero]

Nevermind that, got it to crash...

[izemize]

1. kick
2. reconnect
3. error

#0 0x00007ffff7126b28 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#1 0x00007ffff7127b59 in g_slice_alloc () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007ffff71285f6 in g_slist_prepend () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x00007ffff712a641 in g_strsplit () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4 0x00007fffdc13ad2b in janus_http_handler (cls=0x10, connection=0x1, url=0x7fffc00027d0 "\002", method=0x7fffb8012fe0 "POST", version=0x0, upload_data=0x0, upload_data_size=0x7fff577fdb90, ptr=0x1)
at transports/janus_http.c:1147
#5 0x00007fffd6debf71 in ?? () from /usr/lib/x86_64-linux-gnu/libmicrohttpd.so.10
#6 0x00007fffd6ded1b0 in ?? () from /usr/lib/x86_64-linux-gnu/libmicrohttpd.so.10
#7 0x00007fffd6df0ee1 in ?? () from /usr/lib/x86_64-linux-gnu/libmicrohttpd.so.10
#8 0x00007ffff59f2064 in start_thread (arg=0x7fff577fe700) at pthread_create.c:309
#9 0x00007ffff572762d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

[lminiero]

Can you check if this fixes it for you?

Notice that this will not close the listeners' PeerConnections, but it will mark them as kicked and no media will flow any more, meaning they'll have to close them down as they'll be useless from now on. Trying to close them from within the kick code is what triggered the race condition and the crash for me, as the close_pc code sometimes causes the hangup_media to be invoked from the same thread thus causing locks and slowdowns to occur that lead to the issue. It will probably not be an issue once we deal with this in the reference counters branch, but for now this should do it.

[izemize]

Yes, it's working without crash

[lminiero]

Have you done some more tests? Wondering if it's safe to merge now.

[lminiero]

Nothing else? Well, looks good to me, so merging.