On Feb 3, 2008, at 12:36 AM, Dan Wing wrote: > > > With the functionality to trigger to the TURN server through the > overlay, we > can run a TURN server even behind an address-filtering NAT (but not a > port-restricting NAT or a symmetric NAT). Without the > functionality to > trigger the TURN server, we cannot run behind an address-filtering > NAT. >
I think this is one of the complicated questions about this type of service for an overlay. It allows functionality that is helpful in many cases, but is not as helpful as a fully open TURN server. Is it worth the effort to spec, implement, and provide such a service? My suspicion is that it depends on the type of deployment: a commercial service provider wouldn't care, a public unhosted overlay might consider the service worthwhile. > > I don't know what (pre-standard) version of ICE that Google > implemented, nor > do I recall which version of ICE added the ability to communicate > directly > even with address-restricted NATs. The standard version of ICE > does something > vaguely like the above: it sends a message through the overlay (the > Offer/Answer exchange, using SIP), and that message causes both > peers to try > to communicate with each other, which allows two peers with address- > filtering > NATs to communicate directly with each other (without a relay). > The ability > to communicate through the p2p-sip overlay to the TURN server > provides a > similar capability so that a TURN server can be behind an address- > filtering > NAT. > This was one of the big reasons we put the TUNNEL method into reload-01. It's very useful to use the overlay as a rendezvous service for a variety of applications (SIP and ICE being the most obvious for sip applications). For some applications, by itself it may be enough to exchange the application-layer messages, although I think media is best not relayed through an overlay. Bruce _______________________________________________ P2PSIP mailing list [email protected] http://www.ietf.org/mailman/listinfo/p2psip
