a new API proposal

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

Received on Wednesday, 31 July 2013 22:45:50 UTC