W3C home > Mailing lists > Public > public-webrtc@w3.org > May 2017

Re: Notes from May 2nd VI

From: Cullen Jennings <fluffy@iii.ca>
Date: Sat, 6 May 2017 08:00:06 -0600
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-Id: <542E5A70-12A9-4FC5-B0F9-D06AAF04389B@iii.ca>
To: Stefan Håkansson <stefan.lk.hakansson@ericsson.com>

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

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