Re: [P2PSIP] Choice of STUN peer or TURN peer

["Bruce Lowekamp" <[e-mail]>]

On Jan 23, 2008 4:58 AM, JiangXingFeng <[e-mail]> wrote:
> > From: Dan Wing [mailto:[e-mail]]
> > Sent: Wednesday, January 23, 2008 4:13 PM
> > To: 'JiangXingFeng'; 'P2PSIP Mailing List'
> > Subject: RE: [P2PSIP] Choice of STUN peer or TURN peer
> >
> >
> >
> > > -----Original Message-----
> > > From: JiangXingFeng [mailto:[e-mail]]
> > > Sent: Tuesday, January 22, 2008 8:40 PM
> > > To: 'Dan Wing'; 'P2PSIP Mailing List'
> > > Subject: RE: [P2PSIP] Choice of STUN peer or TURN peer
> > > ICE does support multiple servers. But I guess ICE has not considered
> > > whether STUN server or TURN server is behind NAT. (Is my understanding
> > > right?) So if STUN server or TURN server behind NAT are
> > > involved, the ICE
> > > connectivity procedure will take more time to complete.
> > > I am not sure how longer it is.

A STUN server being behind a NAT is irrelevant from the view of the
STUN client (assuming it knows how to contact the STUN server).  The
NAT in front of the STUN server doesn't change the address of an
incoming request from another client.

Similarly, a TURN server being behind a NAT is irrelevant as long as
both peers can contact it.  A peer that wishes to be a TURN server but
is behind a bad NAT is probably better off not being a TURN server,
but that is about it.

What matters is the kind of NATs the client (A and B in your example) is behind.

> >
> > There are two variables:
> >
> >   1. how many candidates you could gather
> >   2. how quickly your peer can send connectivity checks
> >      to those candidates
> >
> > To the first point, in the diagram you provided in your earlier email,
> there
> > are only three candidate addresses:  one from the local interface, one
> from
> > the STUN server that is behind the same NAT you're behind, and another
> from a
> > STUN server on the Internet.  Are there network topologies where more
> > candidate addresses would be learned?
>
> Even if there are enough candidates who could be learned by using enough
> servers, how could ICE sort the candidate pairs in the order so that the
> workable pairs could be considered as soon as possible?

The reload-02 section I pointed you to describes this very briefly,
but let me try to provide more details. In almost all cases, A and B
will be behind friendly NATs.  In your particular example, no matter
how many STUN servers B uses, it will know two candidate addresses.
In A's case, it will know two or maybe three if it has C in its list
of STUN servers.

Two points to note here.  First, for peer protocol connections, there
is no need to gather candidate addresses when you wish to establish a
new connection because you can do that over time.  Second, reload-02
suggests that you maintain sets of peers grouped according to the
reflexive address they return, then make one query to each when you
gather candidates for media connections (or refresh your peer protocol
addresses).

Now the less common, but important case, is when A or B is behind a
p2p unfriendly NAT.  Any of your NAT1, NAT2, NAT3 could be unfriendly.
 In this case, what will happen is that A or B will discover that as
they make connections with new peers, the number of different
reflexive addresses that they see grows.  In B's case, it will
probably grow infinitely large.  In A's case, assuming there is more
than Peer C behind NAT 2 with it, if NAT 2 is the unfriendly NAT A may
observe several peers reporting the same reflexive address because
they are also behind NAT2.  In these cases, A and B should provide
addresses they see repeated as ICE candidates, but there's unlikely to
be any point in providing a list of every reflexive address ever seen.

In any event, when ordering the candidates for an ice offer, start
with the local address and list the learned addresses in the order of
their frequency.  That will very rarely be more than two.

Bruce

_______________________________________________
P2PSIP mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/p2psip