W3C home > Mailing lists > Public > public-webrtc@w3.org > January 2014

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

From: Cullen Jennings (fluffy) <fluffy@cisco.com>
Date: Fri, 17 Jan 2014 00:18:59 +0000
To: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <0E0D435F-1C06-40B1-BFA7-EB583E5F958A@cisco.com>

It’s a bit hard to decide if all of these are just the spec or some of them are implementation limitations. I’m trying just to focus on things that are limitations of the specs. Few things off top of my head. 

When anything goes wrong, very hard to know what happened. For example, if ICE connectivity fails, no way to debug. 

Create an offer requesting multiple video streams. 

Very difficult to provide a reasonable UX for which microphone gets picked when there are multiple 

Hard to know when things are failing due to permissions 

Not clear what can be done when there are multiple PeerConnections

No good ways to control bandwidth usage and priorities when multiple video steams

Changing microphones , cameras etc mid call 

Persistent permission model 

knowing who the media is encrypted to 

Knowing the applications are not creating fake data 

Understanding what happened when SDP fails at a semantic (not syntax) level 

ICE Candidate pools missing 

Information about voice and video quality 

Changing resolution on one end migrating back to other end. 

Not clear exactly what callbacks one can expect to get when. 

MTI Video codec :-) 



On Dec 21, 2013, at 11:50 PM, 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 Friday, 17 January 2014 00:19:28 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:37 UTC