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

> -----Original Message-----
> From: JiangXingFeng [mailto:jiang.x.f@huawei.com] 
> Sent: Thursday, January 24, 2008 6:12 PM
> To: 'Dan Wing'; 'Jerry Yin'
> Cc: 'P2PSIP Mailing List'
> Subject: RE: [P2PSIP] Choice of STUN peer or TURN peer
> 
> > The p2p-sip TURN server, prior to those messages above,
> > determined its publicly-routable IP address and publicly-
> > routable UDP port.  It may have determined that via STUN
> > (or, if there is only one level of NAT, it might have
> > determined that via UPnP or NAT-PMP).
> > 
> > The p2p-sip TURN server also determines that it can receive
> > STUN requests from arbitrary STUN clients via that port; Bruce
> > I believe has written up how a TURN server makes that
> > determination.  Once the TURN server has made that determination,
> > it would register itself as a TURN server in the p2p overlay
> > network.
> 
> How do you assume the filtering behavior of the NAT which is 
> in the front of the TURN server?

You can test it, and hope your test accurately reflects the
NAT's filtering behavior when real traffic is attempting to
traverse the NAT.  

I am not aware of a better technique, unless you know you
are behind only one NAT (in which case you can use UPnP or
NAT-PMP, both of which require no filtering on the NAT).

> If it is not end-point independent 
> filtering, how could the
> TURN client's request reach the TURN peer behind the NAT? 

It wouldn't.  The p2p-sip TURN server needs to determine if 
it's behind that kind of NAT prior to declaring, to the 
p2p-sip network, that it is a TURN server.  That is part
of the qualification procedure the p2p-sip TURN server
needs to do.

-d

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip