Agenda
<scribe> Scribenick: hta
Carine confirms that the recording has started.
bernard: Stefan has stepped down as the chair of the WEBRTC WG.
Issue 28: permission name "display" accepted. Jan-Ivar to draft text (both for permission and feature policy).
discussing issue 61: system audio capture
decision: {audio: true} is
ignorable - getDisplayMedia can succeed even if no audio can be
produced.
... {audio: true} lets the implementation choose sources.
... {audio: true} will not produce an audio track if no audio
is produced (and can never be produced for the stream produced
by this getDisplayMedia call).
... we'll discuss {audio: {excludeApplicationAudio: true}}
further on the list.
Discussing issue 62: High level source filtering
Decision: Don't add this. Go back to github and ask for more compelling use cases.
<dom> Describe what happens if the window is closed or the monitor is disconnected
Discussing issue 72: Describe what happens if the window is closed or the monitor is disconnected
Decision: window closed ->
ended is OK.
... monitor disconnected -> ended can be a MAY; consider the
reconnect scenario some more.
... muting when minimized. In other cases where no more frames
are produced, tracks should be muted (for consistency).
Advice to the implementor for various cases (screenlock....) would be nice to have.
AI on hbos to create PRs for these.
Discussing issue 77: getDisplayMedia in SecureContext only?
Decision: option 2 - [SecureContext] for getDisplayMedia.
Decision not taken on [SecureContext] for getUserMedia. Discussion will occur later.
Now discussing webrtc-pc spec
Discussing issue 1858: What happens when an answerer stops a transceiver that is the basis of a bundle?
Decision: Agreement on bernard's
recommendation #1 and #2.
... Put in warnings. More text needed.
<dom> Issue 1888: quick fix #2 seems appealing, low risk of breaking compat given limited impl
<dom> issue 1896: congestion control should NOT be affected by the order
proposals #1, #2 and #4 are accepted. proposal #3 is rejected.
Issue 1882: RTCPriorityType is not documented for simulcast
RTCPriorityType not documented if simulcast layers have different priorities, how they are prioritized, etc.
Quick fix #1: Claim all encodings must have the same priority, compatible with current, looks silly.
Quick fix #2: Move the priority to the sender object.
Slow fix #1: Define behavior of priority between different encodings.
Decision: Quick fix #2. Details of how it is exposed on the sender TBD.
Issue 1896: Order of RTCRtpSendParameters.encodings is not described
People have made different assumptions about order. No clear “best way” to do it.
Proposal: Order is consistent. Simulcast layers are truncated from trail.
Bernard: Does anyone do things differently depending on encoding order? Makes sense to drop the biggest first. I’m just worried about if this affects congestion control.
[With regards to order making a difference] Is this going to increase complexity for implementers based on no real benefit for applications?
Youenn: I think for 1.0 we could let the user agent decide that. Drop the highest layer first, and so on.
Jan-Ivar: That sounds better to me.
Bernard: Me too. Can we say congestion control is not affected by order?
Jan-Ivar: If you expose too much control then the application has to do more.
Decision: We don’t define the order but it has to be consistent, all we say is congestion control don’t affect order. The sendEncoding order should be reflected in the SDP, but it doesn’t affect congestion control.
If addTransceiver sendEncoding argument order matters is a separate issue.