W3C home > Mailing lists > Public > public-webrtc@w3.org > January 2014

Re: What is missing for building "real" services?

From: <piranna@gmail.com>
Date: Mon, 6 Jan 2014 19:10:58 +0100
Message-ID: <CAKfGGh1mgbK8P97pQjkzzfTtASBx-oQ-SsxUeqGXW7Zw7b4X=w@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:37 UTC