On Jan 23, 2008 4:58 AM, JiangXingFeng <[EMAIL PROTECTED]> wrote: > > From: Dan Wing [mailto:[EMAIL PROTECTED] > > 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:[EMAIL PROTECTED] > > > 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 [email protected] https://www1.ietf.org/mailman/listinfo/p2psip
