Due to an influx of spam, we have had to impose restrictions on new accounts. Please see this wiki page for instructions on how to get full permissions. Sorry for the inconvenience.
Admin message
Equinix is shutting down its operations with us on April 30, 2025. They have graciously supported us for almost 5 years, but all good things come to an end. We are expecting to transition to new infrastructure between late March and mid-April. We do not yet have a firm timeline for this, but it will involve (probably multiple) periods of downtime as we move our services whilst also changing them to be faster and more responsive. Any updates will be posted in freedesktop/freedesktop#2011 as it becomes clear, and any downtime will be announced with further broadcast messages.
webrtcbin do not signal when ICE candidate gathering is done
New webrtcbin component has signal add-ice-candidate which is sent for every discovered ICE candidate. However now there is no way to tell when all of them are gathered. I need this to send all candidates appended to end of SDP (in my case they are for local IP address only).
It will be beneficial to fix add-ice-candidate signal too, so GStreamer could fail faster if none of provided ICE candidates can be used. Without this it can only use timer to decide when to fail.
So after experimenting with webrtcbin for a while, the ice-gathering-state property is set to complete once the ICE candidates are gathered. The issue is that the property is set to complete when the first on-ice-candidate signal is emitted, so it can't be used to determine if all ICE candidates have been emitted by the on-ice-candidate signal.
an additional on-ice-candidate signal with NULL as the argument or a new signal would be helpful to know when all ICE candidates have been gathered and emitted.
Hello, I'm attaching a "Browser vs GStreamer" comparison, hoping to clarify what this issue is about.
Both attached programs simply create an offer and set it as local description (the rest of the webrtc "handshake" is not needed to reproduce the issue).
If you run the HTML version in browser (tested in Firefox 60 and Chrome 71) and open the console, you will see the following sequence of events:
Creating offer
Offer is ready!
Setting local description
Local description set successfully
onicegatheringstatechange new-state: gathering
onicecandidate candidate:
RTCIceCandidate { candidate: "candidate:0 1 UDP 2122252543 192.168.1.8 44960 typ host", sdpMid: "sdparta_0", sdpMLineIndex: 0 } (this type of event is repeated once for each candidate)
onicegatheringstatechange new-state: complete
onicecandidate candidate: null
Instead, if you run the GStreamer-based program (tested on 1.15.1), you will see this sequence:
on_ice_candidate 0 candidate:1 1 UDP 2013266431 fe80::1234:1234:1234:1234 50388 typ host (this type of event is repeated once for each candidate)
As you can see, the browser correctly notifies onicegatheringstatechange=gathering before ICE candidates, and onicegatheringstatechange=complete immediately afterwards, followed by a final null ICE candidate. On the other hand, GStreamer notifies GST_WEBRTC_ICE_GATHERING_STATE_COMPLETEbefore even emitting the first ICE candidate and does not emit the final null one at all. Given the lack of further notifications, it is impossible to know when all the candidates have been emitted.
Does the 'ice-gathering-state' property not change for you?
I did not try it, and it turned out (see previous answers) that it does not work properly.
Can you clarify what you meant by 'It will be beneficial to fix add-ice-candidate signal too' ?
It it not possible to tell GStreamer that there are only 4 ICE candidates (or any other number). If none of them will work, GStreamer will not know that app will not send it any extra ones, and it will finally timeout and report error. My proposal was to send NULL as a candidate to notify GStreamer about this, so it could report error immediately after finding that all 4 candidates do not work.
I've investigated this question a little bit and found that check ice-gathering-state value can be solution for problem but unfortunately ice-gathering-state logic contains a bug (or at least I think it's the bug).
The problem is _collate_ice_gathering_states by default treat state as COMPLETED even if it doesn't really check transports state. In my case it doesn't check tranports state by
if (!rtp_trans->mid) continue;
condition. The mid is just NULL, so ice-gathering-state become COMPLETE even if transport's or rtcp_transport's gathering-state property is not COMPLETE
I've commented mentioned above condition and got ice-gathering-state working correctly (Ubuntu 19.04 x64, GStreamer 1.15.90 from ubuntu repo rebuilt with above fix). But of course I don't know why this condition is there, and maybe there are some reason for it...
For a bit more context: I'd like to disable Trickle ICE by gathering all candidates upfront and send SDP with all candidates right away.
https://github.com/feross/simple-peer library for instance has trickle boolean option that emulates this behavior when set to false.