webrtcbin socket / file descriptor leaks

I have seen various examples of the same or similar issue but in my case none of the existing solutions seem to resolve the problem. Below is the tail end of lsof output for my process having been connected to by a client webapp 3 times. test_app 6910 testuser 47u a_inode 0,12 0 7523 [eventfd] test_app 6910 testuser 48u a_inode 0,12 0 7523 [eventfd] test_app 6910 testuser 49u a_inode 0,12 0 7523 [eventfd] test_app 6910 testuser 50u IPv4 676153 0t0 UDP test-host:59021 test_app 6910 testuser 51u IPv4 676157 0t0 TCP test-host:57284->123.123.123.123:3478 (ESTABLISHED) test_app 6910 testuser 52u IPv4 676161 0t0 TCP test-host:55161 (LISTEN) test_app 6910 testuser 53u IPv4 676165 0t0 UDP test-host:58914 test_app 6910 testuser 54u IPv4 676169 0t0 TCP test-host:57286->123.123.123.123:3478 (ESTABLISHED) test_app 6910 testuser 55u IPv4 676173 0t0 TCP test-host:56893 (LISTEN) test_app 6910 testuser 56u IPv6 676177 0t0 UDP test-host:32792 test_app 6910 testuser 57u IPv6 676184 0t0 TCP test-host:36487 (LISTEN) test_app 6910 testuser 58u IPv6 676188 0t0 UDP test-host:48594 test_app 6910 testuser 59u IPv6 676195 0t0 TCP test-host:60733 (LISTEN) test_app 6910 testuser 60u a_inode 0,12 0 7523 [eventfd] test_app 6910 testuser 61u a_inode 0,12 0 7523 [eventfd] test_app 6910 testuser 62u a_inode 0,12 0 7523 [eventfd] test_app 6910 testuser 63u IPv4 676293 0t0 UDP test-host:55921 test_app 6910 testuser 64u IPv4 676297 0t0 TCP test-host:57288->123.123.123.123:3478 (ESTABLISHED) test_app 6910 testuser 65u IPv4 676301 0t0 TCP test-host:49897 (LISTEN) test_app 6910 testuser 66u IPv4 676305 0t0 UDP test-host:54264 test_app 6910 testuser 67u IPv4 676309 0t0 TCP test-host:57290->123.123.123.123:3478 (ESTABLISHED) test_app 6910 testuser 68u IPv4 676313 0t0 TCP test-host:35643 (LISTEN) test_app 6910 testuser 69u IPv6 676317 0t0 UDP test-host:36943 test_app 6910 testuser 70u IPv6 676324 0t0 TCP test-host:44785 (LISTEN) test_app 6910 testuser 71u IPv6 676328 0t0 UDP test-host:60323 test_app 6910 testuser 72u IPv6 676335 0t0 TCP test-host:56169 (LISTEN) test_app 6910 testuser 74u a_inode 0,12 0 7523 [eventfd] test_app 6910 testuser 75u a_inode 0,12 0 7523 [eventfd] test_app 6910 testuser 76u IPv4 676437 0t0 UDP test-host:45050 test_app 6910 testuser 77u IPv4 676441 0t0 TCP test-host:57292->123.123.123.123:3478 (ESTABLISHED) test_app 6910 testuser 78u IPv4 676445 0t0 TCP test-host:55935 (LISTEN) test_app 6910 testuser 79u IPv4 676449 0t0 UDP test-host:59790 test_app 6910 testuser 80u IPv4 676453 0t0 TCP test-host:57294->123.123.123.123:3478 (ESTABLISHED) test_app 6910 testuser 81u IPv4 676457 0t0 TCP test-host:45109 (LISTEN) test_app 6910 testuser 82u IPv6 676461 0t0 UDP test-host:59918 test_app 6910 testuser 83u IPv6 676468 0t0 TCP test-host:44689 (LISTEN) test_app 6910 testuser 84u IPv6 676472 0t0 UDP test-host:44078 test_app 6910 testuser 85u IPv6 676479 0t0 TCP test-host:36151 (LISTEN)

In the above there are 3 sets of file descriptors (and associated event fd's) left over, one for each of 3 terminated sessions. These seem to all (or mostly) originate in libnice (1.18) via a call in gst's (1.19.1) iostream.c:209 nice_agent_gather_candidates.

However when I use the send-only example from gst-examples I do not have this issue, it seems to leak a single unix socket per session but nothing like the problem shown here.

I have found various similar cases with various solutions but none seem to apply here. In particular they often involve reusing the same pipeline where as in this case the pipeline is completely destroyed between sessions.

From what I have read simply setting the pipeline to the NULL state should close everything down but this does not seem to be happening. I have actually got code that is going through unlinking and setting state to NULL for all the individual audio and video stream elements already (a colleague who has since left had implemented this and I do not know all the details as to why).

One distinct difference is that we are using a data stream in our application, the send-only example only has audio and video streams.

Can anybody suggest what I might be doing wrong or is this actually a bug that does not manifest in all implementations?