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

>>>> 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
>
> It's is a whole lot easier with a server that's always reachable (it's not a
> very useful server otherwise). :)
>
Yeah, I know :-D Probably I'm too much focused on my own use case (a
P2P framework and filesharing application. Some people compare its
architecture with Gnutella network), where anonimity and pure P2P are
the main corner cases...


>> 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 problem with sending candidates over an internal DataChannel is that you
> can't set up the channel (assuming it's p2p) until you have exchanged
> candidates since the peers can't reach each other yet. It becomes a chicken
> and the egg thing.
>
Also including them on the offer/answer messages?


> You can gather all candidates and then send them. That will take some more
> time, and if an early candidate was useful then you'll make your
> communication setup take more time than it had to.
>
Ok, I agree it makes some more sense as it's at this moment.


>>> 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).
>
>
> So we're on the same page that regular web technologies should be used in
> the setup process of WebRTC. Then, are you aware of any web service where
> two clients communicate with each other without involving a server?
>
Web services no, since until now we didn't have support for P2P
connections... :-D On the other hand, original idea of Tim Berners-Lee
was Internet being pure P2P, only that client-servers are easier to
develop, and also there is a discarded W3C proposition to allow web
pages inside browsers to work as web servers just hooking some paths
on the "web browser web server" root path and using some dynamic DNS
magic to access to them... :-) In some way and in the long run, my
intention with my P2P framework (and in fact the intention of
everybody currently working and experimenting with DataChannels) is
somewhat allow to do this use case :-)


> Any web-based communication would need a server to exchange messages between
> clients. For example, in a chat service, you would probably do an XHR to a
> server to send your chat message to the other participants. If I were to add
> audio and video to such a call (with WebRTC) I could send the session
> descriptions via the same server but as a message type other that "chat
> message". So what I'm saying is that there's no requirement for a "central
> server" that only does handshaking. A lot of services would send the session
> descriptions on the same transport between clients as they send other data;
> for example presence information or chat messages.
>
Yes, and in fact I'm using them (PubNub channels, annonimous XMPP
servers and also my own protocol SimpleSignaling, and I have on the
radar to be able to use SIP-over-WebSockets), but the fact of parasite
this services and none of them giving a definitive solution nor found
a better one yet still give me some hackerish/homebrew/amateur/not
profesional/not serious sensation... :-/


--
"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 Tuesday, 9 July 2013 13:02:09 UTC