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

["Dan Wing" <[e-mail]>]

 

> -----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
> 
> Hi, Dan:
> 
> Thanks for your comments.
> 
> 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?

To the second point, the additional delay depends on how quickly you can send
the connectivity checks to the additional candidates.  This rate depends on
the RTP sending rate.  So, for example, if the endpoint is going to send an
~200 byte RTP packet every 20ms, the endpoint is permitted to send a ~200 byte
connectivity check (to a new candidate) every 20ms.  With 3 different
candidates, that is 3*20ms=60ms of additional time.  60ms does not seem
significant to me.

-d


> --
> JiangXingFeng
> 
> > -----Original Message-----
> > From: Dan Wing [mailto:[e-mail]]
> > Sent: Wednesday, January 23, 2008 10:08 AM
> > To: 'JiangXingFeng'; 'P2PSIP Mailing List'
> > Subject: RE: [P2PSIP] Choice of STUN peer or TURN peer
> > 
> > ICE allows you to have multiple STUN servers.  In the diagram you
> provided,
> > Peer A could contact Peer C, Peer D, and Peer B, and would notice
> different
> > answers from some (or all) of them.  All of those different 
> answers can be
> > provided as different candidates (a=candidate) in the call 
> setup message.
> > 
> > -d
> > 
> > 
> > > -----Original Message-----
> > > From: JiangXingFeng [mailto:[e-mail]]
> > > Sent: Tuesday, January 22, 2008 1:37 AM
> > > To: 'P2PSIP Mailing List'
> > > Subject: [P2PSIP] Choice of STUN peer or TURN peer
> > >
> > > Hi, all:
> > >
> > >
> > >
> > > In order to make the peers serve each other, some peers with
> > > special capabilities could be exploited to play the STUN/TURN
> > > server role for other peers who are behind NAT. Guys in
> > > P2PSIP community has agreed with that peer behind NAT should
> > > seek help from other peers, not centralized STUN/TURN server.
> > >
> > >
> > >
> > > But which kinds of peers are qualified for playing STUN/TURN
> > > server? Of course, Peers on the public internet could take
> > > this responsibility. I also learned from the list that peers
> > > behind p2p-friendly NAT (with end-point independent mapping
> > > and filtering behavior) also could do the same work. But from
> > > my point of view, ICE negotiation procedure may fail if
> > > choosing this kind of peer as STUN/TURN server.
> > >
> > >
> > >
> > > Let's show an example:
> > >
> > >
> > >
> > > Peer A and peer B want to communicate directly. NAT2 is a
> > > p2p-friendly NAT. So peer C would be considered as a
> > > candidate STUN server. If peer A choose the Peer C as its
> > > STUN server, peer A will get a mapping on the NAT1 which is
> > > in the address realm of private network. And Peer A will tell
> > > peer B this server reflexive address. But peer B could not
> > > reach it because it is in different address realm.
> > >
> > >
> > >
> > > Am I missing something? Comments are appreciated!
> > >
> > >
> > >
> > > Regards!
> > >
> > > --
> > >
> > > Jiang XingFeng
> > >
> > >
> > >
> > >
> > >
> > >
> 


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