Sorry for dropping off the thread for so long... On 1/27/08, JiangXingFeng <[EMAIL PROTECTED]> wrote: > > It seems useful to phase this for p2p-sip: initially, just have > > p2p-sip nodes advertise their TURN servers if the p2p-sip node > > is not behind a NAT. > >
This seems like the best first step. It also seems likely that different overlays will have different policies for what defines a good TURN relay. Some provider-based overlays might actually have the provider provision TURN servers, whereas at the other end of the spectrum are overlays that may deploy nothing and rely entirely on individuals who have eligible peers. > > Once we know how to have p2p-sip TURN servers qualify their > > NAT's p2p-friendlyness, then can have p2p-sip nodes advertise > > those TURN servers, too. If we make fast progress on a document > > that describes the qualification procedure, and running code > > that shows it works, we should be good to go. No? > This seems like a fairly straightforward application of nat-behavior-discovery. > > > > TURN client STUN server NAT TURN server > > | | | | > > 1. |------give me a TURN address------->|----->| > > 2. | |<--STUN Request--------| > > 3. | |-STUN Response->|----->| > > 4. |<-----here is your TURN address------------| > > If we allow a TURN server to be behind a NAT, then the only change I would see necessary would that 1 and 4 would have to be routed over the overlay (a reload tunnel, for example). But otherwise, the TURN protocol seems to work as is. For the purposes of a TURN server, a NAT having endpoint independent mapping seems to be the only real requirement on the NAT as long as the two voice endpoints support ICE; the connectivity checks should take care of any form of filtering the NAT uses. Bruce _______________________________________________ P2PSIP mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/p2psip
