- From: Vivien Lacourba <vivien@w3.org>
- Date: Thu, 04 May 2017 14:53:20 +0200
- To: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
In addition to the chair's notes you can find a PDF version of the slides and audio/video recording here: https://www.w3.org/2011/04/webrtc/wiki/May_2_2017#Minutes Vivien On Wed, 2017-05-03 at 08:20 +0000, Stefan Håkansson LK wrote: > Hi all, thanks for a productive meeting yesterday. This is what we noted: > > - Review full document: Bernard, Cullen, Ekr and Taylor will review the > full document for compliance to the technical requirements, and report > back by end of May, preferably in the form of github Issues. The chairs > will then together with the group decide what Issues that need to be > resolved before requesting transition to CR. > > - We will remove the “feature at risk” for Identity (and also revisit > the other features currently marked such as RTP/RTCP non-mux and the > getAlgorithm method) > > - There was a discussion on how deep the “two independent > implementations” must be independent, and discussion about testing. Dom > noted that testing interoperability of all protocol aspects of WebRTC is > out of scope for the W3C process. Bernard talked about the difficulty > of even testing all aspects of the current API, such as features that > typically utilize a centralized conferencing server (such as Simulcast). > Dom noted that development of the test suite is one of the tasks that > begins after CR. So we do not have to have all the answers now. > > - Issue 1073/Issue 1116/PR 1134 (Taylor): Return encoding parameters and > default values before the RD is set. Needs details relating to other > aspects of RTCRtpParameters (such as degradationPreference and rtcp), > but going in the right direction. Let the PR get more review (a lot of > detail needed). There is already a table defining read/write attributes > for setParameters(). > > - Issue 1101/PR 1133 (Taylor): PR looks good, we can merge. > > - Issue 763/PR 1150 (Bernard): Proposing to add three new errors. Cullen > likes to have a maxEncodings, even if it could be dynamic. Invalid > codec: proposal to return a sequence with mime types. Taylor: we should > separate invalid parameters (already covered by > InvalidModificationError) from not supported by the browser parameters. > Bernard to update PR. > > - Issue 1092/1115: (Bernard): goal is to enable applications to respond > to recoverable DTLS errors, so need to distinguish recoverable errors > from non-recoverable errors. Ekr: We should distinguish alerts sent from > alerts received. In NSS we handle many errors beyond alerts by > surfacing some free form JS error stuff. Only way to provide enough > information to understand what exactly happened in situations such as > when a browser provides an ECDSA certificate to an implementation which > only supports RSA (alert number is not enough). Cullen: We are having > issues determining what went wrong when dealing with intermediaries > acting as a DTLS man-in-the-middle. Would like to see error reported in > a common way across browsers. There should some alert about whether you > sent or received the message, and perhaps implementation specific data > in form of a string. Example: NSS Error, with a string. Bernard will update. > > - Issue 1138/PR 1145: (Foolip): Frozen array is only shallowly frozen, > better to return a sequence which is a copy. We can update without > breakage since none of this has been implemented, so let's do that. PR > to be merged. > > - Issue 1128: MSID (Taylor): Track ID won't match in many cases, e.g. > replace track. Does not matter since we have MID. Need stream Id to be > carried over to not break apps. Let's investigate if we can move to > local only Track Ids (and not signal it in the SDP). Will be a little > bit weird since Stream Id is carried across, but best solution we could > think of at the meeting. > > Bernard & Stefan > -- Vivien Lacourba World Wide Web Consortium vivien@w3.org http://www.w3.org http://www.w3.org/People/Vivien Tel: +33.4.92.38.78.89
Received on Thursday, 4 May 2017 12:53:30 UTC