Advertising / Reading ICE trickle support

[delthas]

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:

• 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

https://datatracker.ietf.org/doc/html/rfc8840#section-4 specifically mentions:

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.

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.

[Sean-Der]

Hey @delthas, Sorry for the delay.

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 :)

[ValorZard]

Looking at the latest RFC, why is it called ice2?
https://datatracker.ietf.org/doc/html/rfc9725#section-4.3.3

[JoeTurki]

@ValorZard This is the ice version.

While this specification formally relies on [RFC8445], at the time of
its publication, the majority of WebRTC implementations support the
version of ICE described in [RFC5245]. The "ice2" attribute defined
in [RFC8445] can be used to detect the version in use by a remote
endpoint and to provide a smooth transition from the older
specification to the newer one. Implementations MUST be able to
accept remote descriptions that do not have the "ice2" attribute.

[ValorZard]

gotcha, thanks!

[ValorZard]

https://datatracker.ietf.org/doc/html/rfc9429#section-5.2.1 seems like adding ice2 at the end is mandatory

[nils-ohlmeier]

https://datatracker.ietf.org/doc/html/rfc9429#section-5.2.1 seems like adding ice2 at the end is mandatory

Warning do not just put ice2 into the SDP. You should do that only if the implementation support RFC 8845. So far none of the browsers support 8845.
I guess it is an area which Pion could spearhead. But implementing ice2 support is a big project. Especially since you need to keep full backward compatibility to ice1, which everyone else is using so far.