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