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

Re: Notes from May 2nd VI

From: Vivien Lacourba <vivien@w3.org>
Date: Thu, 04 May 2017 14:53:20 +0200
Message-ID: <1493902400.6216.8.camel@w3.org>
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

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