Re: a new API proposal

On 08/01/2013 12:44 AM, piranna@gmail.com wrote:
> Due to my work I have need to read the last days the current WebRTC
> specification. As you would know, I have been interested and focused
> the last months only on DataChannels and I was very critic and upset
> about how much work was needed to create a simple DataChannel between
> two browsers (SDP, offer/answer, candidates...), but know that I have
> read about how media streams are suposed to be used, now I can say
> that the WebRTC is fairly overcomplicated.
>
> So, I have asked myself, now that I know how it works, how I would do
> it? And I've got some conclusions that I think would be easy to be
> integrated and I hope you find interesting enought to be debated.
> Please don't take in account if there are some errors and only take in
> account the proposed concepts.
>
> First of all, have on PeerConnection object an "autosignal" option.
> When disabled, PeerConnection would require an external signaling
> channel as is currently done, but if enabled, then an internal channel
> is created between both peers as soon as possible and since then all
> the signaling messages between both peers are transfered automaticaly
> and transparent to the developer using this channel. Or explained
> using current WebRTC concepts: if this autosignal option is enabled,
> then the offer and the answer would return only the minimal data to
> allow to create the connection between both peers and an internal
> communications channel (a hidden DataChannel or just a plain socket,
> but it doesn't matter if it's bandwidth reduced), and after that this
> channel is used to transfer the subsequent candidates and do the
> renegotiation between both peers: add and remove streams, change
> resolution and quality, mute... As I said, this channel is purposed to
> be internal and hidden, but it would be discussed to allow to use it
> with send() / onmessage so it would not be required by the
> applications to create dedicated DataChannels for
> application-dependent purposes if latency or high-bandwidth are not
> required (instant messaging, user interaction events...).
>
> Second thing, having reduced so much the required data to be
> interchanged between both peers to create the communication since all
> the data synchronization is done using the internal signaling channel,
> reduce it to the bare minimum. As far as I know, with this method it
> would be only required the STUN/TURN data so it's possible to know on
> what port is listening each peer, and this data would be given by the
> API as just an array with an object for each NAT and proxy that it's
> needed to be transpased with their IP/domain, port, authentication...
> This is a fairly basic data that can be serialized and transfer in
> several ways, being this JSON or SDP or any other.


You have of course also required that there be agreement on what the
signalling protocol that is sent over this channel is, and you have
required that the initial negotiation (carried outside of the data
channel) results in agreement on what the protocol is, which, if we want
interoperability to happen, requires us to have a mandatory to implement
signalling protocol.

Which, in turn, seems to me to be a more complex version of the problem
we're currently trying to solve.

Be careful what you ask for.

Received on Friday, 2 August 2013 09:27:40 UTC