Re: What is missing for building "real" services?

Both myself and my employer use WebRTC for real tasks, but I see several
issues:

* Lack of support, it's still too much cutting edge
* Unstable and incompatibles APIs, leading to too much headaches
* Bad error notification (difficult to debug)
* Too much focused on P2P audio & video, while it's a somewhat marginal,
particular use case. Most of it is client-server or point-to-multipoint
instead, needing a WebRTC MCU to manage them. For client-server I find more
useful XHR now that they are starting to support streams both for download
and upload (and for download you has DASH and HSS/HTTP range), but for
serverless P2MP I don't know any current alternative that would fit better.
* Too much attached to telcos, SDPs and offer/answer are a pain in the *ss
and DataChannels are mostly second line gamers, while a more simple and
reliable would be made if audio & video streams would be builded on top of
them
* Requeriment of a bi-directional, off-the-wire signaling channel to do the
initial handshake

Send from my Samsung Galaxy Note II
El 22/12/2013 10:10, "Alexey Aylarov" <alexey@zingaya.com> escribió:

> It's not true. We offering service built using WebRTC to hundreds of
> businesses and I know a lot of other companies doing that. Of course, we
> have to use fallback to Flash for older browsers and the ones that don't
> support WebRTC yet, but it's not WebRTC problem.
>
> Best Regards,
> Alexey
>
> > On Dec 22, 2013, at 10:50, Stefan Håkansson LK <
> stefan.lk.hakansson@ericsson.com> wrote:
> >
> > During the telechat last Thursday some persons said that WebRTC is
> > sufficient to do demos, but not sufficient for building a "real" service
> > on top of.
> >
> > I would really like to know more. If you can't build a service on top
> > off WebRTC I think we have failed. Would anyone care to expand a bit on
> > what is missing/wrongly designed? And explain the context/use-case.
> >
> > Stefan (speaking for himself only)
> >
>
>

Received on Sunday, 22 December 2013 10:20:32 UTC