> 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. > > 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? Regards! JiangXingFeng _______________________________________________ P2PSIP mailing list [email protected] https://www1.ietf.org/mailman/listinfo/p2psip
