ICE=force vs. ICE-lite

[Alex Balashov]

Hi,

I am curious about the behavioural difference among ICE=force vs. ICE-lite=forward/backward/both. 

At first glance, and without extensive familiarity with the nomenclature and vision around "ICE lite", it seems like they both accomplish the same thing, which is to situate RTPEngine as the sole usable remote ICE candidate to one or more parties. However, I also assume that if this were literally the case, there would not be an additional ICE-lite setting. :-)

Thanks much in advance!

-- Alex

[Richard Fuchs]

The difference is in how ICE is negotiated.

An ICE-lite peer is a purely passive entity and only responds to
requests sent to it, whereas an ICE-full peer actively sends
connectivity checks itself. Effectively this means that an ICE-lite peer
is required to have an IP address reachable by the ICE-full peer, or
otherwise connectivity will fail.

Another difference (and possibly an important one) is that in a role as
a proxy, rtpengine as an ICE-lite peer can only achieve negotiated ICE
status towards the offerer once the answer has been sent by the
answerer. This is because without an answer, the offerer has nowhere to
send ICE requests to. Meanwhile in the same situation but with rtpengine
using ICE-full, it can send requests to the offerer immediately after
receiving the offer, leading to working connectivity towards the offerer
much faster (even more so if then DTLS also needs to be established).
Caveat: Some peers refuse to establish ICE/DTLS before an answer has
been received, and in those cases it wouldn't make a difference.

Cheers

[Alex Balashov]

Thank you for that explanation, Richard. Really appreciate it.

Is there a distinction between ICE=force and ICE-lite when RTPEngine is used to bridge between UDP/TLS/RTP/SAVP and RTP/AVP?

That is to say, given a browser DTLS-SRTP endpoint on one side and a plain UDP endpoint on the other, is there any benefit to using ICE-lite over ICE=force to negotiate ICE with it? The intent is to use RTPEngine as a server-side NAT traversal element and to avoid any peer-to-peer negotiation; in fact, the UDP endpoint on the other side is not even publicly reachable.

-- Alex

--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800

[Richard Fuchs]

On 02/04/2024 11.32, Alex Balashov wrote:
> Thank you for that explanation, Richard. Really appreciate it.
>
> Is there a distinction between ICE=force and ICE-lite when RTPEngine is used to bridge between UDP/TLS/RTP/SAVP and RTP/AVP?
>
> That is to say, given a browser DTLS-SRTP endpoint on one side and a plain UDP endpoint on the other, is there any benefit to using ICE-lite over ICE=force to negotiate ICE with it? The intent is to use RTPEngine as a server-side NAT traversal element and to avoid any peer-to-peer negotiation; in fact, the UDP endpoint on the other side is not even publicly reachable.

The two options (ICE-lite and ICE=force) aren't mutually exclusive.
Setting ICE-lite is just a yes/no boolean switch. So you can set
ICE=force with or without setting ICE-lite.

Using ICE=force is definitely the way to talk to an ICE-enabled peer.
Personally I see no reason to also set ICE-lite as there are no benefits
that I can see. Perhaps there are some misbehaving ICE peers out there
that don't play well against a non-ICE-lite peer. Perhaps someone else
can share some insight as to why they prefer to use rtpengine in
ICE-lite mode.

Cheers