16:36:44 RRSAgent has joined #webrtc 16:36:44 logging to http://www.w3.org/2014/05/21-webrtc-irc 16:36:46 RRSAgent, make logs world 16:36:46 Zakim has joined #webrtc 16:36:48 Zakim, this will be RTC 16:36:48 I do not see a conference matching that name scheduled within the next hour, trackbot 16:36:49 Meeting: Web Real-Time Communications Working Group Teleconference 16:36:49 Date: 21 May 2014 16:36:51 s/Teleconference/F2F/ 16:36:59 Chair: HTA, stefanh 16:37:11 Agenda: https://www.w3.org/2011/04/webrtc/wiki/May_19_-_May_21_2014 16:51:54 Cow_woC has joined #webrtc 16:52:01 Hi 16:52:22 Is this the right channel for this meeting? https://www.w3.org/wiki/May_19_2014 16:52:41 The page does not mention the channel name... 16:52:49 yes, it is. 16:53:07 hta: Harald? :) 17:01:06 jib has joined #webrtc 17:01:14 adam has joined #webrtc 17:02:34 burn has joined #webrtc 17:04:09 lgombos has joined #webrtc 17:04:21 Ted_ has joined #webrtc 17:06:11 haha 17:09:49 So "exact" means "keep min/max width and height the same and optionally add this constraint"? 17:15:12 Is anyone monitoring this IRC channel? 17:16:42 The #mediacap IRC channel is currently being used. 17:16:53 Thank you 17:28:04 jib has joined #webrtc 17:30:21 scribenick: jib 17:30:28 scribe: jib 17:32:09 Topic: Stats definitions 17:32:33 -> https://www.w3.org/2011/04/webrtc/wiki/images/a/a7/Stats_WebRTC_Washington_May_2014.pdf Harald's slides 17:32:36 q? 17:32:36 stefanh has joined #webrtc 17:32:56 gmandyam has joined #webrtc 17:34:11 Giri Mandyam joining as an observer from Qualcomm Innovation Center 17:34:52 lgombos has joined #webrtc 17:34:54 hta presenting 17:34:58 -> https://www.w3.org/2011/04/webrtc/wiki/Stats Stats development space 17:38:13 mt: Tim Terriberry pointed to a spec in the audio community quite some time ago that has a well defined volume definition 17:38:27 cullen: that is in the audio draft 17:38:38 cullen: we dont want the audio volume, we want a change in the audio volume 17:38:46 from Tim: My recommendation would be to follow EBU R128: . See specifically EBU Tech Doc 3344. 17:39:08 … you're just saying it is going up or down in a deterministic way across browsers. Its a hard problem 17:40:44 tuexen has joined #webrtc 17:40:51 Correct link is: http://tech.ebu.ch/loudness 17:40:53 hta: next: inter-object pointers 17:41:09 tuexen has joined #webrtc 17:42:12 mt: now that we have lots of objects in justin's proposal, why not use those instead of the internal stats objects by-id? 17:42:43 … getStats for my dohickey 17:43:02 justin: how do internal objects get referenced? 17:43:22 hta: then you loose ability to make snapshots 17:44:34 … I'm thinking about the case where you get stats from three different objects, and you make a computation between two sets a couple of seconds apart 17:44:50 … and that's why we have timestamps on stats objects 17:45:55 … going to the live object instead ot a stats object would be a complete change to the api. 17:46:30 Slide: Thorny stuff (2) 17:47:42 hta: a lot of what we're trying to monitor is not standardized 17:48:05 jesup: are getting good video? 17:48:11 yes 17:48:16 JonathanLennox has joined #webrtc 17:48:34 Slide: More work 17:48:48 Okay. Harald is using the local stand mic at the podium 17:49:06 justin: go back for a second: how is the video discriminator going to work? 17:49:10 Should he switch to a lapel mic? 17:49:23 hta: (some answer scribe missed) 17:50:21 hta: I want to take wiki page and publish it as a separate document 17:51:24 cullen: a lot of this needs to be in the base spec 17:52:07 dom: I suggest we use the reference scheme to achieve this 17:52:48 cullen: I suggest leave base stats in webrtc spec and further stats in new doc 17:52:52 hta: I don't like that 17:52:52 s/we use/we don't use/ 17:53:04 … I'd like to have one place for everything 17:53:16 rather have a baseline 1 and immediately work on a baseline 2 17:53:24 … would that work fo you? 17:53:35 cullen: yes if people must implement what is in the base spec 17:54:05 hta: next: do we have to represent 'component'? 17:55:40 mt: can I of push for stats for rtp transport would include rtcp stats? (best guess) 17:55:50 hta: problem with that , ip addresses 17:56:10 .. if ip is different for rtp rtcp then you need another place 17:56:35 mt: we decided we dont want the separate object, we wont make those ips available in stats, too bad 17:56:56 hta: in non-mux case we'll have a stats object, and btw here's a link to a separate object 17:57:15 uwe: not happy with not exposing it 17:57:34 … fine with separate transport object. but we should be able to access the information 17:57:46 justin: I think we'll be sad if we take a shortcut 17:57:54 .. why dont we have a separate stats object and point to it? 17:58:07 my: it will be exposed to the dom 17:58:09 s/my/mt/ 17:58:31 hta: rough consensus that stats should speak the truth: = two stats for two transports. will make a suggestion on the list 17:58:36 s/ough/rough/ 17:58:47 stefan: sounds good 17:58:54 .thanks harald 17:59:03 Next: Identity 17:59:11 Topic: Identity and security implications 18:00:00 Slide: requestIdentity 18:00:05 -> https://www.w3.org/wiki/images/2/2d/Martin-slides.pdf Martin's slides 18:00:54 mt: proposal remove this RTCConfiguration parameter 18:01:44 mt: solved 18:01:56 agreement to remove 18:02:07 Slide: Isolation Scope 18:03:35 mt: I suggest that any isolated track will cause peerconnection to negotiate isolation with all 18:04:06 .. if you have an isolated and a nonisolated track you want the remote to respect isolation for all tracks. - simplifies 18:05:04 richt has joined #webrtc 18:05:48 ???: how do I know ?? 18:05:56 mt: this is simplifying model 18:06:34 Slide: Problem 18:07:27 Slide: Option 1 18:08:00 mt: what do we do when it comes to negotiating sessions where eaither side have different expectations on isolation? 18:08:27 Slide: Advantages of Option 1 18:09:00 dan: is this right group? 18:09:07 mt: this is "what do we want?" 18:09:27 Slide: Option 2 18:10:06 ekr: if either side wants isolation you get isolatio? 18:10:06 mt: yes 18:10:17 … simplifies it 18:10:29 cullen: both doors have to be locked 18:11:03 hta: this means browser A that browser B is sending isolated tracks, but browser B can still run a JS plugin that does bad stuff 18:11:45 mt: cake is something, icing is knowing ?? We need something to say this media comes from x.com and no-one else. 18:12:22 Dini has joined #webrtc 18:12:24 dan: question: if in browser A I give permission to fluffy, what does it mean to isolate the media coming to me? 18:12:34 mt: isolation is lowering of access 18:12:40 …you can render this that's it 18:13:12 … when you pull it off the network wih a PC that is tagged as isolated, then you can render it and that's it 18:14:12 mt: isolated both ways 18:14:27 …identity is asymmetric 18:15:18 ???(ms): I'm receiving something browser A, I need to know it is coming from A, right? How do I do that? 18:15:43 mt: at the receiving side you know the source is the network, and the TLS connection was with isolation on or off. If on, youre on your way 18:16:47 dom: an isolated peerconnection creates a separate origin basically 18:17:11 m: web page doesn't have any say once its made this web page and supports this feature 18:17:19 s/m/mt/ 18:17:57 dan: authentication is something you go through when you log in, but there are a variety of ways to get isolation 18:18:19 mt: authentication is only required to get isolation through, or it goes nowhere 18:18:35 Slide: Isolation Timing 18:20:06 jonneth: if adding isolated tracks to PC , what happens if you have the model where you add a data channel, then I want to add isolatiod tracks. bundle. can I do that? 18:20:12 mt: then you cant 18:20:29 mt: solution: put a peerIdentity constriction on the peerConnection 18:20:55 jonneth: what does it apply to? just media? 18:21:17 what about stats? 18:21:33 ekr: maybe not give stats for isolated streams 18:21:43 stefan: what about a track in use becomes isolated? 18:22:07 mt: getUserMedia is not the only way to get a track. CaptureUntilEnded 18:22:33 .. say you're sourcing a video-tag from a website and you're using dash or some sort of streaming protocol, then recreate 18:23:08 … then the model forces cross-origin which means we have to respect that tracks may change their properties over time. 18:23:13 .. same for audio 18:23:34 … when we force cross-origin we have to stop sending 18:24:01 dan: how to configure? 18:24:06 Cow_woC has joined #webrtc 18:24:23 mt: when you provide peerIdentity:foo, it says don't allow session to complete without valid id assertion=foo 18:24:56 ekr: I suggest this first case, needs onnegotiationneeded 18:25:45 mt: adding a track should always cause onnegotiationneeded 18:25:55 ekr: I think always, but if not it should 18:26:31 mt: only concern if you're switching in and out with the aim of not renegotiation, we need to catch that for this isolation case 18:27:15 cullen: with onnegotationneeded, will it have to close and reopen the DTLS connection? 18:27:16 mt: yes 18:27:34 cullen: DTLS connection closes? 18:27:39 ekr: no, just like ICE restart 18:28:00 cullen: will we need the ELPN (sp?) value? 18:28:07 … lets not 18:28:19 mt: agree 18:28:25 …that's what I have 18:29:03 stefan: question related to schedule. we said last call for late september 18:29:14 mt: should be done well before then 18:29:55 jonneth: when it fails, is it silence forever or till onnegitiationneeded fires? black forever without me knowing about it would make me sad 18:30:05 mt: unavoidable 18:30:25 … till you get the callback 18:30:42 mt: but if track changes isolation state then it's harder but that is an edge case 18:31:06 .. we suggested we didn't need to know this earlier 18:32:20 dan: echoing jonneth. what if a naive developer finds themselves with things not working. Just trying to show them basic stuff. Nice to avoid things just failing. Necessary to solve this in real apps. The more failure modes we require renegotiation for then that's not great, how do we avoid that? 18:32:56 dom: suddenly it's black, then how does the model help understand this. 18:32:59 mt: error reporting 18:33:10 ekr: you can't get into this situation accidentally 18:33:26 ekr: it's a feature, if you use this feature you should handle it 18:33:49 dan: you were saying there were cases where you could get redirect, where you didn't cause it 18:34:09 ekr: (some example) 18:34:51 dom: about cameras: I dont want to send video Im watching. Say you're using an interactive canvas 18:35:13 mt: canvas wont render isolation 18:35:33 ekr: otherwise you could use canvas to bypass origin protection 18:37:43 ekr: going back to martins presentation yesterday: if you attempt to add a cross origin video to a PC that should generate some kind of error or warning or exception 18:38:21 dan: what about something that becomes cross-origin for an action you didn't take as a developer 18:38:26 ekr: that can't happen 18:38:30 mt: its always your fault 18:39:15 jonneth: question on that: if the other guy decides to go isolated, is that my fault? 18:39:24 mt: yes, you are the one writing the code in the browser 18:39:30 q? 18:40:35 mt: explore adding information on MediaStream? Sounds like some are arguing for that 18:40:57 … DOM object MediaStream would get a new attribute "you can't touch me" 18:41:16 dom: an 'Isolated' property 18:41:21 mt: and an event 18:41:47 tuexen has joined #webrtc 18:42:13 mt: most of these things are directly initiated by the JS 18:43:39 mt: and isolated:true/false and an onisolation event is enough 18:43:50 … in mediacapture spec 18:44:09 s/and/propose/ 18:45:10 mt: if you did a capture on a DRM mediastream, you would get a mediastream but all you could do was render to the screen 18:45:17 JonathanLennox: :) 18:45:36 dan: can you reconcile: gum obtained track can be isolated. 18:45:45 mt: tracks can change their isolated state at any time 18:46:13 dom: would be nice if you could know that it couldn't change 18:46:47 … if you know it comes from gUM you know it cant change and don't have to monitor the onisolatedchange 18:47:21 mt: if it comes from PC then it can change 18:47:52 … don't think we should assume the invariant that if it comes from gum then it can't change, but... 18:48:33 Action: mt Add some property on MediaStreamTrack for Isolated:true/false, and onisolatedchange event 18:48:33 Created ACTION-113 - Add some property on mediastreamtrack for isolated:true/false, and onisolatedchange event [on Martin Thomson - due 2014-05-28]. 18:49:11 ???: question: what about a mesh network? One wants isolation another don't? 18:49:23 cullen: don't think it'll be much of an issue since there are different PCs 18:49:46 richt has joined #webrtc 18:49:50 … lets same I'm in conference, if I send my media to you and then you send it on then there may be a problem, but not otherwise 18:50:13 mt: a transient property 18:50:30 cullen: if I had cloned the tracks then ... 18:50:57 mt: when you clone an unisolated track and then these clones, some can be isolated and others may not 18:51:51 ted: basic point is correct. Someone asking for isolated. this is a consequence of our model 18:52:14 mt: if you want isolation in a relay environment, the first guy is not going to be able to send it on 18:53:15 dom: in a mesh, if only one of the user is adding something to a nonauthorized source, does this change things for everyone? 18:54:01 …does the application need a way to control this odd usecase? 18:54:18 ted: can't send the kitten on 18:54:33 … you have to put it in a separate PC to not taint everything else 18:56:08 dom: my fear is that you're not trying to protect whats in the camera, it just happened that one of the users tried to do something, I as a developer how do I avoid sending black? 18:56:30 mt: how about a property on a stream "I'm now sending black"? 18:57:13 ???(ms): you mentioned changing track from isolated to nonisolated? 18:57:28 mt: app wont be able to change that, that's a case the browser controls 18:57:52 .. crazy internal stuff 18:58:13 … user says "I'm protecting this stream" can't change that 18:58:34 dan: you can't avoid being tainted. you don't know whether anything you get from a PC can get tainted down the road 18:58:58 .. that may cause everything else that you send to get tainted, and you must use a separate PC 18:59:16 … people who talk about ways to relay media may be tripped up by this 18:59:30 stefan: we have a lot to do 18:59:33 time for coffee 19:11:12 adam has joined #webrtc 19:18:16 scribenick: stefanh 19:18:36 Topic: interoperability 19:18:44 Alex going through slides 19:19:05 First: Data channel label uniqeuness 19:19:32 prop: update the spec to say do not have to be unique 19:20:44 ... need to sort field to large/long - 6553x bytes 19:21:55 justin: rtp data channel long gone 19:23:05 ....don't think that have a 6553x length is a problem in real world use 19:23:37 Randell: they should look up the limit 19:23:57 justin: we should cut at 65k and call it a day 19:24:14 Alex: how to know max size on sending 19:24:43 Justin: use the new w3c streams api is what I have heard people say 19:25:38 Alex: question is if we should add something to the API 19:25:50 kiran has joined #webrtc 19:26:12 justin: we should use streams api for the time being 19:26:34 alex: needs to use different stun/turn servers for ff and chrome 19:26:50 justin+ekr: should be fixed now, may be broken 19:26:52 https://plus.google.com/hangouts/_/google.com/41025012?hceid=aGFyZGllQGdvb2dsZS5jb20.ijvifsrjf0c7vqgbo2v9spilpo 19:27:16 Hi my connection got disconnected while discussing label uniqueness.. can some one please let me know what was discussed on this. 19:27:55 ekr to verify it is fixed 19:28:07 alex: next topic trickle ice 19:29:34 ...ice candidates not fired 19:30:01 ekr and adamr discussing 19:30:37 cullen: we cleared this up during this meeting - but need to make sure it gets documentet 19:30:50 s/documentet/documented/ 19:31:14 alex: noxt topic: mediaStream.stop() method 19:31:22 s/noxt/next/ 19:31:43 alex: users wanting a global stop method for a stream 19:32:04 justin: a stream is just a bunch of tracks - has no state 19:32:36 randell: people asking for this feature 19:32:40 kiran - archive of the irc channel is at http://www.w3.org/2014/05/21-webrtc-irc 19:33:32 danb: we could add something back in for convenience 19:33:57 tuexen has joined #webrtc 19:36:25 ....some more discussion 19:36:45 hta: data channels should not be treated as tracks 19:37:14 cullen: we should add a method to get all tracks to stream 19:37:27 ...as well as get all tracks of a certain type 19:39:13 alex showing slide on implementation status 19:40:04 ekr disagreeing 19:41:11 randell: I have video forwarding work in ff at one stage 19:41:59 ...full browser ec now active 19:43:45 thanks alex 19:43:57 next summary and conclusion 19:44:53 for media cap: we're getting close (to lc) 19:45:14 ...solution emerging for constraints 19:45:43 for weeebrtc: a couple of big items: doohickeys and isolation in all its forms 19:46:24 ...most seem resonably settled, but we will discover bugs down the road 19:46:40 ....we're fairly happy, the meeting has been useful 19:47:07 we at w3c are worried about the progress at ietf side so we will chase people 19:48:05 back to media capture: we have the understandings from this meeting and the bug resolutions to integrate, but I see a lc glimmering in the distance (June?) 19:48:46 what could we have done better? 19:49:05 giri: bunch of bugs filed after hta did his presentation 19:49:27 whats the plan when it comes to dealing this (given next f2f is tpac)? 19:49:49 hta: main tool: mail, but we will call for teleconferences 19:50:16 ....will try to solve the nit-type bugs asap 19:51:29 mt: would be good if someone could go through the bugs and see what bugs that have no proposed solution or plan to solve 19:52:12 hta: the list is under development, but we need to assign them to people 19:52:22 justin: how much work remains? 19:52:36 hta: for media cap we're close in terms of weeks 19:52:55 ...for webrtc we don't know yet - we're not at that stage yet 19:53:17 ...hope to be there before summer's ietf meeting? 19:53:32 cullen: should we focus on gUM and on webrtc? 19:53:51 justin: if we could finsih one would be better than two unfinished ones 19:54:03 bernard: agree 19:54:22 justin: what needs to happen on in/out discussion 19:55:12 hta: what i've been hearing: simulcast is out, doohickeys in, what is in the spec is in 19:55:51 bernard: should finish what we have - can do more than we think 19:55:58 ...with what we have 19:56:51 danb: constraints need more spec, need to spec what ideal really means 19:57:13 ...to avoid misunderstandings 19:58:07 ...need an assignee 19:59:31 justin: a lot of things that are not in the spec 19:59:59 ...we should agree on them being out (rehydration, screen sharing, simulcast, rollback....) 20:00:24 ...would like to understand what is out of 1.0 20:00:35 ...to get total view of things 20:02:05 hta: we have work to do, see you next time 20:02:43 (may have a gettoghether before tpac) 20:03:35 over and out 20:03:59 JonathanLennox has left #webrtc 21:35:34 richt has joined #webrtc 21:40:22 richt_ has joined #webrtc 22:25:44 richt has joined #webrtc 22:30:18 jib has joined #webrtc 22:34:43 richt has joined #webrtc 22:35:15 richt has joined #webrtc 22:56:42 jib has joined #webrtc 23:02:38 jib_ has joined #webrtc 23:35:57 richt has joined #webrtc 23:48:56 jib has joined #webrtc 23:57:32 lgombos has joined #webrtc