W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2013

Re: Expose capabilities / Allow for IP:Post based connections / Better abstraction

From: <piranna@gmail.com>
Date: Tue, 9 Jul 2013 10:34:35 +0200
Message-ID: <CAKfGGh0JRjf45uNxsPOHVa-4scYT+PUk5ziCYrwrW-bxjrZumg@mail.gmail.com>
To: Adam Bergkvist <adam.bergkvist@ericsson.com>
Cc: Johannes Hange <moooitic@mailbox.tu-berlin.de>, public-webrtc <public-webrtc@w3.org>
>> So candidates are mandatory? What's the data that needs to be
>> interchanged? I have seen that up to seven candidates are
>> interchanged, why so much? Couldn't this be made transparent to the
>> user?
> Yes. On a high level, the data describes the different ways you may be
> reached. There are many of them to increase the possibility of a successful
> connection. I think this part of the API is rather OK. All you have to care
> about is sending your generated candidates to the other side.
Ok, that way it make sense, althought I would prefer it would be more
simple and transparent like WebSockets... :-P

What about creating by default an internal DataChannel to support this
things transparently to the user? Or it would be better to be done on
an upper API as I'm currently doing? Cound candidates being send all
in one message instead of several ones?

>>> The web app can't set it's own ports and the receiver ip/ports for
>>> security
>>> reasons.
>> I totally agree, publicly allow random connection with IP:port is a
>> security issue, but there should be an option to directly connect
>> without needing a handshake server and having at most the STUN data.
>> At this moment I'm using UUIDs to identify the peers on the server and
>> interchange the SDP strings, but there should be an easier,
>> no-server-dependent solution to be able to develop a real serverless
>> P2P architecture...
> I think I've asked this question before,

Probably... personally I'm very worried about this point :-/

> but how do you find the person you want to talk to in this case?
> Some entity would have to have a register that
> describes how everyone, for example on your contact list, can be reached;

I'm using UUIDs as identifiers, and XMPP anonimous servers and a
public MUC to do the initial handshake to create some-alike dinamic
anonimous DNS (this autogenerated UUID correspond to this
PeerConnection object). For LANs it would be used ZeroConf, but for
global Internet I didn't found any better option (and trust me I'm
desesperatelly looking for it...).

> are you saying that you want the STUN server to have that?
Oh, no, this would be crazy, but it's true that if STUN server would
have some way to upload snipets of data to the browser (since it has
already a connection to it) this would be solved, so when one peer has
the SDP of one end it could send their own SDP and STUN upload it, so
both peers could have both local and remote descriptions and could
create the connection.

> I think it's a fair requirement that you use regular web technologies to
> locate who you want to to communicate with; then you can connect to that
> peer with WebRTC.
I agree, and in fact I try to use them at widest, but the requeriment
to have a "central" server for handshaking I find it superfluous. I
know you can interchange the SDPs by hand via mail or pidgeons, but
anyway it cumbersome... Ideally, once you create the PeerConnection
object, you should be easy to connect to it someway (the "handshake
signaling", but don't necesarily done by the STUN server...) without
needing to deploy your own server or parasiting another one (as I'm
currently doing).

>>> Compare WebSockets [1], which similarly to WebRTC is exposed in
>>> regular browsers, to the Raw Socket API [2] that developed in SysApps
>>> which
>>> is targeting packaged applications and other cases where you have a
>>> manifest
>>> and the app runs in an elevated security mode.
>>> /Adam
>>> [1] http://dev.w3.org/html5/websockets/
>>> [2] http://www.w3.org/2012/sysapps/raw-sockets/
>> Oh, well... good to know about raw-sockets, but seems really crazy as
>> a solution... Isn't there any solution half-way from raw-sockets to
>> websockets/datachannels, or couldn't be able to be developed?
> I guess there was a lot of discussion before the two above alternatives were
> decided on. Perhaps you'll find some info looking there.
Ok I'll take a look :-)

"Si quieres viajar alrededor del mundo y ser invitado a hablar en un
monton de sitios diferentes, simplemente escribe un sistema operativo
 Linus Tordvals, creador del sistema operativo Linux
Received on Tuesday, 9 July 2013 08:35:24 UTC

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