You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ICE trickling helps speed up the connection establishment. For it to work though, the receiving side should support it. If we send ICE candidates after the SDP payload for clients who do not support ICE trickling, these candidates would be ignored; we could even send an offer without any candidates and the call would fail entirely.
To know whether the other side supports ICE trickling:
The support can be advertised through the signaling channel (which will work without this ticket)
The support can be advertised through an SDP ICE option, a=ice-options:trickle
Trickle ICE Agents MUST indicate support for Trickle ICE by including the ice-option "trickle" within all SDP Offers and Answers in accordance to [RFC8838].
To do this, we probably need to add an "ICETricklingSupported" bool option to webrtc.OfferAnswerOptions that the user can set. If set, the a=ice-options:trickle attribute is added to the generated SDP payload.
As for the actual use case, I'd like to half ICE trickling optimistically to speed up connection establishment in an environment where I do not control the remote client so I do not know whether trickling is supported.
The text was updated successfully, but these errors were encountered:
It would be trivial adding a=ice-options:trickle to the Offer/Answer (from Pion). Are you interested in doing that? We shouldn't just uncomment the line in jsep.go, but instead have pion/webrtc pass it in somehow.
We don't care if the remote trickles or not! I don't believe any logic needs to be added as a receiver.
If you aren't interested in contributing tell me and I can have this fixed in 30 minutes :)
TL;DR, this is the issue for tracking the TODO at https://github.com/pion/sdp/blob/master/jsep.go#L91
ICE trickling helps speed up the connection establishment. For it to work though, the receiving side should support it. If we send ICE candidates after the SDP payload for clients who do not support ICE trickling, these candidates would be ignored; we could even send an offer without any candidates and the call would fail entirely.
To know whether the other side supports ICE trickling:
a=ice-options:trickle
https://datatracker.ietf.org/doc/html/rfc8840#section-4 specifically mentions:
To do this, we probably need to add an "ICETricklingSupported" bool option to webrtc.OfferAnswerOptions that the user can set. If set, the
a=ice-options:trickle
attribute is added to the generated SDP payload.In addition, we would need to be able to know if the remote side sent the attribute, corresponding to https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/canTrickleIceCandidates in the Web spec. This would probably be a method on SessionDescription?
As for the actual use case, I'd like to half ICE trickling optimistically to speed up connection establishment in an environment where I do not control the remote client so I do not know whether trickling is supported.
The text was updated successfully, but these errors were encountered: