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.
I think the concept of allowing a client to be contacted by routing a
message to the client's Node-ID regardless of whether it is directly
attached or not is a very useful one. I think a couple minor changes
might be needed to the base draft to allow an extension or usage to
specify how to do/manage this behavior, but I believe it's definitely
worth the effort.
1. I'm unconvinced. The arguments presented so far seem weak
2. The changes in this draft don't seem minor to me
Ekr
Bruce
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
