[libnice] nice_agent_add_external_address() to skip STUN?

Olivier CrĂȘte olivier.crete at collabora.com
Tue Nov 19 13:27:00 UTC 2019


That sounds like a great idea. There is probably a little work to try to completely hide the internal one.


On November 19, 2019 9:26:38 a.m. GMT-03:00, Juan Navarro <juan.navarro at gmx.es> wrote:
>Hi libnice devs,
>The libnice agent already provides "nice_agent_add_local_address()" as
>way to indicate which local IP address should be used for local
>candidates, which precludes the need to do the whole gathering of local
>This however is of very limited use in nowadays cloud provider's
>networks such as AWS, where our process will live behind a NAT, even
>though all ports in the NAT can be "opened" so the NAT is effectively
>Would it be possible to indicate both an internal *and external* pair
>addresses to libnice, in a similar way of how
>nice_agent_add_local_address() works? Something like
>"nice_agent_add_external_address (local_addr, external_addr)" would be
>helpful to make libnice generate the equivalent of a server-reflexive
>set of candidates, without need for STUN.
>We are exploring the possibility to deploy a media server such as
>Kurento (that uses libnice for WebRTC) and not having to deploy a
>STUN/TURN server alongside. In principle STUN should not be needed
>that A) all ports of the cloud NAT are "open" (all inbound connections
>are allowed), and B) the external, public IP of the machine is always
>known beforehand.
>Using nice_agent_add_local_address() to limit libnice to one of the
>(possibly many) virtual interfaces, then mangling the resulting
>candidates to replace the local IP address with the public IP address,
>is a technique that works perfectly fine albeit it seems very
>unorthodox. Proper support for this use case would be preferred.
>What do you think?
>Juan Navarro
>Kurento maintainer & developer
>j1elo @ Twitter <https://twitter.com/j1elo> / GitHub

Olivier CrĂȘte
olivier.crete at collabora.com

More information about the nice mailing list