Re: a new API proposal

On Thu, Aug 1, 2013 at 12:44 AM, 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...).
>

Certainly this would work, but it doesn't seem to me to address the
requests people have made for *more* control over the signaling,
seeing as it provides *less* control. Moreover, I don't see that it
really makes things simpler. It's not like the code to call createOffer(),
etc. and shuttle the offer/answer back and forth is particularly
onerous, and it seems to me that that's all it's really saving. Basically,


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

Well, this list isn't exhaustive: you need *all* the ICE information.


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

I don't see how that makes a difference. You still need to specify exactly
what messages get exchanged over this autosignal channel, and those
messages are presumably going to be SDP for all the reasons people
currently want to use SDP.

-Ekr