On Mar 18, 2009, at 7:17 AM, Henning Schulzrinne wrote:
True peers (not clients) behind NATs won't work unless they initiate
the connection anyway, so I'm a bit confused by the model you have
in mind.
A signal comes over an existing connection, causing the peer to send
UDP out to a node that can report the address/port number in use. This
address/port set is exchanged with the other peer via the existing
connection, then the peers contact each other directly using the
discovered address/ports. Doesn't work for all NATs, but does for
many. And we don't have a trick for doing that with TCP yet, although
I'm working on one.
And if this doesn't work, we can fall back to using a relay.
Barring elimination of NATs, the next best trick would be to build ICE
directly into the TCP stack. That would be interesting. But talk about
a forklift upgrade! OTOH, it might be possible to do this in such a
way that it is backward compatible with TCP; that is, a node using
iced-TCP could talk to one using standard TCP. Additional behavior
would be required in the NAT, but that's not entirely out of the
question. More thought required to keep from reinventing RSIP.
--
Dean
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
