Re: a new API proposal

I would agree that designing such an API with current WebRTC implementation
is quite a mental exercise, but it is doable and I doubt it will have any
significant performance issues. In general parties are added and removed
from communications fairly infrequently in comparison with dealing with
actual data being transmitted. Because of this almost anything that you
need to do once per each party has almost no performance impact whatsoever.
Building such a library on current API would produce something that would
be a bit more fragile (ie sensitive to future API and SDP changes) and
complicated (in terms of doing more then one offer/answer exchange per
single participant connection) then some of us would wish for, but it will
be usable.
_____________
Roman Shpount


On Wed, Jul 31, 2013 at 7:12 PM, piranna@gmail.com <piranna@gmail.com>wrote:

> Well, I only know WebRTC from a Javascript point of view and don't know
> too much about the internal technology except what has been talked here, so
> I think is obvious... :-D I know it's possible to develop partial if not
> fully all my proposals in Javascript (I was doing it mentally just as a
> mind game with the idea to show a prototype just when I received youe
> email), only that I find fairly absurd to develop a state-less API like
> mine over a stateful API like WebRTC Offee/Answer over a state-less API
> like browser internals... and the same happens to don't require SDP over an
> API that require them. I know it's mostly doable on Javascript, but I think
> it makes more sense and would have some improved performance done at a
> lower level.
> El 01/08/2013 01:02, "Roman Shpount" <roman@telurix.com> escribió:
>
> 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
>>>
>>>
>>