before switching to mediaproxy-ng, i was using mediaproxy and kamailio mediaproxy module. when it added ice candidate, candidate type was 'relay'. now i noticed that rtpengine adds candidate of type 'host' and there seems to be no offer argument to change that.
i'm thinking of scenario where parties of the call may be able to find out a way to communicate directly in which case rtpengine should not be forced on them. that could be achieved by adding 'relay' type candidate to sdp instead of 'host' type candidate.
what is rtpengine motivation for adding 'host' type candidate instead of 'relay' type candidate?
-- juha
On 07 Apr 2014, at 10:22, Juha Heinanen jh@tutpro.com wrote:
before switching to mediaproxy-ng, i was using mediaproxy and kamailio mediaproxy module. when it added ice candidate, candidate type was 'relay'. now i noticed that rtpengine adds candidate of type 'host' and there seems to be no offer argument to change that.
i'm thinking of scenario where parties of the call may be able to find out a way to communicate directly in which case rtpengine should not be forced on them. that could be achieved by adding 'relay' type candidate to sdp instead of 'host' type candidate.
what is rtpengine motivation for adding 'host' type candidate instead of 'relay' type candidate?
Regardless of the reason, this behaviour has to be configurable. It will break when I want to use the RTPengine as a last-resort and actually allow p2p media.
/O
On 04/07/14 04:22, Juha Heinanen wrote:
before switching to mediaproxy-ng, i was using mediaproxy and kamailio mediaproxy module. when it added ice candidate, candidate type was 'relay'. now i noticed that rtpengine adds candidate of type 'host' and there seems to be no offer argument to change that.
i'm thinking of scenario where parties of the call may be able to find out a way to communicate directly in which case rtpengine should not be forced on them. that could be achieved by adding 'relay' type candidate to sdp instead of 'host' type candidate.
what is rtpengine motivation for adding 'host' type candidate instead of 'relay' type candidate?
This hasn't changed since mediaproxy-ng, it also added "host" candidates. 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.
cheers
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
On 04/07/14 09:20, Juha Heinanen wrote:
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.
Yes I understand, but there's still a few different options to consider in this case.
Should it always add itself as relay candidate? Or only if there are other ICE candidates already present?
Should it still replace the endpoint info in m= and c= lines? Or only if it adds itself as host candidate?
As we don't really have this use case ourselves, I can't tell what would make the most sense. Also it should be noted that this eliminates certain features (e.g. you can't have an SRTP-SDES client calling an SRTP-DTLS client any more, if both support ICE).
cheers
Richard Fuchs writes:
Yes I understand, but there's still a few different options to consider in this case.
Should it always add itself as relay candidate? Or only if there are other ICE candidates already present?
in my opinion, always, and there should be option to replace existing ones.
Should it still replace the endpoint info in m= and c= lines? Or only if it adds itself as host candidate?
i'm not sure about that because i don't know ice well enough. if both parties support ice, do they care what is on those lines or do they only look at candidate ips/ports? if they don't care, then i guess it is ok to replace endpoint info on c and m lines. perhaps someone who knows ice well can comment.
-- juha
-
Juha Heinanen -
Olle E. Johansson -
Richard Fuchs