7 Apr
2014
7 Apr
'14
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.