- From: Cullen Jennings <fluffy@iii.ca>
- Date: Sat, 6 May 2017 08:00:06 -0600
- To: Stefan Håkansson <stefan.lk.hakansson@ericsson.com>
- Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
Thank you for doing these minutes for the call. Two small extra things from the call that I think are important. > On May 3, 2017, at 2:20 AM, Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com> 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. I think the notes are missing one key item which is that only on the call when we asked who had recently reviewed the whole document, we got one person. > > - 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. Also it was noted on the call that we do not have a clear idea of what are our exit criteria to exit CR. > > - 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 >
Received on Saturday, 6 May 2017 14:00:37 UTC