Re: Recap from WebRTC World

On Jul 23, 2013, at 11:28 PM, cowwoc <cowwoc@bbs.darktech.org> wrote:

> On 24/07/2013 12:55 AM, Cullen Jennings (fluffy) wrote:
>> On Jun 27, 2013, at 8:19 AM, Gili <cowwoc@bbs.darktech.org>
>>  wrote:
>> 
>> 
>>> Hi,
>>>     (If you'd like to respond to individual points, please start a separate topic)
>>>     I'd like to start a discussion of issues that came up during the WebRTC World conference (in sessions and while speaking with Dan Burnett and Cullen Jennings):
>>> 	• Ending the VP8/H264 war: A proposal was made to mandate a patent-unencumbered codec (whose patents have expired or are not enforced) as mandatory and optionally upgrade to other codecs such as VP8 or H264 depending on peer capabilities and personal preferences. VP8 guys can use VP8. H264 guys can use H264. And if the two camps need to chat with each other they can fall back on H263. This gives you the flexibility of arbitrary codecs without the need to do transcoding.
>>> 	• The WebRTC API needs to focus on normal web developers, not not telecom experts: The conversation on this mailing list is unduly skewed in favor of telecom experts which make up a tiny minority of WebRTC end-users. We need to find a way to collect feedback from the Javascript community at large in order to ensure that the API facilitates their use-cases. The proliferation of WebRTC SDKs for end-users (the conference was full of them) is a strong indication that there is a gap to be filled.
>>> 	• Implementers vs End-users: The specification document has two target audiences, implementers and end-users. We need to provide implementers with a lot of low-level detail but make as little guarantees as possible to end-users to leave the door open to future change (without breaking backwards compatibility). We discussed explicitly marking-up sections of the specification "for implementers" or "for end-users" or separating the specification into separate documents. We need to make it clear, for example, that the specification does not make any guarantees regarding the contents of the SDP token. Implementers need a detailed breakdown in order to implement WebRTC 1.0 but end-users may not rely on these details because the token might not even be SDP in future versions.
>>> 	• SDP: Users should interact with the Constraints API instead of SDP. It is true that there are some use-cases that are not yet covered by this API (forcing you to manipulate the SDP directly) but the plan is to address all these use-cases by 1.0 so users never have to interact with SDP directly. "If your use-case is not covered by the Constraints API, please tell us right away!"
>>> 	• Offer/Accept: There are plans to enable peers to query each other's capabilities and change constraints (and as a result the offer/answer) in mid-call.
>>> 	• Troubleshooting WebRTC: We need to do a better job diagnosing WebRTC problems. We need a user-friendly application (run by non-developers!) for quickly debugging network and microphone problems (Skype does this), and allow users to drill down into more detail if necessary. We also need programmatic access to this API so WebRTC applications can detect problems at runtime and decide (for example) to refund users who paid for a call that was subsequently aborted due to network problems.
>>> 	• Use-cases, use-cases, use-cases: "Tell us what is wrong, not how to fix it". You are a lot more likely to get traction for your problems if you help us understand your use-cases then trying to argue for change for its own sake. On the flip side for specification editors, I encourage you to actively engage posters (ask for these use-cases) instead of ignoring discussion threads ;)
>>>     I encourage other people who attended the conference to contribute their own discussion points.
>>>     (If you'd like to respond to individual points, please start a separate topic)
>>> Thank you,
>>> Gili
>>> 
>> So I take it you expected some sort or response to this from me. I don't really know you wanted me to say. A bunch of this I agree with, the parts I don't are already well covered in previous discussions of the WG. 
>> 
> 
>     I believe the following proposals were not addressed to date:
> 	• Mandating an unencumbered video codec as a baseline, and allowing arbitrary video codecs (H264, VP8, etc) to be negotiated as an upgrade path. To clarify, this proposal isn't meant to favor VP8 or H264. It is meant to eliminate the possibility of future IPR issues without while leaving the door open to better codecs depending the device capability at runtime (think hardware codecs, and codec licenses).

This has been widely discussed, is not relevant to this WG, and is a topic that will likely come up next november at IETF. People will be more likely to reply at that point but if you watch some video from a codec that is certain to be royalty free, I think you will understand the issue. 

> 	• How do we address the fact that the WG does not represent web developers? (I believe we are in the middle of having this discussion)

I suspect we are closer to the end of the discution than the middle of this discussion. 

Let start at a high level. I and many other people here doubly believe in the principles of http://open-stand.org/principles/ and more importantly W3C and IETF believe in that. One of the key principles is balance, which is around inclusiveness. W3C allows anyone to become members of a WG (part of the "open" in "open-stand"). Decisions are made by the members, some who are developers and some who are not. Practically this means that decisions about this API are getting made by some people that are developers and some that are not. The W3C thinks that is a good thing. So do I - I like diversity it all it's forms. 

Of other importance, it would be an anti trust issue if we decided that all members were equal but web developer members were more equal than others. 

A change of this type would require fundamental process changes at W3C. Theses process changes could not be done inside this WG. 

The other issue is what you think a web developer is. I suspect that you think of me as a telco but consider for a moment that I deal with thorny web issues for a very large group of web developers that build webex which is what some analyst consider the #2 cloud provider (behind salesforce.com). Not sure I see it as the #2 but any way you look at it, webex has a lot of web developers working on it and needs to deal with all of the long term hard web developer problems. I think the more you look at it, you will find it hard to decide who is a web developer, who is implementing browsers, and who is a telco. I don't tend to use theses types of distinctions between people. Obviously google has some pretty talented people around web development and web API design. Thinking they don't know how to do this just because they also produce a browser would be a bad assumption.



> 	• Implementers vs End-Users: Shouldn't we have separate documents for the two target audiences?

This was more or less sorted out when the WG was formed so whatever I think is sort of irrelevant to discuss at this point. But just so you know, I believe very strongly the answer to this is "No" because otherwise they are out of sync and inconstant with each other. A small number of people need to read the spec, most people can simply buy http://www.webrtcbook.com/ and ignore the spec

> 	• Troubleshooting WebRTC: There is a gaping hope when it comes to user-facing diagnostic tools.

I think most people following this works know we intent to add more to the stats API. If you want to improve this, I would suggest looking at metrics that are already defined for RTCP and RTCP-XR and pick which ones you need to solve this then come up with a concreted propel for adding theses to the stats API including why they are the right set. 

I was nearly in tear of laughter as you explained to EKR how Skype works. I don't know if you know but Eric was one of the most senior engineers at Skype. I wonder if he qualifies as a web developer - there is code he wrote in Skype, Facebook, WebEx, Chrome, Firefox, as well as many web servers. 


> Thanks,
> Gili

Received on Wednesday, 24 July 2013 07:03:38 UTC