[SR-Users] rtpengine force-relay

[Daniel Tryba]

On Fri, Mar 15, 2019 at 12:37:16PM +0200, Vitalii Aleksandrov wrote:
> Oh, it actually does. If you use ICE=force, rtpengine removes all ICE
> candidates and inserts its own and both call participant can't to talk to
> each other directly but still can use ICE to establish media streams to
> rtpengine. ICE=force-relay does another cool thing. Using it call
> participants try to talk directly and if they can't (both behind NAT) they
> can still use "relay" candidate inserted by rtpengine and exchange media via
> it. I just need a mixed behavior like default + force-relay and don't want
> to hack rtpengine sources and then maintain my patches when need to update
> it.

How is this any different than the default ICE setting (without rewriting
rtp)? rtpengine will add itself to ICE candidates (with a lower priority
than already present ICE). Allowing the rtpengine to be skipped entirely
if there is a better (higher priority) ICE candidate.

endpoint A with ICE support <-> rtpengine with ICE <-> endpoint B with ICE

Here RTP can go directly from A to B.
If any point doesn't support ICE, the rtpengine will be used (with ICE
for the endpoint that does support ICE) if rtpengine rewrites RTP for
legacy endpoints.

The problem of removing ICE is more apparent with more parties involved:
a <-> r1 <-> r2 <-> b

if a,r1 and r2 have ICE support but b doens't, do you want a to
communicate with r1 or r2? If you remove ICE with force-relay, it will
talk to r1, if you "do nothing", it may talk to r2 as ICE candidate.