Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
RFC: Add WebRtcEndpoint.externalIPs configuration parameter #278
This RFC proposes to add
Background and motivation
There is the long story about libnice gathering all possible IP addresses for its ICE candidates which introduces the problem for some Kurento many-networks deployments (like Amazon EC2, or Docker/Kubernetes): Kurento generates too much ICE candidates for itself and that results in the situation that sometimes (quite often, in practice) it fails to choose correct pair of ICE candidates and uses those ones from private networks, which leads to obvious bugs and video stability problems.
The first mention of this problem we found in this mailing list:
Also, the same problem is experienced by many users of Kurento:
The main issue that libnice generates too many unnecessary candidates.
Currently, we're trying to avoid that by custom patched version of libnice where we're filtering unnecessary network interfaces in
Can we do better? I assume yes. Let's find out...
Diving into libnice showed that
Literally, this means that we can set IPs via this field we want Kurento to generate ICE candidates on and do not performs IPs lookup at all which will result also in performance boost (as optimizes "the time it takes for the connection check algorithm to move from state CONNECTED to state READY, on both peers").
No usage of
So, it's relatively easy to provide on Kurento side the config option
This will be a convenient way to make Kurento generate only those ICE candidates we want it to return. Though, remains optional (and opt-out by default) for those who does not need that.
We are interested in adding such functionality to Kurento, as Openvidu itself (which builds upon Kurento) is also deployed in cloud provider environments.
The original idea was to wait until this issue got some more traction in the libnice project, at some point the added the compilation option
Seems that libnice is not interested in solving this issue, so now that this RFC has been brought to our attention (sorry for the time it took!) I think we should work on it. I'd be interested in knowing if there are already working implementations of this out in the wild. I already found that the open-source project instrumentisto seems to have code written for this. If anyone else wants to chime in, she'll be welcome to do so.
All rationale here: Kurento/bugtracker#278 There is the long story about libnice gathering all possible IP addresses for its ICE candidates which introduces the problem for some Kurento many-networks deployments (like Amazon EC2, or Docker/Kubernetes): Kurento generates too much ICE candidates for itself and that results in the situation that sometimes (quite often, in practice) it fails to choose correct pair of ICE candidates and uses those ones from private networks, which leads to obvious bugs and video stability problems. Turns out that libnice won't perform local address gathering if some local address(es) have been set beforehand; so, by using this new setting, we can provide the local addresses that libnice has to use, skipping the actual gathering. Thanks @alexlapa for the implementation at https://github.com/Kurento /kms-elements/pull/20 Fixes #278
Hi there. I'm reopening this issue because we found that the feature is not working for pretty basic use cases, i.e. Amazon AWS EC2 instances.
Indicating the external IP in the WebRtcEndpoint configuration file is actually working for the basic local network tests; e.g. these are the candidates that libnice generates for localhost:
And these ones are generated when testing in LAN:
However, we have a pretty different behavior when running in an empty, clean EC2 instance, where all ports are open and KMS is being installed locally with apt-get:
I'll be studying why libnice behaves like this. Any feedback or insight would be awesome.
Turns out libnice generates all 3 types of candidates when the local address that was added matches with one of the local network interfaces. That's why it was working in the two first tests, where the IP addresses correspond to addresses of the hardware interfaces.
If the local IP doesn't match any, then libnice only generates the TCP active candidate.
So libnice won't generate local candidates for external IP addresses, because it will fail here:
It makes sense: it's simply not possible to bind a local socket to an unknown IP address that doesn't exist in the system. And an external IP (such as the public part of the LAN's NAT) is, indeed, an unknown IP address for the local network.
So, @tyranron @alexlapa I would like to know in what sense is the
If there is no clear way to make this work for the general case of telling libnice about the public IP address, then we'll have to revert this change and instead look into different ways to accomplish the objective.
After some conversation I think or best option right now is to follow the initiative from GStreamer-plugins-bad, and instead of an IP address, accept a network interface name or list of names in the parameter: webrtcbin: add ice-nics property
There is a good reasoning for allowing an interface name instead of an IP address: in virtual and dynamic environments, the interface names are pretty much known beforehand, but the IP addresses might change. So it's safer to give