At Mon, 27 Jul 2009 19:17:01 +0200, Bruce Lowekamp wrote: > > On Mon, Jul 27, 2009 at 7:08 PM, Eric Rescorla<[email protected]> wrote: > > > > > > On Jul 27, 2009, at 9:54 AM, Bruce Lowekamp <[email protected]> wrote: > > > >> On Mon, Jul 27, 2009 at 6:47 PM, Eric Rescorla<[email protected]> > >> wrote: > >>> > >>> However, it seems to me that this same effect could be achieved > >>> simply by having the DAP actually be a TURN server. The client > >>> could then connect to the TURN server and through it to the > >>> RP. You get the same message paths, but there's no additional > >>> protocol mechanisms required to tell anyone that this is > >>> a client--everything just works. It also has the additional advantage > >>> that because TURN servers have public IPs, you know you won't > >>> have to send OAP-DAP messages through the overlay. > >>> > >> > >> This doesn't work when peers can be behind NATs. There's no way to > >> ensure that the responsible peer has a public IP and can be a TURN > >> server. > > > > That's not what I said. The dap, which has no special node relationship with > > the client, is the turn server. > > The DAP was being selected for other criteria, such as having an > existing bluetooth connection to the client. That doesn't make it a > good candidate for a turn server, either.
Well, you don't actually need to be a full TURN server, just one good enough to do ordinary connections. But that said, I don't find this Bluethooth special case very compelling. If you're going over Bluetooth, this is much more like having a split client and much less like having a client with an IP connection to some DAP. -Ekr _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
