[libnice] ICE, NAT
kakaroto at kakaroto.homelinux.net
Tue Dec 9 12:21:55 PST 2014
It will mainly depend on the type of NAT you are behind, some will simply
block incoming traffic from an IP they never sent to before, while some
will create a different port mapping for each destination. Basically, look
at the types of NAT from here :
and see the difference between the full cone, the symmetric nat and the
In the case of port-restricted or symmetric nats, ICE would not work IF
both peers are behind a symmetric or port-restricted NAT. Otherwise, A
can't send to B, but B can send to A, which causes A to discover a remote
peer-reflexive candidate and a new ICE check happens on a new candidate
pair which would then allow A to send to B.
I hope this helps,
On Sat, Dec 6, 2014 at 7:51 AM, <fb111 at web.de> wrote:
> I would like to understand the following part out of the ICE RFC:
> "The second property is important for getting ICE to work when there
> are NATs in front of L and R. Frequently, NATs will not allow
> packets in from a host until the agent behind the NAT has sent a
> packet towards that host. Consequently, ICE checks in each direction
> will not succeed until both sides have sent a check through their
> respective NATs."
> As far as I understand it, it says that even if your have discovered the
> server reflexive candidates from your signaling server of agent A and B
> after having sent the STUN requests/ answers, the two agents A and B can
> not communicate with each other because the NAT IP and port of the
> reflexive address is binded to the STUN servers IP address.
> and now this is my question: how are the two agents A and B are able to
> get a NAT IP & port binding for a communications between A and B directly?
> Do I understand the RFC correctly that A and B send "checks" to the agents
> A respectivley B NAT IP adress? How do A and B find out ech others port
> address so that they can communicate directly?
> nice mailing list
> nice at lists.freedesktop.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the nice