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