See also: IRC log
<dom> ScribeNick: jib
New permission definitions are wrong. #350
jib: jib People should review PR 421
Add Privacy Indicator Requirements #421
<scribe> ACTION: People should review PR 421 [recorded in http://www.w3.org/2016/12/12-webrtc-minutes.html#action01]
Define restrictions on device-info permission. #380
<scribe> ACTION: People should review permissions/131 [recorded in http://www.w3.org/2016/12/12-webrtc-minutes.html#action02]
Reinstate strong language on permission ending when tracks stop, lost by editorial mistake #387
jib: I think we are good on this one
Polling enumerateDevices potentially being a fingerprint. #403
Bernard: This is solved by PR412.
Rules for when devicechange events may fire #412
jib: agree
shijun: agree
Devicechange events when not focus - permitted or forbidden? #414
Shijun: ok for jib to add clarifying text about MUST NOT in a pr
<scribe> ACTION: jib to provide PR to clarify MUST NOT [recorded in http://www.w3.org/2016/12/12-webrtc-minutes.html#action03]
<trackbot> Created ACTION-121 - Provide pr to clarify must not [on Jan-Ivar Bruaroey - due 2016-12-19].
result of enumerateDevices when there is no origin #417
Shijun: I think it's ok to leave spec as is
Section 5.4.1: Hold Examples #952
Bernard: issue is it stops immediately, but doesn't stop rendering immediately (?)
stefan: this works for me
bernard: next is example 4
... rewrite to use setRemoteDescription, or [something
else]
fluffy: how to stop sending packets?
Bernard: I think the right way to stop is replaceTrack with null
add example to show that
and second example to use setRemoteDesciption
fluffy: rtcp and ice consent still happen
taylor: replaceTrack null is better
Bernard: next is example 5
... add some context
... example 6 is response to example 5 (off of hold)
... instead of replaceTrack null, bring back a sending track,
like a mic track
stefan: looks good
STUN/TURN OAuth token auth parameter passing #714
Support for OAuth in TURN credentials (Issue 714 patch) #776
stefan: think we need justin and ekr before we can decide
fluffy: leans toward 2 and 3
<vivien> [We are discussing the 3 proposed options listed at https://github.com/w3c/webrtc-pc/issues/714#issuecomment-260009020 ]
stefan: discuss later and on
list
... and in issue 714
misi: next slide
stefan: Please review issue 714/PR 776 - STUN/TURN OAuth Token (cont’d)
<scribe> ACTION: stefanh to email specific people to review 714/PR 776 - STUN/TURN OAuth Token (cont’d) [recorded in http://www.w3.org/2016/12/12-webrtc-minutes.html#action04]
<trackbot> Created ACTION-122 - Email specific people to review 714/pr 776 - stun/turn oauth token (cont’d) [on Stefan Håkansson - due 2016-12-19].
taylor: next slide
jib: maybe "" instead of null
fluffy: like the idea. "" better
<scribe> ACTION: taylor-b to update PR to add "" [recorded in http://www.w3.org/2016/12/12-webrtc-minutes.html#action05]
<trackbot> Error finding 'taylor-b'. You can review and register nicknames at <http://www.w3.org/2011/04/webrtc/track/users>.
everyone agrees
Specify an AllowUnverifiedMedia RTCConfiguration property #849
<vivien> (now on slide 31)
fluffy: propose a system where we
can deal with media before we have its fingerprint. marked as
unverified. torn down if not a match later
... the signaling latency causes clipping on these hellos
otherwise
... allow a receiver track to be hooked up before fingerprint
arrives
--- an optional thing, some way to do this
pthatcher: security issues with
this, make it time bound. knowing that there isn't a long term
mim
... late in the game. don't want to spend time around sec
issues that could delay spec
fluffy: no problem with time
bound e.g. 1/2 second.
... was in spec before, got accidentally removed?
... playing out (or buffering?) media before it had a
fingerprint
... buffering requires speeding up audio
... and also has audio artifacts, at the time when echo
cancellers are training. buffer bad
... caused by delay in signaling path
... people expect being able to say hello as soon as they
connect
pthatcher: could this be solved by delaying the user perception of when call is picked up?
fluffy: this is on receiver when they click answer, they want to say hello immediately
stefanh: could PRANSWER be used?
fluffy: privacy thing you run into. yes you could use that to some degree
Bernard: could be bad in video too if you lose a key frame
fluffy: buffering works well for video. hard to implement
Bernard: it's a real problem we've encountered
stefanh: I don't see a solution. quite a bit of work
fluffy: allow transceiver to wire
up instead of error. (apps would need to explicitly wire this
up)
... simple spec change. ease up on RFC 4572 Section 6.2
... add time limit
pthatcher: trade-off: spec work, any security issues?
Bernard: video codecs are complicated. inject w/buffer overflow etc.
fluffy: still need ice credentials. Alice was willing to take media from connection
stefanh: don't we need an API for opt-in?
pthatcher: real issue is security issue
Bernard: ssl implementation may not let me do this
pthatcher: don't want to spend a
lot of time on it, and make sure it's optional. Browser doesn't
have to implement it if there's a concern.
... ok with fluffy making a PR
Bernard: write up something to give to security people to consider
Bernard: proposal to add text to explicitly say set SDP when read back may be different
stefanh: great
Remove legacy getStats API? #924
<vivien> /me notes that even if Harald is not present Varun is on the call
jib: jib I support this
bernard: me too
stefanh: lets do it
sender.setParameters(): Changing simulcast parameters? #945
pthatcher: we could not add
simulcast streams after addTransceiver
... In favor of saying you pick how many you want when you call
addTransceiver
fluffy,taylor: agree
Bernard: people won't cry as they
can ask for the max up front
... then inactivate them if you wanted less
STUN/TURN Auto Discovery handling #941
fluffy: we need to figure out how to get credentials
Misi: who needs to get
credentials? Who has the control of the TURN server? What TURN
servers to use?
... the WebRTC stack could create list of closest STUN servers,
discovery
... sent back to app which could then obtain credentials
somehow
... Harald thinks this should be a separate service/api outside
webrtc
fluffy: anycast already works
Misi: if you need different
credentials per server rather than domain.
... important to find TURN server closest to client
fluffy: if you allow JS to run this, you've revealed the location of the person by revealing closest server
stefanh: out of time
<vivien> trackbot, end meeting