- From: <piranna@gmail.com>
- Date: Mon, 6 Jan 2014 19:10:58 +0100
- To: Eric Rescorla <ekr@rtfm.com>
- Cc: public-webrtc <public-webrtc@w3.org>
>>> The part that I think will survive "forever" is, however, the need to have a >>> signalling path in order to start communicating. That's something I don't >>> expect to see workarounds for. >>> >> I know currently WebRTC doesn't allow it, but in other environments, >> is there any way to don't need a signaling path to start the >> communications? I have been reading a lot since more than a year about >> this topic to see if it would be added but didn't found anything... >> The most "P2P distributed" way I've find is using DHT, but it also >> needs a way (mainly directly pointing by IP and port) to bootstrap on >> the DHT network... :-/ > > More or less no. The problem is NAT. > Sh*t :-( >> It seems that with ORCA I would only need the connection configuration >> (the "SDP" info) of one endpoint instead of needing to exchange both >> of them (it would be similar to the "directly pointing by IP and port" >> thing on the DHT). This will greatly help to my purposses, but until I >> could be able to test it I'm not totally sure about it :-( > > That's not really going to work unless you basically are on a public > IP address with no firewall. The issue here isn't the properties of > PeerConnection but the basic way in which NAT traversal algorithms > work. > I know that the "IP and port" think would work due to NAT, but nothing prevent to just only need to exchange one endpoint connection data instead of both... -- "Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton de sitios diferentes, simplemente escribe un sistema operativo Unix." – Linus Tordvals, creador del sistema operativo Linux
Received on Monday, 6 January 2014 18:11:46 UTC