IRC log of webrtc on 2015-10-28

Timestamps are in UTC.

23:56:04 [RRSAgent]

RRSAgent has joined #webrtc

23:56:04 [RRSAgent]

logging to http://www.w3.org/2015/10/28-webrtc-irc

23:56:12 [vivien]

RRSAgent, make logs public

23:56:26 [vivien]

Meeting: WebRTC TPAC 2015 F2F

23:56:49 [vivien]

Agenda: https://www.w3.org/2011/04/webrtc/wiki/October_29_-_30_2015#Thursday_October_29

23:57:01 [vivien]

Chair: Harald & Stefan

23:58:02 [vivien]

Present+ Maire_Reavy, Randel_Jesup

00:01:00 [Shijun]

Shijun has joined #webrtc

00:01:20 [vivien]

Information for presenters if you have slides for today (and I hope you do ;) please sned them to vivien@w3.org and I'll take of adding them to the wiki

00:02:06 [vivien]

on webex we have: Maire & Randel

00:02:14 [vr000m]

vr000m has joined #webrtc

00:02:14 [dom]

Present+ Kevin_Fleming, Adam_Alfar, Shijun, PeterT, MartinT, AdamR, Varun, Cullen, Matthieu, Alex, AndrewH, Vivien, DanB, StefanH, Harald, Dom

00:02:22 [juberti]

juberti has joined #webrtc

00:02:33 [mt_____]

mt_____ has joined #webrtc

00:02:40 [adamR]

adamR has joined #webrtc

00:02:46 [juberti]

Is there a dial-in for this meeting?

00:02:58 [mt_____]

it's on the agenda page

00:03:04 [mt_____]

just added apparently

00:03:19 [burn]

burn has joined #webrtc

00:03:22 [dom]

dom has changed the topic to: https://www.w3.org/2011/04/webrtc/wiki/October_29_-_30_2015

00:03:27 [dom]

Agenda: https://www.w3.org/2011/04/webrtc/wiki/October_29_-_30_2015

00:03:29 [mt_____]

s/Is there a dial-in for this meeting?//

00:03:37 [mt_____]

s/it's on the agenda page//

00:03:38 [jesup]

jesup has joined #webrtc

00:03:45 [mt_____]

s/just added apparently//

00:04:00 [vivien]

Topic: Agenda review for Thursday

00:04:05 [mathieucitrix]

stefan: Going throigh agenda

00:04:08 [vivien]

scribe: mathieucitrix

00:04:30 [vivien]

s/throigh/through/

00:05:38 [mathieucitrix]

... is everybody ok swapping simulcast and webrtc privacy afternoon sessions?

00:05:49 [toddg]

toddg has joined #webrtc

00:05:50 [vivien]

Present+: Justin_Uberti

00:05:52 [vivien]

Present+ Justin_Uberti

00:06:04 [masato]

masato has joined #webrtc

00:06:50 [mreavy]

mreavy has joined #webrtc

00:08:25 [mathieucitrix]

harald: adding agenda bashing tomorrow morning for friday

00:08:45 [gmandyam]

Present+ gmandyam

00:08:58 [mathieucitrix]

stefan: moving on to added functionality

00:09:26 [juberti]

so: agenda is: transceiver and other 1.0 stuff this morning; simulcast in afternoon; IP privacy tomorrow morning?

00:09:49 [wydong_CM]

wydong_CM has joined #webrtc

00:10:31 [vivien]

Topic: Added functionality in WebRTC-1.0 after interim meeting

00:10:49 [mathieucitrix]

stefan going through list of what was agreed since seattle

00:10:56 [igarashi_]

igarashi_ has joined #webrtc

00:11:26 [toddg]

toddg has left #webrtc

00:11:28 [mathieucitrix]

martin: didn't have time to finish PR for pre-negotiation

00:11:39 [toddg]

toddg has joined #webrtc

00:12:27 [mathieucitrix]

stefan: almost all done for items since seattle. separate discussion for simulcast

00:12:51 [mathieucitrix]

... peter can go for slides on transciever

00:14:48 [dom]

-> https://www.w3.org/2011/04/webrtc/wiki/File:RtpTransceivers_at_TPAC_2015.pdf PeterT's slides on Transceiver

00:15:04 [mathieucitrix]

peter: Things that we added: 1:1 mapping between mline and transceiver

00:15:43 [mathieucitrix]

... method for creating transceiver

00:16:35 [mathieucitrix]

martin: why do we have get transciver as getter

00:17:53 [mathieucitrix]

... should mid be on transceiver ?

00:18:18 [mathieucitrix]

peter: for linking back to sender

00:18:35 [mathieucitrix]

martin: there is no attribute ?

00:18:39 [mathieucitrix]

peter: no

00:19:38 [fluffy]

So martin said we need to mark the sender and receiver objects as “saome object” in webild

00:19:43 [fluffy]

seemed to agrement on that

00:20:20 [hta]

hta has joined #webrtc

00:20:20 [juberti]

going afk for a bit; back in ~1hr

00:21:20 [vivien]

Present+ Taylor_Brandstetter

00:21:53 [mathieucitrix]

fluffy: is removing offerToReceive not a problem for breaking what's out there already ?

00:22:22 [mathieucitrix]

martin: remove from spec but keep in implem and deprecate

00:22:45 [mathieucitrix]

adam: we're prefixed anyway so not a problem:

00:23:01 [mathieucitrix]

martin: FF 44 has webrtc unprefixed

00:23:22 [mathieucitrix]

... will have both prefix and unprefix because of broken polyfills

00:23:55 [masato]

masato has joined #webrtc

00:24:00 [mathieucitrix]

peter: leave to browser to handle as implem decision but remove from spec

00:24:38 [mathieucitrix]

fluffy: document in backwards compatibility section ?

00:24:53 [mathieucitrix]

martin: ok either way

00:25:43 [mathieucitrix]

harald: consensus is removing

00:26:14 [mathieucitrix]

peter: removeTrack deactivates instead of removing sender

00:27:24 [mathieucitrix]

... simplified version of examples

00:28:13 [kpfleming]

kpfleming has joined #webrtc

00:29:18 [mreavy]

can someone update the wiki page with the agenda changes? ( http://www.w3.org/2011/04/webrtc/wiki/October_29_-_30_2015 )

00:29:45 [adamR]

hta: ^^^

00:29:51 [jib]

jib has joined #webrtc

00:30:34 [mathieucitrix]

fluffy: media before signalling: if I ever got the video before answer is applied, it would render to video tag in this case ?

00:30:57 [mathieucitrix]

harald: if things are wired that packets manage to come in, then yes

00:32:11 [jesup]

it's very hard to hear many of the people due to the mic-ing.... some aren't hearable due to distance, mic, or voice frequency (hta ;-)

00:32:54 [hta]

I'm sorry - my voice is gone, so I'm more handicapped than usual by the fact that the mike stopped moving.

00:33:12 [mathieucitrix]

peter: if iframe comes in before fingerprint, we can rprocess it but not render it

00:33:18 [vivien]

Present+ Jan-Ivar_Bruaroey

00:34:14 [mathieucitrix]

dom: that example in not in any PR

00:34:23 [mathieucitrix]

peter: will fix that

00:34:36 [mathieucitrix]

... next, remaining questions

00:34:59 [mathieucitrix]

... when does addtrack reuse sender

00:35:05 [mishizaw]

mishizaw has joined #webrtc

00:36:02 [mathieucitrix]

... option a: reuse sender if inactive

00:37:00 [mathieucitrix]

fluffy: can we drop whole problem of replace track onto JSEP ?

00:37:21 [mathieucitrix]

peter: JSEP doesn't fully solve it yet ?

00:38:19 [mathieucitrix]

peter: option C, recommended, reuse sender if never been active

00:38:30 [mathieucitrix]

fluffy: that's what jsep does

00:38:52 [mathieucitrix]

... worried this is defined in 2 places

00:39:18 [mathieucitrix]

peter: already refers to jsep

00:39:37 [dozawa]

dozawa has joined #webrtc

00:39:54 [mathieucitrix]

fluffy: this sounds like agreement on solution, we need to figure out how to put it correcty in spec

00:40:40 [mathieucitrix]

dan: shouldn't use word "resuse", since it's really use if never been used

00:41:29 [mathieucitrix]

harald: concensus on C. need to figure out which document writes it

00:42:09 [mathieucitrix]

adam: theres a discrpeency with jsep.

00:42:59 [dom]

s/discrpeency/discrepancy/

00:43:00 [mathieucitrix]

martin: jsep says you can revive if both sides know it's gone, port 0

00:43:08 [mathieucitrix]

... we're missing that here

00:43:24 [mathieucitrix]

... not using what justin carefully crafted

00:43:56 [mathieucitrix]

peter: justin said use case was too complicated and so didn't have to handle it

00:44:00 [wonsuk]

wonsuk has joined #webrtc

00:44:50 [mathieucitrix]

harald: receiver is gonna see the wrong thing on other end. so only solution is to signal.

00:45:55 [mathieucitrix]

martin: I think what happen is that new transciever sender and receiver might reuse mid

00:46:33 [mathieucitrix]

fluffy: at any given point one to one relationship between mline and transceiver

00:47:01 [mathieucitrix]

... but if mline is gone and transceiver gone, then new one might end up on same mline

00:48:04 [mathieucitrix]

martin: there is a concern. all good on sender side, but receiver might not know. solution is to change mid

00:48:23 [mathieucitrix]

fluffy: need justin and ekr and whiteboard this

00:48:58 [mathieucitrix]

martin: can try to solve it tomorrow. ekr will be here.

00:49:13 [mathieucitrix]

fluffy: record strawman so justin can catch up

00:49:13 [mishizaw]

mishizaw has joined #webrtc

00:51:53 [adamR]

The general shape of the solution is: (1) We will recycle m= sections, as described in draft-ietf-rtc-jsep; (2) We will use *new* transceivers whenever an m= line is recycled; and (3) we *probably*, subject to further analysis, need to change MID on a recyled m= section

00:52:20 [mathieucitrix]

peter: question 2

00:53:10 [mathieucitrix]

... how to activate transceiver without calling addTrack

00:53:31 [mathieucitrix]

... option a: setActive

00:55:08 [mathieucitrix]

harald: should we make all senders active by default ?

00:55:51 [mathieucitrix]

peter: would need to change addTrack logic to behave like replaceTrack ?

00:56:20 [mathieucitrix]

harald: it's in case of never been used, so shouldn't need to change anything

00:57:49 [mathieucitrix]

peter: idea is sender are automatically activate, and redefine addTrack as if active sender that never had track, use replaceTrack logic ?

00:58:05 [mathieucitrix]

... this might work

00:59:15 [mathieucitrix]

fluffy: deafult in SDP is send receive. still need a way to "deactivate"

01:00:18 [mathieucitrix]

peter: option b: put activate sender on transceiver

01:00:21 [mathieucitrix]

... sound like one off

01:00:59 [mathieucitrix]

fluffy: setDirection on transceiver might make more sense. and reflects what's going on in SDP. wouldn't feel weird

01:02:34 [mathieucitrix]

... active is not a good name

01:03:02 [wonsuk]

wonsuk has joined #webrtc

01:03:06 [tomoyuki_]

tomoyuki_ has joined #webrtc

01:03:19 [kinjim]

kinjim has joined #webrtc

01:03:20 [mathieucitrix]

peter: so everybody happy with transceiver ."setHorrible" ?

01:03:55 [mathieucitrix]

harald: setRemoteDescrition might change thos bits

01:04:30 [mathieucitrix]

... transceiver need to go muck with sender and receiver

01:05:33 [mathieucitrix]

peter: is all this worth it compared to say, if you do warm up, you'll have to do re-offer

01:06:06 [mathieucitrix]

fluffy: you might just be able to do offer, provisional answer, answer

01:06:28 [mathieucitrix]

peter: if that's true we dont need setHorrible ?

01:07:36 [mathieucitrix]

peter: scenario already fine in non-warm up

01:07:37 [vivien]

present+ Erik_Lagerway, Bernard_Aboba, Robin_Raymond

01:07:47 [mathieucitrix]

fluffy: are we trying to solve a non-problem

01:08:03 [wonsuk]

wonsuk has joined #webrtc

01:08:53 [mathieucitrix]

... this example is not enough to see where the issue is

01:10:19 [mathieucitrix]

fluffy: nice option with this is we dont need pranswer

01:10:37 [mathieucitrix]

... but it's still 2 signalling messages

01:10:55 [mathieucitrix]

peter: 2 q: is ugly bit worth it? what is exactyly the ugly bit

01:11:17 [mathieucitrix]

martin & fluffy: yes needed, peter to decide what api looks like

01:11:47 [vivien]

(that was option B)

01:11:49 [mathieucitrix]

peter: question 3, harder question, rollback

01:12:29 [mathieucitrix]

... option a, never remove transceiver

01:13:06 [mathieucitrix]

fluffy: if it's there, is it functional, how do you know ?

01:13:22 [mathieucitrix]

martin: how do you diff between good & bad

01:13:27 [mathieucitrix]

peter: not good option

01:13:37 [mathieucitrix]

... option b: always remove

01:14:28 [mathieucitrix]

martin: crux of problem: are you rolling back remote offer, or everything done since left stable ?

01:15:30 [mathieucitrix]

martin: what if stable, call addTrack, then setRemote. track might be added to existing transceiver . what do you do on roolback ?

01:15:46 [mathieucitrix]

fluffy: you go back to stable

01:17:08 [mathieucitrix]

martin: this doesn't work, describing issue if some tracks were added, others not

01:17:24 [mathieucitrix]

... should roll back offer, not add tracks

01:17:34 [mathieucitrix]

.. let tracks sit there

01:17:51 [mathieucitrix]

fluffy: ok, that;s about negotiated offer

01:17:58 [mathieucitrix]

peter: option b no god

01:18:08 [mathieucitrix]

s/god/good/

01:18:37 [mathieucitrix]

peter: option c, ... out not possible

01:18:58 [mathieucitrix]

peter: option D,

01:20:08 [mathieucitrix]

martin raising an issue

01:20:23 [mathieucitrix]

peter: option E is meh

01:20:30 [mathieucitrix]

peter: option E

01:20:43 [mathieucitrix]

s/option E is meh/option D is meh/

01:21:50 [mathieucitrix]

fluffy: this is weird but might be less weird, more fitting mline

01:21:51 [vivien]

s/that;s

01:22:02 [mathieucitrix]

martin: this might be combined with others

01:22:08 [vivien]

s/that;s/that's/g

01:22:12 [mathieucitrix]

peter: E is potential, option F

01:23:12 [mathieucitrix]

... has potential too

01:23:34 [kinjim]

kinjim has joined #webrtc

01:23:53 [mathieucitrix]

martin: option F is very close to current FF implementation of rollback, so it's kinda right, but need better model

01:23:58 [mathieucitrix]

peter: option G

01:24:41 [mathieucitrix]

martin: sounds like option D with extra thing

01:24:59 [mathieucitrix]

... so better than D

01:25:19 [mathieucitrix]

fluffy: it's consistent with everything else we've done

01:25:21 [mishizaw]

mishizaw has joined #webrtc

01:25:39 [mathieucitrix]

peter: option H

01:26:35 [mathieucitrix]

harald: there's one case where you need to rollback remote offer: glare

01:27:03 [mathieucitrix]

peter: but you roll back local offer, not remote

01:28:35 [mathieucitrix]

martin: existing session, receive remote offer, apply it, some tracks appear, don't like all the new stuff, and want to rollback to stop receiving all that

01:29:20 [mathieucitrix]

peter: all sounds like weird edge cases

01:29:40 [mathieucitrix]

fluffy: need to do something to get back to stable state though

01:31:01 [mathieucitrix]

martin & adam: H looks better and better

01:31:41 [mathieucitrix]

harald: on rollback, transceiver that haven't been used, go in mid bucket

01:32:21 [mathieucitrix]

peter: G might not actually solve problem

01:33:24 [mathieucitrix]

... down to E, F, H

01:35:16 [mathieucitrix]

martin: G by itself is not enough but might give you a good base

01:35:55 [mathieucitrix]

peter wants to revive part of B

01:37:35 [mathieucitrix]

peter: go with G, call addtrack, add to pending, rollback, pending ones stay around ?

01:38:24 [mathieucitrix]

harald: need way to find pending and kill them

01:40:27 [juberti]

back

01:41:19 [mt_____]

addTrack creates a pending transceiver

01:41:27 [mt_____]

setRemote(offer) creates a pending transceiver

01:41:47 [mathieucitrix]

summary, martin & peter to work on G + F

01:41:51 [mt_____]

addTrack adds a sender to the transceiver; setRemote(offer) adds a receiver to the transceiver

01:42:28 [mt_____]

on rollback, transceivers are removed from the pending unless they have an active sender

01:42:48 [juberti]

H is needed as long as we want to be able to reject offers.

01:43:23 [mt_____]

(this has the consequence of activateSender() being persisted

01:43:42 [mt_____]

juberti: is that back to front? H is to now permit rejecting of offers

01:44:22 [mt_____]

sorry, H is to not permit rejecting offers

01:44:43 [juberti]

H is to not permit rollback; I was making the point that that implies no rejection, which seems drastic.

01:45:22 [juberti]

are we taking a break, or moving to the next preso?

01:45:31 [mreavy]

hta: can you (or someone) update the wiki page with the agenda changes? ( http://www.w3.org/2011/04/webrtc/wiki/October_29_-_30_2015 )

01:46:17 [mishizaw]

mishizaw has joined #webrtc

01:56:51 [Lags]

Lags has joined #webrtc

01:58:23 [mishizaw]

mishizaw has joined #webrtc

02:06:22 [mishizaw]

mishizaw has joined #webrtc

02:07:46 [mathieucitrix]

everybody is coming back to the room, about to resume

02:08:05 [mathieucitrix]

stefan: next up, codec selection

02:09:22 [mathieucitrix]

martin: application might want to exert control over what browser negotiates

02:09:55 [kinjim]

kinjim has joined #webrtc

02:10:41 [mathieucitrix]

... I sent email to mmusic, will simulcast allow you negotiate things in one direction but not other

02:10:56 [mathieucitrix]

adam: were reluctant to spec that out so far.

02:11:16 [mathieucitrix]

martin: simulcast is asymetric

02:11:22 [juberti]

let's just keep it simple and be asymmetric

02:11:30 [mathieucitrix]

adam: don't want to make mandatory for webrtc

02:11:34 [juberti]

er, symmetric

02:11:52 [mathieucitrix]

martin: let get to the question first

02:12:18 [mathieucitrix]

on slide 4

02:13:24 [mathieucitrix]

fluffy: weird that you get list from one object and set on another

02:13:34 [mathieucitrix]

martin: that's why there's other slide

02:15:11 [mathieucitrix]

aaa: appliation is basically ordering list, what if codec is not ...

02:15:30 [mathieucitrix]

marting: something about hardware codec

02:16:01 [mathieucitrix]

fluffy: I have proposal to be in line with SDP

02:16:19 [mathieucitrix]

... person that generates answer need to accept preference order of offer

02:16:38 [mathieucitrix]

... order set here controls what is in offer

02:17:08 [mathieucitrix]

martin: question is on answer, what do you follow, spd, local setting, browser implem

02:17:28 [mathieucitrix]

fluffy: need to be deterministic

02:18:22 [mathieucitrix]

martin: should affect sdp

02:18:34 [mathieucitrix]

... we working on this so we don;t have to munch sdp

02:19:45 [mathieucitrix]

adam: sdp is pretty thorough. order is meaningful. but both sides don't have to have same order

02:21:32 [mathieucitrix]

martin: reduce number of codec easy. ordering. set order of things in sdp, and when you receive sdp, you're supposed to follow sdp rules

02:21:45 [mathieucitrix]

... next, alternative (slide 5)

02:22:55 [mathieucitrix]

peter: 2 things set availble and set order

02:24:00 [mathieucitrix]

martin: this is closer to getCapabilities and Prederence on sender and receiver but issue

02:25:40 [mathieucitrix]

martin: first option seem better way to do it

02:25:56 [mathieucitrix]

fluffy: with adaptations from adam

02:26:20 [mathieucitrix]

martin: PR might already have been merged?

02:27:08 [mathieucitrix]

peter: already have non active flag when no track on transceiver

02:27:56 [mathieucitrix]

martin: conclusion option 1, with adam interpretation of SDP.

02:28:16 [mathieucitrix]

martin: affect both offer and answer

02:30:00 [mathieucitrix]

fluffy: have to define on re-offer what you do with order. should maintain.

02:30:13 [mathieucitrix]

all agreed

02:30:21 [burn]

martin has asked me to type into IRC that it is important to capture key discussion points in the minutes in addition to the final decisions

02:30:28 [DrAlex]

DrAlex has joined #Webrtc

02:30:37 [fluffy]

When we do a reoffer, we maintain the previoulsy negotated ordering

02:33:10 [mathieucitrix]

stefan: end of morning sessions, can we sneak in soenthing before lunch break

02:33:37 [mt_____]

conclusion is that the codec ordering determines what is put in SDP

02:34:09 [juberti]

Did we discuss what happens if telephone-event, CN, red, FEC, rtx appear in codec preferences?

02:34:11 [mt_____]

SDP determines what - absent overriding preferences - a sender uses

02:34:22 [vivien]

Topic: Stats

02:34:29 [RRSAgent]

I have made the request to generate http://www.w3.org/2015/10/28-webrtc-minutes.html vivien

02:34:30 [mt_____]

juberti - I mentioned those as being overriding preferences

02:34:30 [mathieucitrix]

doing stats (originally Friday afternoon)

02:34:41 [juberti]

?

02:35:05 [mt_____]

as in if they are ordered above more useful things, then they won't get chosen just because they come first

02:35:28 [mt_____]

I guess we could decide that these generate errors, or ordering of them are ignored

02:35:41 [adamR]

juberti: This is normal SDP processing — if a codec can’t encode the input media, you skip it and move on to the next thing.

02:35:43 [mt_____]

I don't think that's particularly important to address now, we can nut that out in the PR discussion

02:36:25 [vr000m]

vr000m has joined #webrtc

02:36:30 [vr000m]

https://docs.google.com/presentation/d/12VCXshmaiM1W_cbJiMrhVZVNuzTaCDpJOjkJsHKEkng/edit?usp=sharing

02:36:33 [juberti]

well, I was wondering if we would always stuff these at the end regardless of setCodecPreferences. Agree this is small beer

02:37:19 [mathieucitrix]

varun: 2 updates since TPAC 2014

02:37:26 [mt_____]

I'm happy to just echo whatever crap the application feeds us, but equally happy to require they be pushed to the back

02:37:35 [mathieucitrix]

varun: open issue #5

02:39:07 [mathieucitrix]

... question is to knwo where to define RTCStats, in webrtc-pc or webrtc-stats

02:40:01 [mathieucitrix]

fluffy: stats document cpuld be considered as first official extension

02:40:11 [mathieucitrix]

... base doc has base object definition

02:40:45 [mathieucitrix]

harald: might need to repeat definition of object

02:40:50 [mathieucitrix]

... for convenience

02:41:10 [geheimnis`]

geheimnis` has joined #webrtc

02:41:44 [mathieucitrix]

varun: stats document would stay open longer

02:42:05 [mathieucitrix]

fluffy: can't implement living standards. need to have one doc with mti, and then open another one

02:42:38 [mathieucitrix]

... some stats normative in webrtc spec, then add more in extensions doc for stats.

02:43:11 [juberti]

for setCodecPreferences, we just need to ensure that ordering is maintained across reoffers, regardless of browser preferences. That prevents oscillation.

02:43:59 [mathieucitrix]

harald: action item for dom to share link to document on naming

02:44:07 [mathieucitrix]

... for hyphen

02:44:20 [mathieucitrix]

varun: issue #7

02:44:32 [mathieucitrix]

... PR not merged

02:45:02 [dom]

"Enumeration values: Lowercase, dash-delimited " in http://w3ctag.github.io/design-principles/#casing-rules

02:45:53 [mathieucitrix]

... if non controversial, go ahead and merge

02:46:03 [mathieucitrix]

varun: issue #11

02:46:44 [juberti]

RTCIceCandidateAttributeInfoStats... sounds like Java

02:46:56 [mathieucitrix]

... should we add "info" to all too ?

02:47:11 [mathieucitrix]

martin: can't we just have "Stats"

02:48:47 [mathieucitrix]

mathieucitrix: don't we have some of the "static" stuff on other objects?

02:48:55 [mathieucitrix]

peter: we have both now

02:49:25 [mathieucitrix]

justin: odd we have 2 dict that have same info

02:49:38 [mathieucitrix]

martin: should all be interfaces

02:50:05 [mathieucitrix]

justin: peter can't we go use the ice objects directly and do away with stats

02:50:13 [fluffy]

http://www.w3.org/TR/2014/WD-webrtc-stats-20141021/#icecandidate-dict*

02:50:37 [mathieucitrix]

bbb: can't we share same object

02:50:42 [mathieucitrix]

harald: no

02:51:29 [mathieucitrix]

martin: or have Stats interface implement RTCCandidate

02:52:03 [mathieucitrix]

... not possible with dict but might be possible with interface here ?

02:52:47 [mathieucitrix]

justin: need to at least make them look the same

02:53:07 [mathieucitrix]

martin: if they're copy of each other, ok

02:53:27 [mathieucitrix]

peter: stats has one more field with associated turn / stun url

02:54:00 [mathieucitrix]

justin: stats object is also missing a field

02:54:47 [mathieucitrix]

martin: have stats have everything, or both have everything

02:54:58 [mathieucitrix]

peter: or embed?

02:55:08 [mathieucitrix]

harald: filed issue #31

02:55:48 [mathieucitrix]

martin: peter has suggestion: put address in stats, and embed RTCCandidate

02:56:19 [mathieucitrix]

harald: something about serializer

02:57:42 [mathieucitrix]

justin: remove RTCIceCandidateAttributes, and embed RTCIceCandidate in the PairStats

02:57:54 [mathieucitrix]

harald: lots of duplication

02:58:18 [mathieucitrix]

bbb: we want to avoid duplicating all that info

02:58:36 [hta]

bbb=Jan-Ivar

02:59:01 [kpfleming]

s/bbb/Jan-Ivar

02:59:51 [jesup]

Good by me

03:00:07 [mathieucitrix]

fluffy: lets get rid of Attributes and Info, everybody agree, done

03:00:15 [juberti]

RTCIceCandidateStats and RTCIceCandidate. Sold.

03:00:20 [mathieucitrix]

varun: issue #13

03:00:52 [mathieucitrix]

fluffy: should reference IETF spec

03:01:12 [mathieucitrix]

harald: draft expired 2012

03:01:33 [mathieucitrix]

fluffy: tell to resubmit, w3c shouldn't define this stuff

03:01:52 [juberti]

Did we discuss #12?

03:02:06 [mathieucitrix]

varun: conclusion: tell magnus to put definition in active draft

03:02:16 [juberti]

RTCIceCandidateStats.addressSourceUrl is different than RTCIceCandidateEvent.url

03:03:00 [mathieucitrix]

harald: action for adam to ping magnus

03:03:12 [mathieucitrix]

varun: issue #16

03:04:33 [mathieucitrix]

martin: opposed, raise risk of app parsing and changing behavior based on content like user agent.

03:05:20 [mathieucitrix]

harald: should have standard way to parse info. but only if can make it useful for stats

03:10:48 [mathieucitrix]

martin: massive fingerprinting surface

03:11:21 [mathieucitrix]

mathieucitrix: can we get info of whether hardware of software decoder is used in stats

03:11:45 [mathieucitrix]

adam: does not belong in stats

03:12:18 [mathieucitrix]

fluffy: ok with one bit of info, but not in stats

03:12:32 [mathieucitrix]

varun: issue #

03:12:57 [mathieucitrix]

all: undefined

03:13:21 [mathieucitrix]

justin: did we discuss #12

03:13:28 [mathieucitrix]

varun: has already been fixed

03:13:42 [mathieucitrix]

justin: it's inconstitent

03:13:51 [mathieucitrix]

harald: noted that in issue #31

03:14:18 [juberti]

((#issue 21)

03:14:47 [mathieucitrix]

s/#31/#21

03:15:19 [mathieucitrix]

fluffy: we need some stats being defined as MTI in webrtc-pc

03:16:13 [mathieucitrix]

varun: add new metrics. packetsDiscarded/Repaired

03:16:34 [mathieucitrix]

fluffy: useful, should be defined, maybe not MTI

03:16:48 [mathieucitrix]

justin: what does repair mean

03:16:54 [mathieucitrix]

varun: retransmit or fec

03:18:33 [mathieucitrix]

varun: process for adding new metrics ?

03:19:07 [mathieucitrix]

fluffy: should we bundle that with extensibility discusssion of media capture later this afternoon ?

03:19:34 [mathieucitrix]

... process in IETF is you can define whatever, and anyone can chose to implement or not

03:20:03 [mathieucitrix]

... so here, define, and then main doc can bring in what is deemed good

03:21:58 [mathieucitrix]

dan: difference with extensibility discussion later, is this is only data structure

03:22:55 [mathieucitrix]

fluffy: living document not ok

03:23:27 [mathieucitrix]

harald: want to avoid DOM experience with levels

03:24:16 [mathieucitrix]

fluffy: usually only adding, so new ones can go in new document

03:24:54 [mathieucitrix]

discussion to continue over lunch for those interested

03:25:45 [jxck]

jxck has joined #webrtc

03:49:33 [frodek]

frodek has joined #webrtc

04:01:47 [jxck]

jxck has joined #webrtc

04:02:50 [tomoyuki]

tomoyuki has joined #webrtc

04:04:26 [hta]

hta has joined #webrtc

04:08:42 [oonishi]

oonishi has joined #webrtc

04:14:58 [iwashi]

iwashi has joined #webrtc

04:19:50 [masato]

masato has joined #webrtc

04:25:16 [npdoty]

npdoty has joined #webrtc

04:27:29 [npdoty]

npdoty has joined #webrtc

04:28:27 [burn]

burn has joined #webrtc

04:29:03 [adamR]

adamR has joined #webrtc

04:30:20 [vr000m]

vr000m has joined #webrtc

04:30:35 [hta]

now.

04:30:38 [fluffy]

fluffy has joined #webrtc

04:31:23 [igarashi]

igarashi has joined #webrtc

04:34:49 [vr000m]

justin: slide 2

04:35:12 [vr000m]

juberti: slide 3 (concerns)

04:35:29 [jesup]

where are the slides?

04:36:14 [vr000m]

juberti: slide 4 (consideration)

04:36:25 [wonsuk]

wonsuk has joined #webrtc

04:36:51 [alan_iida]

alan_iida has joined #webrtc

04:37:19 [vivien]

-> https://www.w3.org/2011/04/webrtc/wiki/images/4/4d/WebRTC_IP_Address_Privacy_TPAC_2015.pdf WebRTC IP Address Privacy slides from Justin

04:37:36 [jystewart]

jystewart has joined #webrtc

04:37:53 [mishizaw]

mishizaw has joined #webrtc

04:38:13 [vr000m]

ekr: DHCP reliably gives you the same IP address.

04:38:36 [vr000m]

juberti: there are other things that can be done here, like UA fingerprinting

04:38:41 [kinjim]

kinjim has joined #webrtc

04:38:42 [vr000m]

ekr: agree

04:40:00 [vivien]

Topic: WebRTC privacy - IP address leakage

04:40:02 [vr000m]

juberti: slide 5 (goals)

04:40:59 [oonishi_]

oonishi_ has joined #webrtc

04:41:16 [ekr]

ekr has joined #webrtc

04:41:29 [ekr]

Citation for TCP timestamp fingerprinting

04:41:41 [vr000m]

juberti: slide 6 (restricted gathering)

04:41:53 [dom]

dom has joined #webrtc

04:42:05 [ekr]

https://www.caida.org/publications/papers/2005/fingerprinting/KohnoBroidoClaffy05-devicefingerprinting.pdf

04:42:34 [dandan]

dandan has joined #webrtc

04:42:51 [vr000m]

adamR: per address family.

04:43:09 [vr000m]

martin: 1 address per family on that interface

04:43:36 [vr000m]

juberti: you pick your default interface, and then gather one v4 and v6 address.

04:43:58 [vivien]

present+ Eric_Rescorla, Nick_Doty

04:44:00 [ekr]

See also: Virtual Pwned Networks

04:44:01 [ekr]

https://www.usenix.org/system/files/conference/foci12/foci12-final8.pdf

04:44:29 [vr000m]

juberti: if you connect to multiple well known addresses, this may pick different interfaces

04:45:03 [vr000m]

juberti: slide 7 (host candidates)?

04:45:54 [kpfleming]

kpfleming has joined #webrtc

04:46:04 [npdoty]

without any user involvement?

04:46:13 [vr000m]

juberti: allow host to host connections. because in some cases they expect it to work.

04:47:01 [vr000m]

juberti: slide 8 (restricted gathering)

04:47:46 [vr000m]

fluffy: VPN in enterprise case?

04:48:22 [vr000m]

juberti: if you bind to 0.0.0.0 address, it maps to tun0 interface instead of en0 or en1.

04:48:31 [npdoty]

did that broken ICE host-to-host example include camera/microphone user-granted permission? or was it just displaying a video, no user involvement, in the browser and so needed to support it by default?

04:48:52 [vr000m]

fluffy: in the enterprise case it wont be a private address but an enterprise IP address.

04:48:59 [dom]

juberti was referring to data channel usage (so no camera permission grant involved)

04:49:38 [vr000m]

juberti: will the VPN provide the IP address in the same space as the enterprise address?

04:49:56 [vr000m]

ekr: looking at the routing tables in the VPN paper.

04:50:14 [wdh_]

wdh_ has joined #webrtc

04:50:33 [vr000m]

fluffy: what if a company had 8.8.* address, the VPN from that company might allocate in the same space.

04:50:36 [npdoty]

it seems like there are cases where an enterprise administrator wants local rtc to work (because they installed some video appliance) and cases where an enterprise administrator doesn't need that and would prefer a little more topology/privacy protection for their users

04:51:09 [vr000m]

juberti: 8.8.1.2 maybe assigned by DHCP and 8.8.2.1 maybe assigned by the VPN

04:51:41 [DrAlexG]

DrAlexG has joined #webrtc

04:52:07 [vr000m]

fluffy: the address in the case of home is your home IP address and the VPN would be the enterprise address and not neccessarily RFC1918 address

04:52:40 [vr000m]

adamR: both are possible: i.e., 1918 address and also enterprise addresses.

04:52:47 [vr000m]

adamR: does it matter?

04:52:55 [vr000m]

juberti: it shouldnt matter.

04:53:56 [vr000m]

juberti: do not bother about enterprise VPN case but the privacy preserving case where the endpoint always gets a non-routable address.

04:54:11 [vr000m]

juberti: slide 9 (Consent)

04:55:09 [vr000m]

ekr: if you are behind the same NAT in the VPN, then you wont be able to talk to them.

04:55:23 [vr000m]

juberti: yes, not without a TURN server

04:55:45 [vr000m]

fluffy: but wont this affect the enterprise case as well?

04:56:04 [vr000m]

juberti: it might hairpin if they have a routable address

04:56:32 [vr000m]

adamR: what are we gaining or losing by cutting out all the local ip addresses.

04:57:00 [vr000m]

ekr: need cross pairing or need to be more aggressive.

04:57:44 [vr000m]

adamR: if this happens frequently enough. the app developers will ask for the mic just so that they get more permissive

04:58:37 [vr000m]

juberti: for those cases, we are down to the 10% of the 10% of ... so we need to measure this.

04:59:27 [vr000m]

adamR: you cannot assume that there is a need for TURN and this may cause a lot hairpining in cases where it should have gone through some IP address but the default was incorrect.

04:59:53 [vr000m]

fluffy: there are use-cases, like gaming where having TURN might be too high a bar to entry

05:00:32 [vr000m]

ekr: what would be the concern of not sharing all the 1918 addresses?

05:00:32 [jxck]

jxck has joined #webrtc

05:00:42 [vr000m]

juberti: this is more complex to explain

05:01:33 [vr000m]

ekr: we have 3 options: 1) do nothing 2) do what justin suggested, and measure, 3) be more aggressive, measure, and turn off.

05:01:34 [npdoty]

can users configure if they're expecting to reach something on the local network?

05:02:13 [vr000m]

fluffy: getting default addresses in some OSes is not clear

05:02:35 [vr000m]

martint: we use a well known ipaddress, for example 8.8.8.8

05:02:55 [kinjim]

kinjim has joined #webrtc

05:03:14 [vr000m]

fluffy: there is no need for it to be routable, you are just querying your routing table.

05:03:52 [vr000m]

martint: but can also use the STUN/TURN server, as they already know the client's ipaddress, which should be the same

05:04:12 [vr000m]

mathieu: what is the difference between address families?

05:04:42 [vr000m]

ekr: we bind to different v4/v6 address, and we just use the default addresses returned by that.

05:05:11 [vr000m]

martint: so the reason I mentioned, where you have two interfaces and this might not be ideal?

05:05:31 [vr000m]

ekr: that should not be a problem, because it may be revealed nonetheless

05:06:27 [vr000m]

ekr: we would like to get general consensus on which set of addresses we do need. i.e., the default addresses that we specify here should work

05:07:14 [vr000m]

fluffy: in enterprise VPN might not be the default route because it might just needed the address for content inside the enterprise

05:07:48 [vr000m]

adamR: if the assertion is that this is too hard to specify, I volunteer to explain this

05:08:11 [vr000m]

petert: this is not just specifying but explaining that to the community

05:08:32 [kpfleming]

kpfleming has joined #webrtc

05:08:45 [vr000m]

adamR: we are revealing one, more addresses should have the same properties

05:08:56 [vr000m]

juberti: but this is not true

05:09:35 [vr000m]

mathieu: the VPN tend to rotate the IP addresses, so these are not statically bound to an endpoint

05:10:27 [vr000m]

martint: we adopt the strategy outlined here, then we measure. We should also do the 1918 addresses, then we measure. we measure the difference, and verify the fingerprinting. and then decide

05:11:12 [vr000m]

fluffy: the statistical significance because the affected population is so small, it might be lost in the noise

05:11:32 [npdoty]

does this depend a lot on the configuration of the VPN and the applications in use by a particular enterprise?

05:11:33 [vr000m]

adamR: I agree that we wont know who got lost.

05:11:52 [npdoty]

why doesn't the enterprise administrator decides what matters to them?

05:11:53 [npdoty]

q+

05:12:36 [Zakim]

Zakim has joined #webrtc

05:12:43 [vr000m]

juberti: why dont we go out and measure. we should make sure that we observe or not observe the hypothesis

05:12:45 [toddg]

toddg has joined #webrtc

05:12:45 [vivien]

Zakim, q+ npdoty

05:12:45 [Zakim]

I see npdoty on the speaker queue

05:13:27 [vivien]

ack npdoty

05:13:27 [vr000m]

juberti: if someone wants to make a counter proposal, I can have a look at it.

05:14:13 [DrAlexG]

DrAlexG has joined #webrtc

05:14:16 [vr000m]

npdoty: my enterprise uses many datachannels, I tell my browsers to get all IP addresses and if not then i tell them to restrict it

05:15:10 [vr000m]

ekr: we already have a filter which does pair v4 with v4 and v6 with v6. we can do pairing of private with private

05:16:29 [vr000m]

shijun: we notice that most people will click the permission in the case and remember it.

05:17:05 [vr000m]

juberti: the application in this case can do ICE restart. We already agreed to also do TURN first. We could do ice restart after the permission is granted

05:17:32 [vr000m]

martint: this is exactly trade off we are making here.

05:18:48 [vr000m]

shijun: we can from an implementation, we can gather all the candidates, and not fire the event if there is restrictions, and when permissions are granted then you can have all of the candidates.

05:19:02 [vr000m]

jesup: what is the impact on warmup

05:19:29 [vr000m]

juberti: we start with TURN, this might make things faster in some scenarios.

05:20:06 [vr000m]

jesup: wasnt the idea of warmup that you can send data via low latency and not have to change from TURN to something better.

05:21:07 [vr000m]

juberti: actually opposite is true, because in the warmup case you want to start with quick choices, then make the transition. In the case of TURN privacy case, it would be TURN nonetheless. callee privacy use-case

05:21:20 [vr000m]

fluffy: you brought up ICE restart, what would be the concern

05:21:43 [vr000m]

juberti: there is no concern because there is a make before break, so no problem here

05:22:23 [vr000m]

baboba: TURN sets up quicker on average, our measurements show that.

05:22:52 [vr000m]

jesup: my concern is what should the consent question read?

05:23:07 [vr000m]

juberti: we have not found something yet.

05:23:27 [Bernard]

Bernard has joined #webrtc

05:23:28 [vr000m]

martint: we do not have enough space to explain this. perhaps a learn more.

05:23:57 [vr000m]

juberti: slide 10 (force proxy)

05:23:58 [vivien]

i/justin: slide2/Scribe: vr000m/

05:24:20 [npdoty]

"More info" or "Learn more" could try to explain that this is revealing information about your local network, for example, if you use a VPN or certain kinds of proxies

05:24:25 [RRSAgent]

I have made the request to generate http://www.w3.org/2015/10/28-webrtc-minutes.html vivien

05:25:30 [linemany]

linemany has joined #webrtc

05:25:30 [vivien]

i/justin: slide2/Scribe: vr000m

05:25:37 [RRSAgent]

I have made the request to generate http://www.w3.org/2015/10/28-webrtc-minutes.html vivien

05:26:54 [vr000m]

juberti: slide 11 (proposals)

05:27:13 [vr000m]

juberti: if you have consent, you expose everything.

05:27:55 [vr000m]

juberti: if you do not have consent, make sure it works, and no VPN addresses are exposed, and not anything else. Just a single host candidate for each family

05:28:21 [vivien]

i/now./Scribe: vr000m/

05:28:25 [RRSAgent]

I have made the request to generate http://www.w3.org/2015/10/28-webrtc-minutes.html vivien

05:28:46 [vr000m]

juberti: there are additional modes, for example via extensions or user/browser prefs. In this case you do not expose host candidates

05:29:01 [vr000m]

juberti: the last case, we clamp to TCP

05:29:05 [mishizaw]

mishizaw has joined #webrtc

05:29:30 [vr000m]

dom: this is not best practice but specify this as thing for everyone to do.

05:29:50 [vr000m]

juberti: what ever makes sense. specify or best practice

05:30:00 [vr000m]

adamR: we should still do the measurement

05:31:10 [vr000m]

adamR: i.e., differential gathering. use all 1918 addresses. Ted's variant of (2)

05:31:39 [vr000m]

juberti: we can measure between 1) current default and 2) new restrictions. We do not know how much energy to implement Ted's variant of (2)

05:32:06 [vr000m]

adamR: my intuition is that there would be non-trivial difference between the 3 approaches.

05:32:29 [vr000m]

juberti: we need to do measurements, and then discuss before we close this matter

05:33:04 [vr000m]

burn: when you mean consent, you mean gUM consent

05:33:35 [kinjim]

kinjim has joined #webrtc

05:33:44 [vr000m]

burn: for example I goto netflix and they ask me for permission and I give it

05:34:09 [vr000m]

burn: then I come to Japan, and it wont ask for permission

05:34:28 [npdoty]

depending on whether the browser persists permission for access to your camera and microphone

05:34:33 [vr000m]

martint: this is an issue with persistent permission

05:35:56 [vr000m]

burn: gUM permissions is for accessing the media capture but now these consents are for transport. Want to make sure this is the case

05:36:30 [vr000m]

dom: in seattle, we talked about network consent. I dont know if we are extending the consent

05:36:49 [igarashi_]

igarashi_ has joined #webrtc

05:37:32 [vr000m]

fluffy: the exact thing that drove this is the advertising pixel. But this is a problem with third party thing

05:37:42 [npdoty]

that script on the NYTimes was presumably not Google or Facebook, so it's certainly still relevant

05:38:16 [vr000m]

juberti: we just wanted to make sure the the NYTimes thing does not happen again

05:39:01 [npdoty]

when I raised this comment, I was told that embedded iframes of "calltechsupport.com" would expect permission to extend

05:39:02 [wseltzer]

wseltzer has joined #webrtc

05:39:23 [vr000m]

ekr: what are the properties we want here? should this be top level or not?

05:40:24 [vr000m]

martint: this is not the right context to reopen an old issue. this was discussed before. this is not a bad idea.

05:40:39 [vr000m]

ekr: this was proposed 4 years ago and there was push back on it

05:40:55 [vr000m]

fluffy: there was a demo in france, that showed the use case for allowing this.

05:41:24 [vr000m]

jan-ivar: you can bring up the permission dialog again for each I-frame.

05:41:31 [npdoty]

from Privacy Interest Group comment earlier: "Top-level origin/embedded origin pairs, for example, might be a useful model, as in some implementations of Geolocation."

05:41:46 [npdoty]

yes, double-keying permission

05:42:03 [vr000m]

ekr: are you suggesting that they ask the permission for each I-frame

05:42:55 [vr000m]

jan-ivar: well that is up to the implementation. Do not need to do that. perhaps one for facebook.com and one for the I-frames using facebook. We could have different permissions for those two cases

05:43:14 [vr000m]

martint: call permissions API each time

05:43:56 [ekr]

http://seclab.stanford.edu/websec/framebusting/framebust.pdf

05:44:21 [vr000m]

martint: justin wanted the top-level to have access to the permissions.

05:46:24 [vr000m]

ekr: non-safe behaviour if a random I-frame on a website accesses the camera, it would be bad to say it was the website was trying to get access

05:46:59 [vr000m]

juberti: well if you are at foo.com, it would be odd to get a permission that bar.com is asking for permission

05:47:44 [dom]

[I think the end result with that these sites will require to do camera-based avatars or something]

05:47:56 [npdoty]

if it were a separate permission, could we explain to users what they were going to reveal?

05:48:17 [vr000m]

jesup: this is going to cause data channel developers some concern, because they might want to have more IP addresses, and they will ask for media permissions. Then the users are going to be confused why the data channel apps are asking for audio/video

05:49:15 [dom]

npdoty, when I chatted with ted hardie back in Seattle, he thought that was achievable (e.g. "do you want to share your network location with foo.com?")

05:49:16 [vr000m]

juberti: we want to dissuade developers of datachannel apps to ask for media consent. There is one network interface in the restricted gathering, so that should be sufficient.

05:50:32 [vr000m]

stefanh: how do we conclude this discussion?

05:50:51 [vr000m]

martint: the concerns with all the local addresses needs to be done

05:51:13 [vr000m]

martint: we should take justin's proposal and also the permission prompt for now and see what we can do with this.

05:51:50 [vr000m]

juberti: we will learn from experience. and we hope to answer these questions in a relatively small amount of time

05:52:10 [vr000m]

dom: how do we incorporate this in the spec.

05:52:56 [vr000m]

juberti: we wrote up an I-D, is available. it can be copied into jsep or here in this draft.

05:53:28 [juberti]

(copied into the w3c spec, jsep, or security doc)

05:53:40 [npdoty]

dom, not that it's impossible, but that everyone is likely to be confused by it, and answer in a way that isn't necessarily tied to what they want or what is good for them

05:53:44 [vr000m]

fluffy: as rtcweb chair, does it make sense that we split this into the security considersations draft, jsep and reference these in the w3c spec.

05:55:05 [wonsuk]

wonsuk has joined #webrtc

05:55:16 [DrAlexG]

change scribe

05:55:19 [vr000m]

fluffy: socialize this next week at the IETF with the relavant parties

05:55:24 [dom]

ScribeNick: DrAlexG

05:55:25 [vivien]

Topic: Simulcast control

05:55:35 [DrAlexG]

simulcast fever starts now.

05:55:36 [DrAlexG]

plan X

05:55:46 [DrAlexG]

peter: plan X example

05:56:17 [vivien]

-> https://www.w3.org/2011/04/webrtc/wiki/images/e/e3/Simulcast_at_TPAC_2015.pdf Simulcast control slides

05:56:45 [DrAlexG]

peter: here is how you set up a transceiver, with the mapping between the RID (see MMUSIC multicast SDP) and the corresponding resolution scales ...

05:57:35 [DrAlexG]

peter: once this is done, ou create your offer, the entire JSEP dance, and if you look at your parameters after, you should see the result

05:57:49 [DrAlexG]

shing: what happen if it gets rejected ?

05:57:57 [DrAlexG]

peter: then you don t see it

05:58:11 [DrAlexG]

fluffy: question to remember later

05:58:24 [DrAlexG]

peter: if all goes well in the IETF, this is what the SDP looks like

05:58:50 [DrAlexG]

mathieu: so the scales are not in the sip?

05:58:52 [toddg]

toddg has left #webrtc

05:58:55 [toddg]

toddg has joined #webrtc

05:58:58 [DrAlexG]

peter: correct, there is nothing like that in the sdp

05:59:08 [DrAlexG]

martin: question for later

05:59:27 [DrAlexG]

peter: there is a risk that IETF will not deliver in time, in that case, we need a contingency plan.

05:59:35 [DrAlexG]

<looking for updated slides>

05:59:35 [frodek]

frodek has joined #webrtc

06:00:08 [DrAlexG]

<discussion on how to get the right slides on screen.>

06:00:26 [DrAlexG]

<adam and eke going back to exactly why we should shave our legs again>

06:00:38 [mishizaw]

mishizaw has joined #webrtc

06:00:44 [DrAlexG]

<different people speaking separately, waiting for the slides>

06:00:48 [DrAlexG]

<slides back on>

06:01:55 [DrAlexG]

peter: reading the sentence about problems that can arise when you send multiple stream the remote party is not ready for.

06:02:02 [kpfleming]

kpfleming has joined #webrtc

06:02:29 [DrAlexG]

peter: the idea is to SIGNAL the information (without SDP because IETF would not have deliver in time)

06:03:03 [DrAlexG]

fluffy: intend might be misinterpreted by IETF

06:03:19 [DrAlexG]

adam: no, we want to have a safety net if we have nothing.

06:03:40 [DrAlexG]

adma: moreover: since you would have everything define on wire, and only the signaling is the problem, you can always polyfill

06:03:52 [DrAlexG]

fluffy: don t you have a problem at the RTP header level

06:04:06 [DrAlexG]

adam: no, we can have that nailed down. this is a pure signaling problem

06:04:08 [DrAlexG]

fluffy, ok then

06:04:11 [DrAlexG]

peter: next slide

06:04:40 [DrAlexG]

peter: either way, there will be *an* api to send multiple things using the RID header extension

06:04:51 [DrAlexG]

peter: there will NOT be an API for PT based simulcast

06:05:11 [DrAlexG]

peter: there will NOT be any API mapping for max-width, and some other attribute

06:05:44 [DrAlexG]

peter: browser may support more advanced form of simulcast, but only the RID part, with header extension will be mandatory

06:06:24 [DrAlexG]

fluffy: i have a use case, very simple, where people use different devices, like mobile, with different form factors, and limiting ourselves to scales of 2 is problematic to say the least.

06:06:29 [DrAlexG]

ekr: fair

06:06:38 [DrAlexG]

peter: two things: size and aspect ratio

06:06:55 [DrAlexG]

peter: you can always change the size by applying constraints on a track

06:07:02 [DrAlexG]

peter: aspect ratio is more ......

06:07:30 [DrAlexG]

fluffy: i couldn t care less how I do it, but I need to be able to specify three specific resolutions for example in JS

06:08:00 [DrAlexG]

fluffy: through contsraints, I can only pass hints. It's surprisingly difficult to get exacting three resolutions.

06:08:20 [DrAlexG]

adam: the JS knows the size of the track, not on the wire after it s encrypted.

06:08:42 [DrAlexG]

all: GetSettings will show you the ACTUAL resolution (not the constraint)

06:09:14 [vivien]

Present+ Andreas_Pehrson

06:09:28 [DrAlexG]

mathieu: why simulcast and not streams in parallel

06:10:01 [DrAlexG]

fluffy: we need timing information to be consistent

06:10:10 [DrAlexG]

peter: can we go back to the example slide?

06:11:12 [DrAlexG]

fluffy: there for example, I don't want integer numbers for the scales, and i want to be able to scale them separately, so I can change the aspect ratio.

06:11:30 [wydong_CM]

wydong_CM has joined #webrtc

06:11:40 [DrAlexG]

peter: that is orthogonal to what we are doing here for simulcast, because it applies to non-simulcast cases.

06:12:31 [ekr]

ekr has joined #webrtc

06:12:31 [DrAlexG]

adam: I would add the blacks bars at rendering time, instead of adding them before encoding, and sending them on the wire, and paying the bandwidth price.

06:12:37 [DrAlexG]

ekr: he wants to crop on send :D

06:12:57 [jesup]

Sending black bars is a waste of bits.... as we all know.

06:12:57 [juberti]

Do we need this for 1.0?

06:13:06 [DrAlexG]

fluffy: use case: full res iphone screen phone factor, low res square, we expect the square to be a crop.

06:13:35 [DrAlexG]

ekr: I do not think we have decided on that. I assume that we never lose data, which means, we don t crop, we add black bars.

06:13:48 [DrAlexG]

<silence>

06:13:56 [DrAlexG]

fluffy: fair enough, my use case still stands.

06:14:13 [DrAlexG]

dan: it s a good valid use case.

06:14:43 [DrAlexG]

ekr: if we crop, which part do we keep ?

06:14:49 [DrAlexG]

fluffy: center

06:14:53 [DrAlexG]

peter: left

06:15:30 [DrAlexG]

ekr: that s a new parameter we would need to add. Cropping is not simple, and merely giving the size of the remaining window would;t be enough.

06:15:36 [ekr]

ekr has joined #webrtc

06:16:44 [DrAlexG]

ekr: you re not going to make a big difference by shaving bits off the thumbnail.

06:17:10 [DrAlexG]

ekr: we might want to do this on the big guy [high res track], that would make sense, but certainly not the low res.

06:17:25 [DrAlexG]

fluffy: lots of people want to do simulcast by setting bitrates

06:17:43 [DrAlexG]

peter: not shown in examples, but existing parameters can all be set here, including bandwidth

06:17:53 [DrAlexG]

fluffy: ok, then what would be missing to achieve my use case?

06:18:10 [DrAlexG]

peter: like what/

06:18:17 [DrAlexG]

fluffy: what was in the RID draft

06:18:38 [DrAlexG]

fluffy: is there anything else that anybody would have asked for. Are you confident that you are ready?

06:19:10 [DrAlexG]

peter: some are missing here, because we set them on the track. Those are not encoding parameters, and we do not want to duplicate parameters all over the place.

06:19:37 [DrAlexG]

fluffy: what about max pixels per second for example. That would be set per simulcast stream. How would I do that?

06:19:54 [DrAlexG]

peter: if there is no encoding parameters, this is not the place to set them. set them on tracks

06:20:08 [DrAlexG]

peter: in this case, you really can t set them.

06:20:29 [DrAlexG]

peter: i propose we go with what we have, and for any new parameters we discuss about them.

06:20:31 [vr000m]

vr000m has joined #webrtc

06:20:43 [DrAlexG]

shijun: also, make the scale parameter a double.

06:21:04 [DrAlexG]

fluffy: it s a good point if I known the frame, otherwise, it does not help.

06:21:22 [pehrsons]

pehrsons has joined #webrtc

06:21:44 [DrAlexG]

peter: i believe that back at the face 2 face, we agreed that the resolution thing was the fundamental thing for 1.0

06:22:11 [DrAlexG]

fluffy: i do not remember that. We are where we are, now i m asking: why can t we put the bitrate here?

06:22:33 [DrAlexG]

stefan: I came out of the f2f meeting saying: let s be practical, stop adding things, and deliver now

06:22:49 [DrAlexG]

fluffy: this is a very concrete proposal that was around for a lot of time.

06:23:27 [DrAlexG]

fluffy: now, I would challenge you if you were, as a chair , saying that it was the consensus of the room after seattle, that it was not the case.

06:23:42 [DrAlexG]

peter: let s get consensus on this right now, and then we propose new things.

06:24:42 [DrAlexG]

ekr: it seems like a fine general structure, and i m ok as long as we are not closing the discussion about what gets in for 1.0

06:24:59 [DrAlexG]

peter: i would like to avoid dragging the discussion so long that we don t deliver.

06:25:12 [DrAlexG]

ekr: let's validate the structure first, the content after

06:25:38 [DrAlexG]

shijun: what s your proposal for new content )bitrate)?

06:26:54 [DrAlexG_]

DrAlexG_ has joined #webrtc

06:27:33 [DrAlexG_]

stefan: at the last meeting we did say that we were drawing the lane.

06:27:45 [DrAlexG_]

line

06:28:24 [DrAlexG_]

dom: this is indeed my remembering, we could also point to several email setting this expectation for the seattle meeting.

06:28:41 [YusukeNakaya_]

YusukeNakaya_ has joined #webrtc

06:29:07 [DrAlexG_]

dom: i also do remember that the only question was about simulcast, and one of the condition was that it could happen in time for TPAC because we wanted to close

06:30:32 [DrAlexG_]

dom: i feel like I'm hearing a consensus about the structure.

06:31:13 [DrAlexG_]

fluffy: there are really two ways. I m fine with the current approach, as long as it gives us capacity to add more attribute. If that s it, then that s no tit for me.

06:31:46 [DrAlexG_]

dom: based on my raw feeling of the room, there seems to be a rough consensus about it because it s reasonable enough

06:31:57 [DrAlexG_]

dom: to be fair your cropping use case might not fit.

06:32:27 [DrAlexG_]

<discussion about cropping>

06:32:46 [DrAlexG_]

<use CSS>

06:33:03 [DrAlexG_]

<getting into 4x4 transformation matrices>

06:33:46 [DrAlexG_]

<agreeing to disagreeing>

06:34:16 [DrAlexG_]

and .... peter is back

06:34:27 [DrAlexG_]

peter: minor questions slide

06:34:30 [mreavy_]

mreavy_ has joined #webrtc

06:34:49 [DrAlexG_]

peter: 1. should the JS be able to set RID?

06:35:21 [DrAlexG_]

peter: 2. Should we just use RtpSender.setParameters() instead of sendEncodings()

06:35:33 [DrAlexG_]

peter: 3. Can a browser receive simulcast?

06:35:53 [adambe]

adambe has joined #webrtc

06:37:53 [npdoty]

First, Do No Harm to the Internet

06:38:15 [DrAlexG_]

<the room is venting>

06:38:53 [DrAlexG_]

<barely surviving the simulcast discussion makes you wander into the strange paths of emojis used as RID in RTP headers limited to 4 bits in good case, and much more in other case>

06:39:22 [DrAlexG_]

fluffy: just let the browser handle it, unless anybody feels strongly about it.

06:40:16 [DrAlexG_]

adam: ok guys, break is over: is anybody against browser picking it?

06:40:36 [DrAlexG_]

fluffy: bernard are you o with that? what s the status in ORTC

06:41:01 [DrAlexG_]

bernard: well, i would prefer it the JS to set it, but then, i wouldn't want to give people the tentation to write shakespeare in this field.

06:41:14 [DrAlexG_]

adam: where is the access for this?

06:41:38 [DrAlexG_]

peter: sender.setParameter(), which does not exist before you actually have a first set.

06:42:45 [DrAlexG_]

[adam: i would prefer to avoid an extra Round trip for the negotiation.

06:43:19 [DrAlexG_]

<nervus breakdown on the mozilla team>

06:44:20 [DrAlexG_]

<rapid show of hand>

06:44:33 [DrAlexG_]

peter: ok JS picks, no more than 16 characters

06:44:45 [DrAlexG_]

martin: not unicode please

06:45:22 [DrAlexG_]

peter: A~&, 0~9, both cases

06:45:24 [DrAlexG_]

all: good

06:45:32 [DrAlexG_]

question 2

06:45:39 [DrAlexG_]

peter: 2. Should we just use RtpSender.setParameters() instead of sendEncodings()

06:46:03 [DrAlexG_]

<room gets silent and humbly request for a break>

06:46:11 [DrAlexG_]

peter: ok so let s keep what we have.

06:46:18 [DrAlexG_]

peter: 3. Can a browser receive simulcast?

06:46:42 [DrAlexG_]

adam: out of scope for 1.0 ?

06:48:18 [DrAlexG_]

<mozilla team breakdown #2>

06:49:27 [DrAlexG_]

adam: in the SFU case, the browser always gets only one stream anyway

06:50:00 [DrAlexG_]

all: even if you send several streams from media server to browser, you can consider them as separate stream.

06:50:38 [DrAlexG_]

dan: coffee disapears in 10mn

06:50:44 [DrAlexG_]

adam: it s bad coffee anyway

06:50:49 [DrAlexG_]

ekr: that answers our question

06:50:52 [DrAlexG_]

stefan: ok coffee

06:51:10 [DrAlexG_]

stefan: when we re back, it will be user media work

06:51:20 [DrAlexG_]

stefan; [not webrtc anymore]

06:52:33 [wdh__]

wdh__ has joined #webrtc

06:55:33 [tomoyuki]

tomoyuki has joined #webrtc

07:07:50 [ekr]

ekr has joined #webrtc

07:07:53 [npdoty]

npdoty has joined #webrtc

07:08:32 [masato]

masato has joined #webrtc

07:08:42 [RRSAgent]

I have made the request to generate http://www.w3.org/2015/10/28-webrtc-minutes.html vivien

07:09:33 [alan_iida]

alan_iida has joined #webrtc

07:10:08 [jib]

jib has joined #webrtc

07:10:25 [oonishi]

oonishi has joined #webrtc

07:10:42 [vivien]

scribe: vivien

07:10:59 [vivien]

Topic: gUM: Results of Constraints registry vote, and implications thereof

07:11:10 [npdoty]

scribenick: vivien

07:11:17 [vivien]

dom: PR related to removal of IANA registry

07:12:03 [vivien]

... I also moved the related section of description of constraints (it was before in a sudo APPENDIX)

07:12:27 [vivien]

... mostly editorial changes

07:12:35 [DrAlexG]

DrAlexG has joined #webrtc

07:12:49 [DrAlexG]

<changing to Media Device>

07:12:53 [vivien]

cullen: it does not quite answer the question, how does extensibility works now ?

07:13:08 [vivien]

dom: right, but not part of this PR, dan will talk about that

07:13:36 [katashin]

katashin has joined #webrtc

07:13:49 [vivien]

martin: is this plan to merge this and talk about the issues Dan will raise ?

07:14:09 [vivien]

dom: yes

07:14:39 [vivien]

martin: goal is to address the last call comment question

07:15:11 [vivien]

Topic: gUM issue 244 Extensibility

07:15:54 [vivien]

burn: Anssi gave 2 links as extensibility examples

07:16:08 [vivien]

-> https://github.com/w3c/mediacapture-main/issues/244 Issue #244

07:16:18 [vivien]

burn: example of sensors API

07:16:30 [vivien]

... how you should name sub classes and so on

07:16:43 [tomoyuki]

tomoyuki has joined #webrtc

07:16:49 [vivien]

burn: we coudl go to this level if we want, but this seems more detailed than what we need

07:17:10 [vivien]

... currently the PR is only 3 paragraphs we could extent

07:17:25 [YusukeNakaya]

YusukeNakaya has joined #webrtc

07:18:22 [vivien]

-> https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#extensibility Service Workers extensibility section

07:18:48 [vivien]

burn: it says this are the precise extensibility points, we need to do some of that but should be more general

07:19:27 [vivien]

martin: good to explain the structure as otherwise you will make it wrong

07:20:11 [vivien]

burn: here it is a "may"

07:20:23 [mishizaw]

mishizaw has joined #webrtc

07:20:46 [vivien]

cullen: what does the name specification mean here ?

07:20:52 [vivien]

burn: it is a good section

07:21:00 [vivien]

s/section/question/

07:21:25 [vivien]

burn: (reading the proposed text in #244)

07:22:19 [vivien]

ekr: this is to distinguish new version of the spec from extension specifications ?

07:22:24 [vivien]

burn: right

07:23:29 [vivien]

burn: if you want to put new requirements on the core spec you will have to contact the maintainer of the core spec

07:24:35 [vivien]

burn: this is very generic stuff, to explain how we care about extension specs

07:25:03 [vivien]

dom: @@dom also the notion of isolated streams, so need to look if we are breaking our own rules here

07:25:37 [vivien]

martin: regarding values for attributes that probably falls to the last category

07:25:57 [vivien]

dom: default behavior for a browser that don't imple

07:26:07 [vivien]

... ment the extension is @@dom2

07:27:05 [vivien]

burn: if you add new value, the 4th bullet applies, so your document has to document expected interoperation of implementation that don't support it

07:27:25 [vivien]

martin: I suggest we remove attributes value as impossible to check

07:27:46 [vivien]

jan-ivar: this is the reason why we are using @@jiv and not DOMString

07:28:20 [vivien]

martin: issue with facing mode

07:28:55 [vivien]

martin: kind of OK for constraints that have a default

07:30:04 [vivien]

martin: eg. extending the range of an integer value would be problematic

07:30:25 [vivien]

jan-ivar: are we saying we can change anything that was written in the WebIDL ?

07:30:34 [vr000m]

vr000m has joined #webrtc

07:30:52 [vivien]

cullen: in W3C I think it means a W3C specification

07:31:56 [vivien]

burn: example of the depth spec, which came up from introduction of a new type besides audio and video including new attributes

07:32:26 [vivien]

cullen: I think we want to discuss mainly adding new constraints

07:32:42 [vivien]

burn: this text is because wanting to do an extension

07:32:58 [vivien]

jan-ivar: then you don't need attribute values

07:33:13 [vivien]

burn: you need it for the "kind" attribute

07:33:24 [vivien]

jan-ivar: is that a DOMString ?

07:33:26 [vivien]

burn: yes

07:33:55 [vivien]

burn: is your point that attributes whose values need to be extended would be on us ?

07:34:22 [vivien]

martin: my expectations was that it would be limited to constraints

07:34:50 [vivien]

dom: cases where enum was not appropriate and were we used DOMString

07:35:10 [vivien]

stefan: Nigel was not only into constraints

07:35:30 [vivien]

burn: current text was my initial thinking

07:35:44 [vivien]

martin: we can call kind explicitely

07:36:07 [vivien]

dom: the requirements imposed by WebIDL and the pros

07:36:18 [vivien]

burn: (reading definition of kind)

07:37:13 [vivien]

dom: we are saying if you are a video mediastreamtrack your kind should be video, not exaplaining what it should be for a new type of mediastream track

07:37:35 [vivien]

burn: this what I did not want to describe as we cannot predict

07:37:52 [vivien]

dom: we have a concrete to learn from, goal is to provide guidance

07:38:12 [vivien]

burn: at a minimal you need to add a new value for kind

07:38:23 [vivien]

martin: define what type it consumes and returns

07:38:25 [vr000m]

vr000m has joined #webrtc

07:38:28 [YusukeNakayaJP]

YusukeNakayaJP has joined #webrtc

07:38:37 [vivien]

dom: depth is a good example to learn from

07:39:26 [vivien]

martin: may we say 2 subs-sections if you want to define a new constraints, and if you want to define a new type of track

07:39:44 [vivien]

burn: nigel by reading the spec thought it was not possible to extend the spec

07:40:05 [vivien]

burn: agree with martin

07:40:23 [vivien]

burn: indicate the webIDL change needed

07:41:10 [vivien]

jan-ivar: I am worried we can extend any WebIDL is too broad

07:41:31 [vivien]

martin: suggestion was follow the rules WebIDL is establishing nothing more

07:41:53 [vivien]

jan-ivar: I thought we can formulate this differently

07:42:05 [vivien]

burn: imprtant to say what you are not allowed to do

07:42:14 [vivien]

martin: I think it is the most important part

07:42:28 [vivien]

cullen: it is fine but people will ignore it

07:43:02 [vivien]

dom: it is a matter of awareness and guiding

07:43:23 [vivien]

burn: then it can be done as additional guidance

07:44:12 [vivien]

dom: if you make that a requirement then you will have to indicate you have 2 implications of this requirements during CR

07:44:27 [vivien]

martin: we have unittests that cover some of this

07:44:57 [vivien]

dom: we could say "Don't be dumb, don't be harm to the Web" without saying a MUST

07:45:08 [vivien]

s/be harm/do harm/

07:45:32 [vivien]

burn: 3rd and 4th bullets are requirements on the extension specifications

07:45:53 [vivien]

dom: you are making writers of extension spec implementors of this section

07:46:18 [vivien]

cullen: I think we are missing critical point: adding new constraints

07:46:27 [vivien]

... how to get a code point

07:47:47 [vivien]

martin: would you prefer to define what specification means here ?

07:47:58 [npdoty]

W3C has a specific definition of "Recommendation", but I don't think it does for "specification"

07:48:37 [vivien]

dom: any other JS API have been extended either in W3C CGs or oustide of W3C

07:49:16 [vivien]

dom: again I think what we want is tfor additionnal constraints to be implemented, and you don't want constraints to reuse names

07:49:21 [kpfleming]

kpfleming has joined #webrtc

07:49:25 [vivien]

cullen: how do we stop name collision

07:49:51 [vivien]

dom: traditional way, eg when you had it on mozilla trunk you will get a compilation error

07:50:42 [vivien]

ekr: is a name reservation by the browsers enough ?

07:51:11 [vivien]

... if something is put on a personnal website that does not count right ?

07:51:53 [vivien]

dom: in CSS they say when something as not reach CR don't put it in the world, you use prefix when it is experimental

07:52:48 [vivien]

cullen: some devices have specific constraints that will not be reused elsewhere

07:53:00 [npdoty]

for link relation values, we just point to a wiki

07:53:18 [npdoty]

http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions

07:53:25 [vivien]

cullen: example of telepresence constraints

07:54:23 [vivien]

dom: you have to be careful on the name you pick so something specific to telepresence

07:55:39 [vivien]

dom: if cisco wants to have cooperation with other products it will have to discuss with those vendors first to have success

07:55:56 [vivien]

ekr: I thought there was a way to register a code point

07:56:18 [vivien]

s/there was/we wanted/

07:56:36 [vivien]

dom: if you want interop the cost is higher

07:57:12 [vivien]

dom: for things you want high interoperability we can learn from what CSS has done

07:57:34 [vivien]

cullen: when we ship thing it is because it works

07:58:04 [vivien]

dom: but the question is it is inter-operable

07:58:11 [vivien]

adamR: @@adamR

07:58:53 [vivien]

jan-ivar: how is it different from writing a spec where I extend a partial dictionnary

07:59:02 [npdoty]

q+ on html link rel registration

07:59:03 [vivien]

ekr: because here we discuss a simple case

07:59:22 [vivien]

dom: jan-ivar says why is it a constraints on not for CSS ?

07:59:30 [vivien]

giri: I agree with jan-ivar

08:00:03 [vivien]

... for mediastram depth extension they take it to the W3C process to ensure interoperability

08:00:09 [adamR]

s/@@adamR/How could we deal with two uses of unprefixed names that end up meaning different things? As an example, if one vendor decided to call something “audioOffset” that talks about the position of a microphone on a soundstage, and someone else calls something else “audioOffset” to mean a timestamp offset into an audio stream, the resulting conflict is irreconcilable./

08:00:53 [vivien]

cullen: let's say we want to add white balance, classic on telepresence

08:01:22 [vivien]

cullen: sure we can work with polycom, pb is that it is not an open source development

08:01:48 [vivien]

... w3c could say we assign you

08:01:59 [vivien]

s/you/you ZZZ/

08:02:22 [vivien]

cullen: how do you know that when you ship your product you are not going to get screwed ?

08:03:12 [vivien]

jan-ivar: isn't the screen sharing implementations of chrome and firefox implementing different specs

08:03:28 [vivien]

giri: @@giri

08:03:48 [vivien]

burn: you have said we don't need a registry can you explain more

08:04:10 [vivien]

martin: it is an authority issue, who as controle here W3C or ... ?

08:04:50 [vivien]

martin: for white balance we did not say no but not now

08:04:58 [vivien]

cullen: that was 4 years ago

08:05:36 [vivien]

ekr: the guarantee you want is to have a code point reservation

08:05:46 [vivien]

... what is the bar to reach that ?

08:06:18 [vivien]

martin: we talked about github repo, cg, bringing stuff to this group, ...

08:07:04 [vivien]

dom: my thinking was that peopel using a prefix for things that don't hit the wide web

08:07:10 [vivien]

martin: 'x-'

08:07:30 [dom]

dom: -cisco-foo

08:08:11 [vivien]

ekr: @@ekr2

08:08:59 [vivien]

npdoty: HTML had this pb for link relations, they were first using IANA and found the process to heavy, so they went to a simple wiki

08:09:28 [vivien]

dom: link rel don't have interoperable issues so a different problem

08:09:38 [mishizaw]

mishizaw has joined #webrtc

08:10:18 [vivien]

ekr: @@@ekr3

08:10:33 [vivien]

martin: the pb is the discoverabilty of others people names

08:11:02 [vivien]

... can be as simple as a web search

08:11:28 [vivien]

cullen: I was not successful doing that in the past

08:12:17 [vr000m]

vr000m has joined #webrtc

08:13:26 [vivien]

vivien: here we are talking about referencing a wiki page, this is similar to a registry and we voted not

08:13:37 [vivien]

... so anyone is free to create that wiki page

08:13:51 [vivien]

stefan: it will simply not be referenced from the spec

08:14:22 [npdoty]

q-

08:14:38 [npdoty]

HTML5 describes how to add a link type here: http://www.w3.org/TR/html5/links.html#other-link-types

08:14:55 [vivien]

cullen: does the W3C would commit to not using names from that list ?

08:15:05 [vivien]

jan-ivar: that sounds like a registry

08:15:50 [vivien]

ekr: CR does, what else does ?

08:16:18 [vivien]

cullen: I am goin to implement this extension and want to make sure to reserve to not have a conflict

08:16:27 [npdoty]

wikis are a good way to prevent accidental overlap. almost nothing can prevent intentional conflicts

08:17:07 [vivien]

ekr: @@@ekr4

08:17:39 [vivien]

ekr, can you write down what you are saying, you are talking way fatser than by yping or even my brain

08:19:52 [vivien]

martin: I think cullen pb is ensure that the community knows aboiut cullen we don't want to block all use cases

08:21:04 [vivien]

cullen: @@cullen3

08:22:05 [vivien]

nick: as a process manner it is difficult for the W3C to constraints other developments

08:22:50 [vivien]

martin: we could say if people are aware of usage of some names then they should not reuse names

08:23:21 [fluffy]

Key thig is this community (the WG) agrees that if someone comes and gets a code point for a constraint in a given way, then this standards orgnaiaiton is not going to stomp on it

08:23:34 [vivien]

ekr: reserving a code point require a W3C REC high cost, or a W3C CG

08:24:06 [vivien]

cullen: you need to inform people

08:24:21 [vivien]

ekr: can people notify public-webrtc list ?

08:24:23 [vivien]

cullen: sure

08:25:12 [vivien]

martin: sounds good

08:25:54 [vivien]

nick: you can't have commitment from the entire consortium unless you go in front the AC

08:26:21 [vivien]

martin: we would write it in the right way

08:26:42 [vivien]

stefan: sounds we ahve rough consensus how do we move forward

08:27:30 [vivien]

martin: I suggest dan write a first version adding guidance on notifying the WG for new extensions

08:27:40 [vivien]

stefan: ok we have a plan

08:28:01 [wydong_CM]

RRSAgent, draft minutes

08:28:01 [RRSAgent]

I have made the request to generate http://www.w3.org/2015/10/28-webrtc-minutes.html wydong_CM

08:28:26 [vivien]

Topic: gUM status of Last Call Comments

08:28:40 [vivien]

stefan: we had 19 comments after the deadline, now done to 1

08:28:57 [vivien]

... last one from justin, which should be resolved when we merge dom's PR

08:29:04 [vivien]

martin: ok done !

08:29:26 [vivien]

burn: we can wait till we merge the PR than answer and close this

08:29:44 [vivien]

stefan: after that we had comments coming after that

08:30:02 [vivien]

mathieucitrix: isn't there some ongoing privacy issues ?

08:30:10 [vivien]

brun: yes with nick

08:30:18 [vivien]

s/brun/burn/

08:30:44 [vivien]

burn: should we create issue based on nick's email ?

08:31:19 [vivien]

stefan: I have not read the full thread but we discussed part of this today with the iframe issue

08:31:38 [vivien]

nick: I don't see some of the reported issues

08:31:55 [ekr]

https://github.com/w3c/mediacapture-main/issues/244#issuecomment-152111790

08:31:56 [vivien]

stefan: we ask people to send them as github issues

08:32:32 [vivien]

burn: yes usually we let the discussion happen then the chairs ask the reporter to fill an issue

08:32:51 [vivien]

stefan: will you file an issue(s) ?

08:33:11 [vivien]

nick: there are sperate issues in that thread, do you want me to fill multiple ones ?

08:33:19 [vivien]

stefan: yes

08:33:28 [vivien]

martin: this ensure we don't miss anything

08:34:03 [npdoty]

ekr is always awake enough to discuss security, it sounds like

08:34:07 [vivien]

ACTION: npdoty to fill in github the various privacy issues he reported

08:34:07 [trackbot]

Error finding 'npdoty'. You can review and register nicknames at <http://www.w3.org/2011/04/webrtc/track/users>.

08:35:53 [vivien]

nick: most important 1) iframe 2) programmatic way for sites to revoke permission or for site to indicate a permission should not be persistent

08:37:24 [vivien]

nick: ekr I understand you discussed that previously my alternative where: say this is one time only, and possibility to revoke a persistent permission

08:38:44 [vivien]

shinjoun: regarding the iframe, if the domain is the same as the parent page, this is something to think about

08:39:02 [vivien]

s/shinjoun/shinjun/

08:39:25 [vivien]

nick: sounds like the chrome implementation is fine

08:39:34 [vivien]

martin: this is what I proposed

08:40:29 [vivien]

martin: (looking at options outlined in issue #267)

08:41:35 [npdoty]

npdoty has joined #webrtc

08:41:46 [vivien]

ekr: 4. is not a pain to implement for us

08:41:54 [YusukeNakaya_]

YusukeNakaya_ has joined #webrtc

08:42:03 [YusukeNakayaJP]

YusukeNakayaJP has joined #webrtc

08:42:14 [vivien]

cullen: one use case is call centers

08:42:27 [vivien]

ekr: yes you might only use the service once or twice a year

08:42:46 [vivien]

mathieucitrix: yes the user would expect this

08:43:19 [RRSAgent]

I have made the request to generate http://www.w3.org/2015/10/28-webrtc-minutes.html vivien

08:43:33 [vivien]

cullen: I think 4. is the most realistic

08:43:42 [vivien]

martin: I'm with you fluffy

08:44:06 [vivien]

ekr: the browser would decide

08:44:36 [vivien]

mathieucitrix: no because my application would work differently on different browsers

08:44:51 [vivien]

mathieucitrix: for me option 6. is a no go

08:46:06 [vivien]

mathieucitrix: I would prefer not 6. for the reason expalined by fluffy and mathieucitrix

08:46:59 [vivien]

ekr: I don't see a lot of value for sites to be able to revoke permissions

08:47:39 [vivien]

ekr: the use case is if you are worried for the privacy of your users

08:47:45 [vivien]

s/ekr:/nick:/

08:48:18 [vivien]

nick: if it is uncommon but helps a lot of users (eg used by gravatar) it is great

08:48:39 [vivien]

dom: it is fair to say if chrome did not have the defaults to persist permission on https

08:48:57 [ekr]

"The API MUST provide a mechanism for the requesting

08:48:57 [ekr]

JS to indicate which of these forms of permissions it is

08:48:57 [ekr]

requesting. This allows the browser client to know what sort of

08:48:57 [ekr]

user interface experience to provide to the user, including what

08:48:59 [ekr]

permissions to request from the user and hence what to enforce

08:48:59 [ekr]

later. For instance, browsers might display a non-invasive door

08:48:59 [ekr]

hanger ("some features of this site may not work..." when asking

08:49:00 [ekr]

for long-term permissions) but a more invasive UI ("here is your

08:49:00 [ekr]

own video") for single-call permissions. The API MAY grant weaker

08:49:00 [ekr]

permissions than the JS asked for if the user chooses to authorize

08:49:01 [ekr]

only those permissions, but if it intends to grant stronger ones

08:49:01 [ekr]

it SHOULD display the appropriate UI for those permissions and

08:49:01 [ekr]

"

08:49:26 [vivien]

ekr: I pasted what is the requirement in the specification

08:49:30 [dom]

s/ persist permission on https/ persist permission on https, we would not have that conversation/

08:50:35 [vivien]

varun: if you relaod the page will it ask again ?

08:50:47 [vivien]

ekr: firefox does, chrome doesn't

08:51:03 [npdoty]

my only new information is the suggestions of alternative API designs: oneTimeOnly=true, or a revoke() method

08:51:29 [vivien]

dom: I think the firefox model is better here, it is better for privacy

08:52:09 [vivien]

martin: google folks are well aware it is a point of differenciation between browsers

08:52:14 [victor_pascual]

victor_pascual has joined #webrtc

08:52:34 [vivien]

mathieucitrix: we are not removing this from browsers just letting application developpers chose

08:52:58 [vivien]

martin: if the option changes it would be confusing to the user

08:53:32 [jystewart]

jystewart has joined #webrtc

08:53:55 [vivien]

martin: browser developers are very sensitive in trying to protect their users

08:54:29 [ekr]

Thread starts here: https://lists.w3.org/Archives/Public/public-media-capture/2015Mar/0001.html

08:54:39 [vivien]

nick: when I raised the issue it was more that some site developers might feel in an uncomfortable situation if the permission is being persisted

08:54:51 [vivien]

nick: sites might know things that you don't

08:55:21 [vivien]

nick: I am providing suggestion to the group

08:55:31 [mishizaw]

mishizaw has joined #webrtc

08:57:23 [vivien]

(firefox team looking over at chrome options)

08:58:04 [vivien]

s/chrome options/clear site data spec/

08:59:17 [wonsuk]

wonsuk has joined #webrtc

08:59:36 [vivien]

cullen: maybe revoke is one form for this

08:59:52 [jystewart]

jystewart has left #webrtc

09:00:14 [vivien]

cullen: if their is a revoke in the permissions API we can rely on that too but too me it feels like a bad idea

09:00:27 [katashin_]

katashin_ has joined #webrtc

09:00:45 [vivien]

dom: so if gUM permissions belongs to the Permissions API this solve the discussion

09:00:54 [vivien]

dom: they do have a revoke API

09:01:18 [vivien]

ekr: if revoke is a good idea...

09:01:30 [vivien]

dom: the logout use case sounds good

09:02:41 [vivien]

dom: how do we proceed are we exploring the Permissions API approach ?

09:03:09 [vivien]

martin: I don't think we reached consensus on @@mt1

09:03:36 [vivien]

... for revoke we can follow webapps work so if they think it is a good idea

09:03:59 [vivien]

dom: nick you that satisfy your comment ?

09:04:19 [vivien]

nick: @@npdoty

09:05:11 [vivien]

nick: it will be hard to get the group satisfied if your answer is it maybe it would be handled by the webapps group

09:05:18 [wydong_CM]

wydong_CM has joined #webrtc

09:05:27 [vivien]

stefan: sounds like a good answer if we leave that to the experts

09:05:36 [wydong_CM]

rssagent, draft minutes

09:05:49 [RRSAgent]

I have made the request to generate http://www.w3.org/2015/10/28-webrtc-minutes.html vivien

09:13:38 [wonsuk]

wonsuk has joined #webrtc

09:34:25 [npdoty]

npdoty has joined #webrtc

09:35:10 [npdoty]

npdoty has left #webrtc

09:43:13 [kpfleming]

kpfleming has joined #webrtc

10:08:31 [hta]

hta has joined #webrtc

10:44:51 [kpfleming]

kpfleming has joined #webrtc

11:27:27 [victor_pascual]

victor_pascual has joined #webrtc

12:06:44 [mishizaw]

mishizaw has joined #webrtc

12:18:04 [iwashi]

iwashi has joined #webrtc

12:48:26 [hta]

hta has joined #webrtc

13:04:46 [hta]

hta has joined #webrtc

13:11:04 [hta]

hta has joined #webrtc

13:13:58 [hta]

hta has joined #webrtc

13:17:11 [hta1]

hta1 has joined #webrtc

13:27:17 [hta]

hta has joined #webrtc

13:39:26 [hta]

hta has joined #webrtc

14:04:43 [hta]

hta has joined #webrtc

14:24:37 [Zakim]

Zakim has left #webrtc

14:25:47 [mishizaw]

mishizaw has joined #webrtc

14:54:43 [mishizaw]

mishizaw has joined #webrtc

15:14:55 [adamR]

adamR has joined #webrtc

15:27:16 [adamR]

adamR has joined #webrtc

15:28:09 [mishizaw]

mishizaw has joined #webrtc

15:44:18 [adamR]

adamR has joined #webrtc

17:00:41 [mishizaw]

mishizaw has joined #webrtc

18:14:18 [hta]

hta has joined #webrtc

19:02:59 [mishizaw]

mishizaw has joined #webrtc

19:44:20 [hta]

hta has joined #webrtc

20:10:44 [kpfleming]

kpfleming has joined #webrtc

20:35:17 [mishizaw]

mishizaw has joined #webrtc

20:46:23 [ekr]

ekr has joined #webrtc

21:37:57 [mishizaw]

mishizaw has joined #webrtc

21:41:33 [ekr]

ekr has joined #webrtc

21:43:41 [ekr]

ekr has joined #webrtc

21:47:38 [ekr]

ekr has joined #webrtc

21:54:35 [ekr]

ekr has joined #webrtc

22:33:54 [ekr]

ekr has joined #webrtc

22:38:43 [mishizaw]

mishizaw has joined #webrtc

22:53:33 [hta]

hta has joined #webrtc

23:04:40 [mishizaw]

mishizaw has joined #webrtc

23:25:11 [toddg]

toddg has joined #webrtc

23:30:40 [vivien]

vivien has joined #webrtc

23:31:45 [vivien]

RRSAgent, draft minutes

23:31:45 [RRSAgent]

I have made the request to generate http://www.w3.org/2015/10/28-webrtc-minutes.html vivien

23:32:26 [vivien]

i/stefan: at the last meeting/Scribe: DrAlexG_/

23:32:26 [vivien]

RRSAgent, draft minutes

23:32:26 [RRSAgent]

I have made the request to generate http://www.w3.org/2015/10/28-webrtc-minutes.html vivien

23:32:59 [vivien]

RRSAgent, bye

23:32:59 [RRSAgent]

I see 1 open action item saved in http://www.w3.org/2015/10/29-webrtc-actions.rdf :

23:32:59 [RRSAgent]

ACTION: npdoty to fill in github the various privacy issues he reported [1]

23:32:59 [RRSAgent]

recorded in http://www.w3.org/2015/10/28-webrtc-irc#T08-34-07