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

> From: Dan Wing [mailto:dwing@cisco.com]
> 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:jiang.x.f@huawei.com]
> > 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
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip