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