7 Apr
2014
7 Apr
'14
11:22 a.m.
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
7 Apr
7 Apr
12:31 p.m.
On 07 Apr 2014, at 10:22, Juha Heinanen <jh(a)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
3:36 p.m.
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
4:20 p.m.
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
5:36 p.m.
On 04/07/14 09:20, Juha Heinanen wrote:
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?
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
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.
6:15 p.m.
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
3884
days inactive
3884
days old
5 comments
3 participants
participants (3)
-
Juha Heinanen -
Olle E. Johansson -
Richard Fuchs