Notes from May 2nd VI

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

Received on Wednesday, 3 May 2017 08:20:56 UTC