I'm creating a client application where I construct and destroy webrtcbin gstreamer components as the remote pears connect and disconnect. During the ICE negotiation the application opens several ports which is fine.
> netstat -aon | findstr 11608
TCP 10.17.106.41:54009 0.0.0.0:0 LISTENING 11608
TCP 127.0.0.1:53981 127.0.0.1:57778 ESTABLISHED 11608
TCP 192.168.56.1:54012 0.0.0.0:0 LISTENING 11608
TCP [fe80::34:f544:540:20ec%6]:54010 [::]:0 LISTENING 11608
TCP [fe80::8618:6e2e:a295:191c%14]:54011 [::]:0 LISTENING 11608
UDP 10.17.106.41:62525 *:* 11608
UDP 192.168.56.1:62528 *:* 11608
UDP [fe80::34:f544:540:20ec%6]:62526 *:* 11608
UDP [fe80::8618:6e2e:a295:191c%14]:62527 *:* 11608
when the remote peer disconnects I set the webrtcbin to a GST_STATE_NULL state and according to other sources:
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1169
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1636
this should free up the ports what have been reserved by webrtcbin.
The problem is it doesn't happen and the file descriptors which describes these port connections gets leaked I guess.
Already tryed to apply the bus flush trick mentioned in the links but it doesn't helped.
The problem was caused by programmer error.
I acquired the audio and video transceivers, and forgot to gst_unref them. This basically leaks them away but also this incremented the ref count of the webrtcbin internal nicebin component. When I destroyed the pipeline it decremented the refcount as it should be but because of the earlier leaks the refcount was 3 instead of 1. Because of that the internal nicebin was never deleted, and this caused the ports to be leaked away.
When the leak of the transceievers was noticed I applying gst_unref to the transceivers and that solved the problem.
Always read the documentation of the functions you use whether it returns owning raw pointers or not. C style api-s regularly does that so you should always remember to free the objects which are created by the functions you use.