[Spce-user] RTPEngine ICE Candidates Exchange

[Andreas Granig]

Hi,

On 12/16/2015 07:33 PM, Peter Villeneuve wrote:
> 1) always with plain SDP

This means that rtpengine is stripping any ICE candidates and sends a
plain SDP without ICE. That's useful if you're dealing with endpoints
not supporting ICE at all.

> 2) always with rtpproxy as additional ICE candidate

This option would add the rtpengine as additional ICE candidate, as the
description implies. I believe it adds rtpengine as relay candidate
(something Richard would need to confirm). That means that existing ICE
candidates are preserved, and if the endpoints are not able to establish
a connection to any of the candidates provided, they can fall back to
relaying it via rtpengine.

> 3) always with rtpproxy as only ICE candidate

This option is stripping any ICE candidates offered by the endpoint and
replaces it by a host candidate (I believe; again up to Richard to
explain) pointing to rtpengine in oder to enforce media anchoring over
the server while still using ICE.

> 4) never

Well, not engage rtpengine at all.

> Obviously 4 is pretty self-explanatory, but I don't understand what
> option 1 does. Doesn't rtpengine always rewrite/insert ICE candidates in
> SDP when activated? So what does option 1 do exactly that's different
> from 2/3? I can't find any info regarding that in the documentation.

We'll extend the online help of that preference to make it more clear.

> Also, in my test scenario, where both android linphone clients support
> ICE, I thought that using option 2 would be ideal since the media would
> only be relayed when the two clients cannot establish a p2p connection
> directly.
> But when I actually use option 2, and both linphone clients are in the
> same LAN and can communicate p2p, I see in the linphone logs that ICE
> reports it is using relay connections, which surprises me since they
> should both be reporting a p2p host connection.
> Since linphone states it adheres to the ICE RFC, and so does rtpengine,
> I don't understand what's going on when I know for certain that both
> clients can easily talk to each other directly. It seems to me that
> rtpengine maybe inserting itself as a host candidate when in fact it is
> a relay one. Does this make any sense?

With option 2 it should add itself as relay candidate, see above.
Waiting for Richard's feedback on that (or you could grab a SIP trace
and provide the SDP bodies negotiated in your case, so we can have a
quick look together).

Andreas