23:56:04 RRSAgent has joined #webrtc 23:56:04 logging to http://www.w3.org/2015/10/28-webrtc-irc 23:56:12 RRSAgent, make logs public 23:56:26 Meeting: WebRTC TPAC 2015 F2F 23:56:49 Agenda: https://www.w3.org/2011/04/webrtc/wiki/October_29_-_30_2015#Thursday_October_29 23:57:01 Chair: Harald & Stefan 23:58:02 Present+ Maire_Reavy, Randel_Jesup 00:01:00 Shijun has joined #webrtc 00:01:20 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 on webex we have: Maire & Randel 00:02:14 vr000m has joined #webrtc 00:02:14 Present+ Kevin_Fleming, Adam_Alfar, Shijun, PeterT, MartinT, AdamR, Varun, Cullen, Matthieu, Alex, AndrewH, Vivien, DanB, StefanH, Harald, Dom 00:02:22 juberti has joined #webrtc 00:02:33 mt_____ has joined #webrtc 00:02:40 adamR has joined #webrtc 00:02:46 Is there a dial-in for this meeting? 00:02:58 it's on the agenda page 00:03:04 just added apparently 00:03:19 burn has joined #webrtc 00:03:22 dom has changed the topic to: https://www.w3.org/2011/04/webrtc/wiki/October_29_-_30_2015 00:03:27 Agenda: https://www.w3.org/2011/04/webrtc/wiki/October_29_-_30_2015 00:03:29 s/Is there a dial-in for this meeting?// 00:03:37 s/it's on the agenda page// 00:03:38 jesup has joined #webrtc 00:03:45 s/just added apparently// 00:04:00 Topic: Agenda review for Thursday 00:04:05 stefan: Going throigh agenda 00:04:08 scribe: mathieucitrix 00:04:30 s/throigh/through/ 00:05:38 ... is everybody ok swapping simulcast and webrtc privacy afternoon sessions? 00:05:49 toddg has joined #webrtc 00:05:50 Present+: Justin_Uberti 00:05:52 Present+ Justin_Uberti 00:06:04 masato has joined #webrtc 00:06:50 mreavy has joined #webrtc 00:08:25 harald: adding agenda bashing tomorrow morning for friday 00:08:45 Present+ gmandyam 00:08:58 stefan: moving on to added functionality 00:09:26 so: agenda is: transceiver and other 1.0 stuff this morning; simulcast in afternoon; IP privacy tomorrow morning? 00:09:49 wydong_CM has joined #webrtc 00:10:31 Topic: Added functionality in WebRTC-1.0 after interim meeting 00:10:49 stefan going through list of what was agreed since seattle 00:10:56 igarashi_ has joined #webrtc 00:11:26 toddg has left #webrtc 00:11:28 martin: didn't have time to finish PR for pre-negotiation 00:11:39 toddg has joined #webrtc 00:12:27 stefan: almost all done for items since seattle. separate discussion for simulcast 00:12:51 ... peter can go for slides on transciever 00:14:48 -> https://www.w3.org/2011/04/webrtc/wiki/File:RtpTransceivers_at_TPAC_2015.pdf PeterT's slides on Transceiver 00:15:04 peter: Things that we added: 1:1 mapping between mline and transceiver 00:15:43 ... method for creating transceiver 00:16:35 martin: why do we have get transciver as getter 00:17:53 ... should mid be on transceiver ? 00:18:18 peter: for linking back to sender 00:18:35 martin: there is no attribute ? 00:18:39 peter: no 00:19:38 So martin said we need to mark the sender and receiver objects as “saome object” in webild 00:19:43 seemed to agrement on that 00:20:20 hta has joined #webrtc 00:20:20 going afk for a bit; back in ~1hr 00:21:20 Present+ Taylor_Brandstetter 00:21:53 fluffy: is removing offerToReceive not a problem for breaking what's out there already ? 00:22:22 martin: remove from spec but keep in implem and deprecate 00:22:45 adam: we're prefixed anyway so not a problem: 00:23:01 martin: FF 44 has webrtc unprefixed 00:23:22 ... will have both prefix and unprefix because of broken polyfills 00:23:55 masato has joined #webrtc 00:24:00 peter: leave to browser to handle as implem decision but remove from spec 00:24:38 fluffy: document in backwards compatibility section ? 00:24:53 martin: ok either way 00:25:43 harald: consensus is removing 00:26:14 peter: removeTrack deactivates instead of removing sender 00:27:24 ... simplified version of examples 00:28:13 kpfleming has joined #webrtc 00:29:18 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 hta: ^^^ 00:29:51 jib has joined #webrtc 00:30:34 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 harald: if things are wired that packets manage to come in, then yes 00:32:11 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 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 peter: if iframe comes in before fingerprint, we can rprocess it but not render it 00:33:18 Present+ Jan-Ivar_Bruaroey 00:34:14 dom: that example in not in any PR 00:34:23 peter: will fix that 00:34:36 ... next, remaining questions 00:34:59 ... when does addtrack reuse sender 00:35:05 mishizaw has joined #webrtc 00:36:02 ... option a: reuse sender if inactive 00:37:00 fluffy: can we drop whole problem of replace track onto JSEP ? 00:37:21 peter: JSEP doesn't fully solve it yet ? 00:38:19 peter: option C, recommended, reuse sender if never been active 00:38:30 fluffy: that's what jsep does 00:38:52 ... worried this is defined in 2 places 00:39:18 peter: already refers to jsep 00:39:37 dozawa has joined #webrtc 00:39:54 fluffy: this sounds like agreement on solution, we need to figure out how to put it correcty in spec 00:40:40 dan: shouldn't use word "resuse", since it's really use if never been used 00:41:29 harald: concensus on C. need to figure out which document writes it 00:42:09 adam: theres a discrpeency with jsep. 00:42:59 s/discrpeency/discrepancy/ 00:43:00 martin: jsep says you can revive if both sides know it's gone, port 0 00:43:08 ... we're missing that here 00:43:24 ... not using what justin carefully crafted 00:43:56 peter: justin said use case was too complicated and so didn't have to handle it 00:44:00 wonsuk has joined #webrtc 00:44:50 harald: receiver is gonna see the wrong thing on other end. so only solution is to signal. 00:45:55 martin: I think what happen is that new transciever sender and receiver might reuse mid 00:46:33 fluffy: at any given point one to one relationship between mline and transceiver 00:47:01 ... but if mline is gone and transceiver gone, then new one might end up on same mline 00:48:04 martin: there is a concern. all good on sender side, but receiver might not know. solution is to change mid 00:48:23 fluffy: need justin and ekr and whiteboard this 00:48:58 martin: can try to solve it tomorrow. ekr will be here. 00:49:13 fluffy: record strawman so justin can catch up 00:49:13 mishizaw has joined #webrtc 00:51:53 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 peter: question 2 00:53:10 ... how to activate transceiver without calling addTrack 00:53:31 ... option a: setActive 00:55:08 harald: should we make all senders active by default ? 00:55:51 peter: would need to change addTrack logic to behave like replaceTrack ? 00:56:20 harald: it's in case of never been used, so shouldn't need to change anything 00:57:49 peter: idea is sender are automatically activate, and redefine addTrack as if active sender that never had track, use replaceTrack logic ? 00:58:05 ... this might work 00:59:15 fluffy: deafult in SDP is send receive. still need a way to "deactivate" 01:00:18 peter: option b: put activate sender on transceiver 01:00:21 ... sound like one off 01:00:59 fluffy: setDirection on transceiver might make more sense. and reflects what's going on in SDP. wouldn't feel weird 01:02:34 ... active is not a good name 01:03:02 wonsuk has joined #webrtc 01:03:06 tomoyuki_ has joined #webrtc 01:03:19 kinjim has joined #webrtc 01:03:20 peter: so everybody happy with transceiver ."setHorrible" ? 01:03:55 harald: setRemoteDescrition might change thos bits 01:04:30 ... transceiver need to go muck with sender and receiver 01:05:33 peter: is all this worth it compared to say, if you do warm up, you'll have to do re-offer 01:06:06 fluffy: you might just be able to do offer, provisional answer, answer 01:06:28 peter: if that's true we dont need setHorrible ? 01:07:36 peter: scenario already fine in non-warm up 01:07:37 present+ Erik_Lagerway, Bernard_Aboba, Robin_Raymond 01:07:47 fluffy: are we trying to solve a non-problem 01:08:03 wonsuk has joined #webrtc 01:08:53 ... this example is not enough to see where the issue is 01:10:19 fluffy: nice option with this is we dont need pranswer 01:10:37 ... but it's still 2 signalling messages 01:10:55 peter: 2 q: is ugly bit worth it? what is exactyly the ugly bit 01:11:17 martin & fluffy: yes needed, peter to decide what api looks like 01:11:47 (that was option B) 01:11:49 peter: question 3, harder question, rollback 01:12:29 ... option a, never remove transceiver 01:13:06 fluffy: if it's there, is it functional, how do you know ? 01:13:22 martin: how do you diff between good & bad 01:13:27 peter: not good option 01:13:37 ... option b: always remove 01:14:28 martin: crux of problem: are you rolling back remote offer, or everything done since left stable ? 01:15:30 martin: what if stable, call addTrack, then setRemote. track might be added to existing transceiver . what do you do on roolback ? 01:15:46 fluffy: you go back to stable 01:17:08 martin: this doesn't work, describing issue if some tracks were added, others not 01:17:24 ... should roll back offer, not add tracks 01:17:34 .. let tracks sit there 01:17:51 fluffy: ok, that;s about negotiated offer 01:17:58 peter: option b no god 01:18:08 s/god/good/ 01:18:37 peter: option c, ... out not possible 01:18:58 peter: option D, 01:20:08 martin raising an issue 01:20:23 peter: option E is meh 01:20:30 peter: option E 01:20:43 s/option E is meh/option D is meh/ 01:21:50 fluffy: this is weird but might be less weird, more fitting mline 01:21:51 s/that;s 01:22:02 martin: this might be combined with others 01:22:08 s/that;s/that's/g 01:22:12 peter: E is potential, option F 01:23:12 ... has potential too 01:23:34 kinjim has joined #webrtc 01:23:53 martin: option F is very close to current FF implementation of rollback, so it's kinda right, but need better model 01:23:58 peter: option G 01:24:41 martin: sounds like option D with extra thing 01:24:59 ... so better than D 01:25:19 fluffy: it's consistent with everything else we've done 01:25:21 mishizaw has joined #webrtc 01:25:39 peter: option H 01:26:35 harald: there's one case where you need to rollback remote offer: glare 01:27:03 peter: but you roll back local offer, not remote 01:28:35 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 peter: all sounds like weird edge cases 01:29:40 fluffy: need to do something to get back to stable state though 01:31:01 martin & adam: H looks better and better 01:31:41 harald: on rollback, transceiver that haven't been used, go in mid bucket 01:32:21 peter: G might not actually solve problem 01:33:24 ... down to E, F, H 01:35:16 martin: G by itself is not enough but might give you a good base 01:35:55 peter wants to revive part of B 01:37:35 peter: go with G, call addtrack, add to pending, rollback, pending ones stay around ? 01:38:24 harald: need way to find pending and kill them 01:40:27 back 01:41:19 addTrack creates a pending transceiver 01:41:27 setRemote(offer) creates a pending transceiver 01:41:47 summary, martin & peter to work on G + F 01:41:51 addTrack adds a sender to the transceiver; setRemote(offer) adds a receiver to the transceiver 01:42:28 on rollback, transceivers are removed from the pending unless they have an active sender 01:42:48 H is needed as long as we want to be able to reject offers. 01:43:23 (this has the consequence of activateSender() being persisted 01:43:42 juberti: is that back to front? H is to now permit rejecting of offers 01:44:22 sorry, H is to not permit rejecting offers 01:44:43 H is to not permit rollback; I was making the point that that implies no rejection, which seems drastic. 01:45:22 are we taking a break, or moving to the next preso? 01:45:31 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 has joined #webrtc 01:56:51 Lags has joined #webrtc 01:58:23 mishizaw has joined #webrtc 02:06:22 mishizaw has joined #webrtc 02:07:46 everybody is coming back to the room, about to resume 02:08:05 stefan: next up, codec selection 02:09:22 martin: application might want to exert control over what browser negotiates 02:09:55 kinjim has joined #webrtc 02:10:41 ... I sent email to mmusic, will simulcast allow you negotiate things in one direction but not other 02:10:56 adam: were reluctant to spec that out so far. 02:11:16 martin: simulcast is asymetric 02:11:22 let's just keep it simple and be asymmetric 02:11:30 adam: don't want to make mandatory for webrtc 02:11:34 er, symmetric 02:11:52 martin: let get to the question first 02:12:18 on slide 4 02:13:24 fluffy: weird that you get list from one object and set on another 02:13:34 martin: that's why there's other slide 02:15:11 aaa: appliation is basically ordering list, what if codec is not ... 02:15:30 marting: something about hardware codec 02:16:01 fluffy: I have proposal to be in line with SDP 02:16:19 ... person that generates answer need to accept preference order of offer 02:16:38 ... order set here controls what is in offer 02:17:08 martin: question is on answer, what do you follow, spd, local setting, browser implem 02:17:28 fluffy: need to be deterministic 02:18:22 martin: should affect sdp 02:18:34 ... we working on this so we don;t have to munch sdp 02:19:45 adam: sdp is pretty thorough. order is meaningful. but both sides don't have to have same order 02:21:32 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 ... next, alternative (slide 5) 02:22:55 peter: 2 things set availble and set order 02:24:00 martin: this is closer to getCapabilities and Prederence on sender and receiver but issue 02:25:40 martin: first option seem better way to do it 02:25:56 fluffy: with adaptations from adam 02:26:20 martin: PR might already have been merged? 02:27:08 peter: already have non active flag when no track on transceiver 02:27:56 martin: conclusion option 1, with adam interpretation of SDP. 02:28:16 martin: affect both offer and answer 02:30:00 fluffy: have to define on re-offer what you do with order. should maintain. 02:30:13 all agreed 02:30:21 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 has joined #Webrtc 02:30:37 When we do a reoffer, we maintain the previoulsy negotated ordering 02:33:10 stefan: end of morning sessions, can we sneak in soenthing before lunch break 02:33:37 conclusion is that the codec ordering determines what is put in SDP 02:34:09 Did we discuss what happens if telephone-event, CN, red, FEC, rtx appear in codec preferences? 02:34:11 SDP determines what - absent overriding preferences - a sender uses 02:34:22 Topic: Stats 02:34:29 I have made the request to generate http://www.w3.org/2015/10/28-webrtc-minutes.html vivien 02:34:30 juberti - I mentioned those as being overriding preferences 02:34:30 doing stats (originally Friday afternoon) 02:34:41 ? 02:35:05 as in if they are ordered above more useful things, then they won't get chosen just because they come first 02:35:28 I guess we could decide that these generate errors, or ordering of them are ignored 02:35:41 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 I don't think that's particularly important to address now, we can nut that out in the PR discussion 02:36:25 vr000m has joined #webrtc 02:36:30 https://docs.google.com/presentation/d/12VCXshmaiM1W_cbJiMrhVZVNuzTaCDpJOjkJsHKEkng/edit?usp=sharing 02:36:33 well, I was wondering if we would always stuff these at the end regardless of setCodecPreferences. Agree this is small beer 02:37:19 varun: 2 updates since TPAC 2014 02:37:26 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 varun: open issue #5 02:39:07 ... question is to knwo where to define RTCStats, in webrtc-pc or webrtc-stats 02:40:01 fluffy: stats document cpuld be considered as first official extension 02:40:11 ... base doc has base object definition 02:40:45 harald: might need to repeat definition of object 02:40:50 ... for convenience 02:41:10 geheimnis` has joined #webrtc 02:41:44 varun: stats document would stay open longer 02:42:05 fluffy: can't implement living standards. need to have one doc with mti, and then open another one 02:42:38 ... some stats normative in webrtc spec, then add more in extensions doc for stats. 02:43:11 for setCodecPreferences, we just need to ensure that ordering is maintained across reoffers, regardless of browser preferences. That prevents oscillation. 02:43:59 harald: action item for dom to share link to document on naming 02:44:07 ... for hyphen 02:44:20 varun: issue #7 02:44:32 ... PR not merged 02:45:02 "Enumeration values: Lowercase, dash-delimited " in http://w3ctag.github.io/design-principles/#casing-rules 02:45:53 ... if non controversial, go ahead and merge 02:46:03 varun: issue #11 02:46:44 RTCIceCandidateAttributeInfoStats... sounds like Java 02:46:56 ... should we add "info" to all too ? 02:47:11 martin: can't we just have "Stats" 02:48:47 mathieucitrix: don't we have some of the "static" stuff on other objects? 02:48:55 peter: we have both now 02:49:25 justin: odd we have 2 dict that have same info 02:49:38 martin: should all be interfaces 02:50:05 justin: peter can't we go use the ice objects directly and do away with stats 02:50:13 http://www.w3.org/TR/2014/WD-webrtc-stats-20141021/#icecandidate-dict* 02:50:37 bbb: can't we share same object 02:50:42 harald: no 02:51:29 martin: or have Stats interface implement RTCCandidate 02:52:03 ... not possible with dict but might be possible with interface here ? 02:52:47 justin: need to at least make them look the same 02:53:07 martin: if they're copy of each other, ok 02:53:27 peter: stats has one more field with associated turn / stun url 02:54:00 justin: stats object is also missing a field 02:54:47 martin: have stats have everything, or both have everything 02:54:58 peter: or embed? 02:55:08 harald: filed issue #31 02:55:48 martin: peter has suggestion: put address in stats, and embed RTCCandidate 02:56:19 harald: something about serializer 02:57:42 justin: remove RTCIceCandidateAttributes, and embed RTCIceCandidate in the PairStats 02:57:54 harald: lots of duplication 02:58:18 bbb: we want to avoid duplicating all that info 02:58:36 bbb=Jan-Ivar 02:59:01 s/bbb/Jan-Ivar 02:59:51 Good by me 03:00:07 fluffy: lets get rid of Attributes and Info, everybody agree, done 03:00:15 RTCIceCandidateStats and RTCIceCandidate. Sold. 03:00:20 varun: issue #13 03:00:52 fluffy: should reference IETF spec 03:01:12 harald: draft expired 2012 03:01:33 fluffy: tell to resubmit, w3c shouldn't define this stuff 03:01:52 Did we discuss #12? 03:02:06 varun: conclusion: tell magnus to put definition in active draft 03:02:16 RTCIceCandidateStats.addressSourceUrl is different than RTCIceCandidateEvent.url 03:03:00 harald: action for adam to ping magnus 03:03:12 varun: issue #16 03:04:33 martin: opposed, raise risk of app parsing and changing behavior based on content like user agent. 03:05:20 harald: should have standard way to parse info. but only if can make it useful for stats 03:10:48 martin: massive fingerprinting surface 03:11:21 mathieucitrix: can we get info of whether hardware of software decoder is used in stats 03:11:45 adam: does not belong in stats 03:12:18 fluffy: ok with one bit of info, but not in stats 03:12:32 varun: issue # 03:12:57 all: undefined 03:13:21 justin: did we discuss #12 03:13:28 varun: has already been fixed 03:13:42 justin: it's inconstitent 03:13:51 harald: noted that in issue #31 03:14:18 ((#issue 21) 03:14:47 s/#31/#21 03:15:19 fluffy: we need some stats being defined as MTI in webrtc-pc 03:16:13 varun: add new metrics. packetsDiscarded/Repaired 03:16:34 fluffy: useful, should be defined, maybe not MTI 03:16:48 justin: what does repair mean 03:16:54 varun: retransmit or fec 03:18:33 varun: process for adding new metrics ? 03:19:07 fluffy: should we bundle that with extensibility discusssion of media capture later this afternoon ? 03:19:34 ... process in IETF is you can define whatever, and anyone can chose to implement or not 03:20:03 ... so here, define, and then main doc can bring in what is deemed good 03:21:58 dan: difference with extensibility discussion later, is this is only data structure 03:22:55 fluffy: living document not ok 03:23:27 harald: want to avoid DOM experience with levels 03:24:16 fluffy: usually only adding, so new ones can go in new document 03:24:54 discussion to continue over lunch for those interested 03:25:45 jxck has joined #webrtc 03:49:33 frodek has joined #webrtc 04:01:47 jxck has joined #webrtc 04:02:50 tomoyuki has joined #webrtc 04:04:26 hta has joined #webrtc 04:08:42 oonishi has joined #webrtc 04:14:58 iwashi has joined #webrtc 04:19:50 masato has joined #webrtc 04:25:16 npdoty has joined #webrtc 04:27:29 npdoty has joined #webrtc 04:28:27 burn has joined #webrtc 04:29:03 adamR has joined #webrtc 04:30:20 vr000m has joined #webrtc 04:30:35 now. 04:30:38 fluffy has joined #webrtc 04:31:23 igarashi has joined #webrtc 04:34:49 justin: slide 2 04:35:12 juberti: slide 3 (concerns) 04:35:29 where are the slides? 04:36:14 juberti: slide 4 (consideration) 04:36:25 wonsuk has joined #webrtc 04:36:51 alan_iida has joined #webrtc 04:37:19 -> 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 has joined #webrtc 04:37:53 mishizaw has joined #webrtc 04:38:13 ekr: DHCP reliably gives you the same IP address. 04:38:36 juberti: there are other things that can be done here, like UA fingerprinting 04:38:41 kinjim has joined #webrtc 04:38:42 ekr: agree 04:40:00 Topic: WebRTC privacy - IP address leakage 04:40:02 juberti: slide 5 (goals) 04:40:59 oonishi_ has joined #webrtc 04:41:16 ekr has joined #webrtc 04:41:29 Citation for TCP timestamp fingerprinting 04:41:41 juberti: slide 6 (restricted gathering) 04:41:53 dom has joined #webrtc 04:42:05 https://www.caida.org/publications/papers/2005/fingerprinting/KohnoBroidoClaffy05-devicefingerprinting.pdf 04:42:34 dandan has joined #webrtc 04:42:51 adamR: per address family. 04:43:09 martin: 1 address per family on that interface 04:43:36 juberti: you pick your default interface, and then gather one v4 and v6 address. 04:43:58 present+ Eric_Rescorla, Nick_Doty 04:44:00 See also: Virtual Pwned Networks 04:44:01 https://www.usenix.org/system/files/conference/foci12/foci12-final8.pdf 04:44:29 juberti: if you connect to multiple well known addresses, this may pick different interfaces 04:45:03