[sr-dev] rtpengine ice candidate type

[Juha Heinanen]

Richard Fuchs writes:

> This hasn't changed since mediaproxy-ng, it also added "host"
> candidates.

yes, that is true, but i didn't pay attention to it before now when i
started to test calls between ice capable sip clients.  in case of
websocket clients, it is not possible for the proxy to determine if a
client is behind nat or not and thus the proxy does not know if the
parties of the call are able to make p2p media connection.  in such a
case, a sensible thing for the proxy to do would be to add rtpengine as
a relay candidate to the invite, which the clients then can use as the
last resort.

mediaproxy module always add a 'relay' ice candidate and there is a
module parameter that tells its priority level:

5.6. ice_candidate (string)

    Indicates the type of ICE candidate that will be added to the SDP. It
    can take 3 values: 'none', 'low-priority' or 'high-priority'. If 'none'
    is selected no candidate will be adeed to the SDP. If 'low-priority' is
    selected then a low priority candidate will be added and if
    'high-priority' is selected a high priority one.

> The primary reason is that we normally use rtpengine/mp-ng
> in ICE=force mode, where "host" candidates are the only thing that makes
> sense, and I'm unsure about what kind of logic an ICE client employs
> when it sees different candidates of different types, i.e. what would be
> the best candidate type for rtpengine to use in this case.

my understanding is that ice clients normally prefer host candidates,
then reflexive candidates, and last relayed candidates.  using ICE=force
prevents p2p media and i don't consider it a good idea. ICE=force_relay
would be better meaning that all relay candidates are replaced leaving
host and reflexive ones as they were.

-- juha