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

[JiangXingFeng <[e-mail]>]

> 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.

The following is another story. For peer to be a TURN server, how could TURN
clients get their allocated transport address belonging to the TURN server
if the TURN server is behind NAT? Because in TURN, the allocated address is
encapsulated in the message and then communicated with the clients, but due
to NAT, the allocated address could not be contacted by the clients in the
future. 

Am I missing soothing?  
> 
> 
> 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).

Thanks for your explanations. You mean that reload-2 uses the reflexive
address from its peers as its peer reflexive address candidate?

What my concern is how the peer learns the reflexive address when it just
joins the overlay? It should find a bootstrap peer? Must the bootstrap peer
have a public address? If not, how could the peer contact directly with the
bootstrap peer? 

Another concern is: although a peer could gather candidates over time, the
first reflexive address SHOULD be on the public Internet (If bootstrap peer
has to have a public address). The peer must actively find the STUN servers
and only passively relying on the packets from its peers to get reflexive
candidate is not enough because its peers could not contact him directly due
to NAT. 

One more question here is: how do you define p2p-friendly NAT in terms of
filtering behavior? Do you refer to end-point independent filtering or
others? If it is the case, the security property would be sacrificed.  

> 
> 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.

Whatever method being used to sort the candidate, if two candidates in the
candidate pair is not within the same realm, the connectivity check must
fail, hence the connectivity check time will be prolonged. 




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