Hello, I have used the code given here to create the webrtc application. The issue with this application is that the ports remains occupied even if we close the live view is closed or peers are disconnected.
Could anyone help me understand:
Why WebRTC keeps the ports occupied after disconnection?
If there’s a way to explicitly release the port sooner?
Does anyone know why this happens or have tips on managing WebRTC port usage so they release more quickly after a disconnect? Any advice or best practices would be super helpful!
Thanks in Advance!
The last time this came up was due to a reference counting issue in the application causing resources to still be alive. My suggestion would therefore be, ensure your application is leak free.
I’m seeing this too. I cannot post the code as it’s part of a commercial application, but the gist is that once the webrtcbin connects, we end up with some number of ports opened (as expected). However, despite verifying that the reference count of our webrtcbin does in-fact reach 0 on our unref, those ports never close, and the next webrtcbin effectively doubles the number of ports consumed. Eventually, this long-running service runs out of ports.
I’m trying to isolate the problem by using one of the GStreamer examples, but none of them work. All end with this error:
ERROR from element nicesrc1: Internal data stream error.
Debugging info: ../libs/gst/base/gstbasesrc.c(3177): gst_base_src_loop (): /GstPipeline:pipeline0/GstWebRTCBin:recv/TransportReceiveBin:transportreceivebin1/GstNiceSrc:nicesrc1:
streaming stopped, reason not-linked (-1)
Pipeline stopped
We’re presently using 1.24.8. What version are you using, @ravhad934? Have you tried investigating port usage of the example apps as well?
I had a small breakthrough just now. I was able to get the webrtcswap example to work in Windows and attach a debugger to see if I could reproduce the problem. The way the example shuts down is it releases its extra references to the two webrtcbin elements and then releases the pipeline. I added a GSource timeout to quit the loop 10 seconds after the application starts, and then I re-ordered the unref process so it went like this:
- Unref
webrtcbin #1
- Unref the pipeline
- Unref
webrtcbin #2
I then attached a debugger and waited to hit step 1.
l observed using tcpview64 (free application) that the ports that were opened only closed after step 3 happened. In other words: despite the reference count to the first webrtcbin being 0 at that point (confirmed in the debugger), the ports for both webrtcbin instances were still open until both the remaining webrtcbin and its now-defunct peer (the first webrtcbin) were released.
This behavior seems a little strange to me, @ystreet00, that the ports would remain open after the webrtcbin that opened them has been destroyed.