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

On 2013-07-09 10:34, piranna@gmail.com wrote:
>>> 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). :)

>
> 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.

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.

>>>> 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).

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?

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.

/Adam

Received on Tuesday, 9 July 2013 11:53:41 UTC