Re: a new API proposal

My first and most obvious question is: Would it be sufficient if the
described functionality were implemented as a JavaScript library? Most of
what you describe is implementable this way even with the current
specification, so why should anybody design a browser API specifically for
this?
_____________
Roman Shpount


On Wed, Jul 31, 2013 at 6:44 PM, piranna@gmail.com <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.
>
> Finally, also the multiconference problem showed the last days can
> also being fixed this way, since several peers would connect to the
> same internal signaling channel and sending and receiving messages as
> a pool, or several signaling channels would be created, one for each
> peer.
>
> With this both things, we have fixed the problems regarding with the
> offer/answer mechanism and removed the requeriment to use SDP while
> still being able to generate it to be compatible with legacy systems
> requiring it, and also we fixed the problems regarding to adding or
> removing streams or when the quality changes, because this can be
> notified sending messages over the internal signaling channel.
>
> That's all for now, please send me any comment or suggestion you have
> regarding this suggestions.
>
> Greetings, Jesús Leganés Combarro "piranna".
>
>
>
>
> --
> "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
>
>