07:11:42 RRSAgent has joined #webrtc 07:11:42 logging to http://www.w3.org/2012/06/11-webrtc-irc 07:12:19 http://plus.google.com/hangouts/_/google.com/webrtc 07:12:34 that should work for non-google.com users 07:12:43 martin has joined #webrtc 07:13:28 yes, but there's nobody in that hangout. 07:13:51 RRSAgent, draft minutes 07:13:51 I have made the request to generate http://www.w3.org/2012/06/11-webrtc-minutes.html dom 07:15:27 trackbot, start meeting 07:15:34 RRSAgent, make logs world 07:15:36 Zakim, this will be RTC 07:15:37 Meeting: Web Real-Time Communications Working Group Teleconference 07:15:37 Date: 11 June 2012 07:15:47 Agenda: http://www.w3.org/2011/04/webrtc/wiki/June_11_2012#Agenda 07:16:00 Meeting: Web Real-Time Communications Working Group F2F 07:16:44 Chair: Harald_Alvestrand, Stefan_Hakansson 07:20:09 Present: Harald_Alvestrand, Stefan_Hakansson, Magnus_Westerlund, Ted_Hardie, Tim_Terriberry , Anant_Narayanan, Dan_Burnett, Dan_Druta, Dominique_Hazael-Massieux, Cullen_Jennings (remote), Justin_Uberti (remote), Adam_Bergkvist, Jim_Barnett 07:20:42 https://cisco.webex.com/cisco/e.php?AT=WMI&EventID=195618382&PW=eeaef7985d44&RT=MiMxMzA%3D 07:20:54 (there are more people in the room, but I can't identify them visually; if you know any of the missing names, please type "Present+ Name") 07:23:03 I have a cable, magnus 07:23:36 Present+ Neil_Stratford (remote) 07:23:42 Present+ Stephan_Wenger 07:23:52 Present + Gang_Liang(remote) 07:23:58 Present+ Salatore Loreto (remote) 07:25:54 Present+ Jonathan_Lennox 07:26:10 Present+ EKR_(remote) 07:26:10 Present+ Randell_Jesup 07:26:20 Present+ Maire_Reavy 07:27:20 s/Jesup/Jesup_(remote)/ 07:27:30 s/Reavy/Reavy_(remote)/ 07:28:03 Present+ Mary_Barnes 07:29:30 juberti: joining the hangout via that URL always says "you are the first one to join" 07:29:38 -> http://www.w3.org/2011/04/webrtc/wiki/File:WebRTC_interim-june-2012_PeerConnection_API.pdf JSEPified PeerConnection API (slides) 07:29:49 s/juberti:/juberti,/ 07:30:33 DanRomascanu has joined #webrtc 07:30:34 Scribe: anant 07:31:29 -> http://www.w3.org/2011/04/webrtc/track/actions/open WebRTC open action items 07:31:34 ACTION-11? 07:31:34 ACTION-11 -- Daniel Burnett to add Constraints API to API spec -- due 2012-01-12 -- OPEN 07:31:34 http://www.w3.org/2011/04/webrtc/track/actions/11 07:31:38 Welcome to the W3C interim! Coffee at 10:30, lunch at 12:30 CET 07:31:50 Administrivia, going through action items 07:32:07 stefanh_: Action 11 is ongoing, more to be discussed today 07:32:07 ACTION-12? 07:32:12 ACTION-12 -- Daniel Burnett to add Stats API to API spec -- due 2012-01-20 -- OPEN 07:32:12 http://www.w3.org/2011/04/webrtc/track/actions/12 07:32:12 stefanh_: ACTION 12 07:32:27 Present+ Gonzalo_Camarillo 07:32:31 Mauro has joined #webrtc 07:32:35 ACTION-12: Harald's proposal http://lists.w3.org/Archives/Public/public-webrtc/2012Jun/0040.html 07:32:40 ACTION-12 Add Stats API to API spec notes added 07:32:45 harald: I put some comments, feedback welcome 07:32:52 I'm not sure that the mic is working 07:33:17 burn: capabilities was discussed in terms of the constraints. there needs to be a quick check on the list before we can put it in 07:33:56 dom: I agree. there is the sysapps WG whose one of the charter items is to define how web applications should be given access to privileged APIs 07:34:20 burn: it would be good to look at that group. I want to make sure we don't wait on a model from that group before being able to put capabilities in our document 07:34:27 ACTION-16? 07:34:32 ACTION-16 -- Eric Rescorla to propose how to tie into identity frameworks for comms partner verification -- due 2012-01-12 -- OPEN 07:34:32 http://www.w3.org/2011/04/webrtc/track/actions/16 07:34:38 stefanh_: next action, putting identity information 07:34:54 ekr: I am a little behind on that, working on it now. I can have that by 2 weeks or so 07:35:01 JonLennox has joined #webrtc 07:35:01 ACTION-16 due June 25 07:35:06 ACTION-16 Propose how to tie into identity frameworks for comms partner verification due date now June 25 07:35:17 stefanh_: next action (21), belongs to the media capture task force. to draft initial requirements 07:35:30 stefanh_" propose to not discuss it further here 07:35:43 fluffy: I had a question about that, what is the plan here? 07:36:00 stefanh_: the plan is to move it from this tracker and opened into the mediacap tracker 07:36:02 s/21/25 07:36:06 ACTION-29? 07:36:06 ACTION-29 -- Cullen Jennings to change all numeric constants to be enumerated strings -- due 2012-06-15 -- OPEN 07:36:06 http://www.w3.org/2011/04/webrtc/track/actions/29 07:36:35 fluffy: largely we've taken the first stab at moving most of the stuff, but we're still waiting for the respec2 move 07:36:53 action 39: repsec2 move 07:36:53 Sorry, couldn't find user - 39 07:37:14 burn: there is no need to move respec2. dom made changes to the gUM doc, but we can do the same changes to the webrtc doc 07:37:24 burn: respec 3 = respec 2 + extra module 07:37:24 ACTION-29: mostly done, waiting for new respec version 07:37:24 ACTION-29 Change all numeric constants to be enumerated strings notes added 07:38:03 +1 on moving WebRTC to respec v3 07:38:05 burn: it worked well with gUM, so it's worth trying with the webrtc document 07:38:28 stefanh_: action 42 is also mediacap 07:39:18 stefanh_: shall we move on to the next part of the agenda? JSEPified PeerConnection API 07:39:24 adambe has slides on the discussion 07:39:40 -> http://www.w3.org/2011/04/webrtc/wiki/File:WebRTC_interim-june-2012_PeerConnection_API.pdf JSEPified PeerConnection API (slides) 07:40:42 adambe: slides about our current PeerConnection API, I didn't really know in what form to do this. start with a simple example 07:41:03 i/adambe:/Topic: JSEP in PeerConnection/ 07:41:42 adambe: the code in the example has never been run, so there could be issues. but here's my view of how this API could work right now 07:42:04 as few lines as possible, the straightest line possible between a two-way audio/video call 07:42:38 the overview shows each step in the process 07:42:50 subsequent slides will go in detail for each part 07:43:49 Spencer has joined #webrtc 07:44:16 who you are calling is left to the web application. variable signalingChannel is a way to send data to the other side (somehow) 07:44:53 create a peerconnection, a way to handle ice candidates as they come in, use signalingChannel to send the candidate from the event over to the other side 07:45:26 handler for handling what happens when you get a stream from the other side. in this case, we simply show the video in a video element 07:45:32 (as far as I can tell, the current editors draft doesn't allow "null" for the IceServers configuration param in PeerConnection param) 07:45:58 part2: use getUserMedia to get access to the local media and create an offer or answer (based on role) 07:47:31 part3: handling incoming messages sent through the signalingChannel. three types of messages: "offer", "answer" and "candidate" 07:47:57 nstratford has joined #webrtc 07:48:14 anant: what is the SessionDescription constructor? 07:48:33 adambe: that's how it is in the spec right now, it converts the string to an object 07:49:55 anant: we can't add "SessionDescription" as a global object; we could either make it a sub-interface of PeerConnection, or avoid a constructor altogether by using a string 07:50:37 I'm not sure that th mix in front of anat is working 07:50:42 mic 07:50:44 it was ealeir but seems to be off now 07:51:57 adambe: we have a constructor to go one way, and stringifier to go another wa 07:52:09 the object is the place to add those, and it's the placeholder 07:52:51 Would it be possible for someone to relay slide numbers into the chat for those of us trying to follow along without video or slides in webex? 07:53:32 harald switched to the right slide in hang-out 07:53:33 this is the last slide 07:54:56 dom: I don't know if there's another WebAPI that does that 07:55:15 harald: get it out of the global namespace as an action item, and we can do the specific proposal 07:55:25 adambe to consult with dom and make a proposal 07:55:45 ACTION: adam to move SessionDescription and IceCandidate out of the global namespace 07:55:49 PeerConnectionSessionDescription 07:55:50 Created ACTION-43 - Move SessionDescription and IceCandidate out of the global namespace [on Adam Bergkvist - due 2012-06-18]. 07:56:18 juberti, I think the idea was more to have PeerConnection.createSessionDescription() or something 07:56:28 Magnus has joined #webrtc 07:56:52 adambe: let's see what happens when someone calls. the start method takes a boolean in this example (true for outgoing, false for incoming) 07:59:34 anant: on the receiving side, you're calling navigator.getUserMedia, and then createAnswer, without having received the offer 07:59:52 adambe: the caller side has called start(true); the callee side hasn't done anything yet 08:00:46 q+ ekr 08:01:32 q+ 08:01:57 can't hear ekr 08:01:58 ekr, please unmute 08:02:15 cullen problem 08:03:13 If this helps at all, I have a bit of a call flow at 08:03:14 https://github.com/fluffy/webrtc-w3c/raw/master/call-simple.png 08:03:20 it has some known problems 08:03:28 ekr: what is the sequence of events on the answerer side? 08:03:49 juberti: [answering, but not audibly] 08:04:24 fluffy: I suspect this hasn't been carefully thought about 08:04:32 fluffy: originally we didn't have the split and we didn't have setRemoteDescription 08:04:50 juberti: do we still need pc.remotedescription as an argument to createAnswer? 08:05:09 fluffy: what will drive this requirement is a rollback on update, but so far we don't have call flows that require this 08:05:51 adambe: you do addstream, and when you call createAnswer, you use the added stream on the pc as the source of information, and then you pass a separate offer as another input 08:06:17 adambe: it might make better sense to get both added streams and remote description from the pc 08:06:19 My general ask to the authors is that they need to provide a definitive answer to every such questoin. 08:06:36 harald: the difference I remember is that with createAnswer(arg) you have not committed to accept from the other side 08:06:47 There is a potential bug in the example code if the browser calls the getUserMedia callback inline because the remote description wont have been set when that happens. 08:06:49 i.e. no guarantee to call setRemote after createAnswer 08:07:04 ekr: I'd like to hear definitely whether or not I should call setRemoteDescr... 08:07:09 juberti: you don't right now 08:07:34 fluffy: this is clearly an issue where I haven't heard strong arguments one way or another. but obviously need to be defined 08:07:39 lots of different alternatives 08:08:15 if people have a preference for one or the other it would be great to hear 08:08:42 ekr: one of the things I need to do is to introspect the offer. is one of the ways I do this is via setRemote that's fine, but we want to try and limit side effect to calling setRemote 08:08:59 Do people hear Justin & EKR OK ? 08:09:05 Yeah 08:09:06 juberti: my expectation is that it doesn't really have a lot of side effects. unless there's both local & remote description nothing will happen 08:09:08 fluffy: yeah 08:09:58 juberti: why would we not automatically generate an answer when calling setRemoteDescr…? the answer lies is some outlying cases where there might be modifications required. but if we are always passing in the same description, then we should. 08:10:09 action on juberti & cullen to deep dive on the possibilities here 08:10:09 Sorry, couldn't find user - on 08:11:04 ACTION: juberti to deep dive on setRemoteDescription with cullen 08:11:04 Sorry, couldn't find user - juberti 08:11:10 ACTION: justin to deep dive on setRemoteDescription with cullen 08:11:10 Sorry, couldn't find user - justin 08:11:38 ACTION: cullen to deep dive on setRemoteDescription with justin 08:11:39 fluffy: what happens when you call setRemote? are any added stream callbacks called? 08:11:43 Created ACTION-44 - Deep dive on setRemoteDescription with justin [on Cullen Jennings - due 2012-06-18]. 08:11:55 juberti: the stream stuff is pretty clear, when setRemote is called, it triggers the callback 08:12:23 fluffy: we might need two different callback. onstreamproposed/onstreamaccetped? 08:12:49 harald: is it even meaningful to reject a stream? if the other end is sending me a stream, I can either take the data, or cause the data to not be sent 08:13:06 ekr: I don't reject the idea, but the spec talks quite a bit about what happens when a stream is permanently dead 08:13:41 ekr: when I get told there's a stream on the other side, I can either accept, get media, or I've been told there is no more media 08:13:58 stefanh_: but you do hear about all this stuff. you get events on the stream 08:14:19 ekr: what about the event where I get a video with h.264 but I constraint to only vp8 via setLocal 08:14:54 juberti: you plugged in setRemote, got streams with audio/video. I don't know if you have track event, but you get stream event, you would then listen for onended, and these things are not negotiated 08:15:00 ekr: conversely, when you accept, what happens? 08:15:09 juberti: we talked about having an event where media start arriving 08:15:21 stefanh_: you get an unmuted for incoming data 08:16:01 ekr: what's the UI? in incoming call request, want to display audio/video, open a screen big enough, but don't want to do it until we know we can display it. but also before media actually arrives 08:16:36 harald: tentatively, I think, when you get media stream (onstreamadded), and then you get media track events saying that the stream has ended because it cannot be delivered 08:17:05 fluffy: using muted is bogus, because the other side may actually be muted so there's no data 08:17:31 ekr: I tend to agree with cullen, but I can be convinced that it can be made to work 08:18:11 juberti: we need to know one way or another if the negotiation completed or not 08:18:56 ekr: that may imply the main thread has to block until the negotiation finished? 08:19:00 so we'll need another event 08:19:11 fluffy: so we'll add another event 08:19:17 juberti: we need a state machine for streams 08:19:26 harald++ 08:19:29 yang has joined #webrtc 08:19:48 harald: we need a state machine for streams and a state machine for tracks. audio track will be perfectly fine if we can't agree on the video codec. 08:20:06 fluffy: the per track state. do you want us to do that as an extension of the tracks in this document or in the gUM document? 08:20:36 dom: I think it belong in webrtc document 08:20:59 harald: we have to have a state machine in the gUM document, but extend with more event and state in this document 08:21:06 first we should figure out what events and states are 08:21:18 fluffy: the high level use case is to see if negotiation failed or suceeded 08:21:34 juberti: media arriving and muting should all be explicit 08:22:07 adambe: as in the spec right now, things are very fluffy "when a stream has enough information to know it succeeded it should unmute" 08:22:48 adambe: addtrack event is after setRemoteDescr… is called. is that really a stream in that case? it's something to be negotiated. I think we should have a mediastream only when the negotiation has completed 08:23:22 fluffy: this ia an alternative approach, but we can make it work. there are some corner cases that we need to handle 08:23:35 fluffy: I think we can deal through all those issues. 08:23:54 fluffy: in the media stream's object it won't be in the video or audio track list (for smellivision) 08:24:28 ekr: what's going to happen when we add non video/audio tracks to streams? 08:24:49 partial interface MediaStream { attribute Smell smelltracks; } 08:25:12 fluffy: does it buy you anything to have separate "tracks" attribute? and not just video/audio track sets 08:25:21 stefanh_: it was to align with the media elements spec 08:25:43 fluffy: a track should tell you what the type is 08:26:16 harald: we discussed it a lot, and there was no case where it was simpler to have one set of tracks than 2 sets of tracks. I don't want to reopen that discussion 08:26:36 harald: ekr I think that if you want to have a dictionary instead of attributes, throw yourself at it 08:26:50 var audiotracks = alltracks.filter(function(x) { return x.type === 'audio'; }) 08:27:21 +1 to harald 08:27:32 +1 to harald 08:27:37 harald: I think it is actually extensible enough that we can add later when we need them, but adding earlier than needing them is not pleasant 08:27:56 ekr: I'm not suggesting that we add them right now, as a programmer it's not ideal to have things named like this 08:28:23 I usually argue that the valid number of objects is: 0, 1, and infinite 08:28:26 audiotracks = pc.tracks("audio") 08:28:44 juberti++ 08:29:14 jim barnett: we need a JS API to introspect the offer, and you don't get a stream object until you accept 08:29:54 Present+ Richard_Ejzak 08:30:06 richard: you still need a way for the browser of responding to an offer based on what it's capabilities are. my interpretation is that createAnswer is the way to do that 08:30:40 the question is, if there is enough information to the JS for it to know if it can accept the answer or not. there's a little bit of a chicken and egg there 08:31:22 there is a problem with the haptic track 08:31:23 ekr, I wouldn't mind too much if we defined tracks as tracks { audio[], video[] } rather than audiotracks[], videotracks[]. That's what I was driving at with "dictionary". 08:31:34 hta: that would be preferable to me. 08:31:43 + 08:31:50 how do we make it so 08:32:05 that works for me too 08:32:19 ekr, type up the IDL you want and send it in. 08:32:25 Willdo. 08:32:38 s/hta:/hta,/ 08:32:52 timpanton has joined #webrtc 08:33:19 ekr, fluffy: we cannot hear you 08:33:42 sorry 08:33:58 We were discussing how awesome this AV technology is 08:34:54 adambe: we can discuss this issue separately later 08:36:30 ACTION-44: Adam can help with when streams should be dispatched 08:36:35 ACTION-44 Deep dive on setRemoteDescription with justin notes added 08:36:42 time for coffee! 15 minute break 08:39:17 Hangouts still doesn't work for many of us - please don't turon off WebEx! 08:58:52 anant__ has joined #webrtc 08:59:16 adambe: continuing example slide 09:00:34 after setRemoteDescription is called, on the callee side, getUserMedia is called to select a local source 09:01:10 if we're lucky, media will start flowing and the streams can been displayed 09:01:56 ekr: there are a lot of events been thrown out of this API. only the ICE event fire in the example, what about the others? 09:02:22 adambe: there's a subsequent slide that discusses the ICE events 09:02:40 ekr: but there's also PeerConnection events. it's unclear to me when all these events fire 09:03:09 (and do we need all these events?) 09:03:24 adambe: I don't think it's clear when some of these events fire 09:03:38 ekr: I can go in and enumerate when I think these events fire, do people want that? 09:03:47 ekr: perhaps you could mark up the sample i wrote up with the event times? https://docs.google.com/document/d/1L3lMBINuLn2S7EO4APWTUaPcUMV0Ke1q2zCzZaYYba8/edit 09:03:51 fluffy: proposal, why don't ekr and I take as an action item to annotate when the events fire 09:04:02 ekr has joined #webrtc 09:04:26 fluffy: sometimes ICE is per track and other times it's for the peerconnection, deliberately not cleared up in the spec yet 09:04:29 ACTION: cullen to annotate the callflow diagram with events fired 09:04:29 Created ACTION-45 - Annotate the callflow diagram with events fired [on Cullen Jennings - due 2012-06-18]. 09:04:34 ekr: https://docs.google.com/document/d/1L3lMBINuLn2S7EO4APWTUaPcUMV0Ke1q2zCzZaYYba8/edit 09:04:41 s/ekr:/ekr,/ 09:04:56 juberti: thanks 09:05:22 adambe: regarding events and examples, most of the events, we don't really need 09:05:41 Tech note: I'm having someone look closely at the hangout. Could those who try to join post the email addresses here? 09:06:02 fluffy: it's true you don't need them, but the customer for the spec is the browser implementers who need to know when to generate them 09:06:08 hta: anant@mozilla.com (for hangout) 09:06:23 adambe: I have suggested some discussion topics 09:06:43 adambe: how to tell we have enough candidates? in the trickle case 09:07:48 nacl... awesome 09:08:33 adambe: do we need to talk about that before we decide what the events are associated with? 09:08:53 juberti: the "null" event may have independently of a candidate 09:09:03 fluffy: in nearly every I think that is the case 09:09:29 ekr: it is passing effectively a domstring to the interface for each candidate, then null may be okay, but for JSON, what would you do 09:09:50 juberti: if some ICE candidate is an object, then this would have the m-line for SDP 09:10:02 and real objects can be null in the DOM 09:10:28 ekr: there are fast path lines, there is the case where I have two interfaces but can't write to one of them 09:11:07 harald needs to use a mic 09:11:31 harald: for the implementation, we faked it by just doing a timeout. the browser should not decide when it's enough that we got all the candidates 09:12:08 either we define what's enough, or we leave it to the application 09:12:13 ekr: but the browser does know! 09:12:33 fluffy: I think harald makes a good point, enough is not the right thing here, the question is when is ICE done? there are no more candidates 09:12:54 ekr: the technical state in which every candidate fails or succeeds, happens about 40 seconds later... 09:12:58 fluffy: that's the event we are talking about 09:13:39 juberti: the application needs to either have its own timeout, but if it gets told if I have everything ahead of that, I'm not going to wait that long 09:13:56 fluffy: so we need an event that does this ICE session is done 09:15:20 ekr: the relevant event here is: I have now received STUN answers or given up on every possible candidate. min time: 0, max time: ~40-60 seconds after 09:15:41 The max time depends on your rtt estimate to your stun/turn server, doesn't it? 09:15:45 adambe: so we need something in between 1 candidate and 40 seconds later. 09:15:56 ekr: how would you tell the browser this 09:16:19 I would set a timer at the beginning for roughly at 4-5 seconds, and timer or callback firing would send out the offer 09:17:06 juberti: I think it should be really short, if it takes more than 5 seconds for a candidate, you probably don't want to use that candidate 09:17:25 I think the action here should be that we define what happens when the browser wishes to indicate that it it is not expecting any more candidates to be produced - at that point it will indicate it by doing the following ? 09:17:33 ekr: one thing it might be relevant here, would it make sense for the application to control 09:20:23 ekr: there are only two relevant events, I got 1 candidate, or I'm done. 09:20:46 juberti: anything in between is hard to specify 09:20:59 if you using trickle candidates, that will always work better than timeouts 09:21:40 fluffy: so null or events? 09:22:13 fluffy: it seems to me that the code you want to write is different in the case where you get a real candidate than when you get this event, you might want two different callbacks 09:23:04 juberti: there's gathering, connecting.. there's really not any linear state progression in ICE. you can't get away from an explicit callback 09:23:40 I think there are separate state machines for gathering and connecting 09:24:08 adambe: to sum up, people seem to agree that there should be some information on the candidates so the app can decide when to send something off. is the 40 second event useful to anyone? 09:24:29 JonLennox, I agree 09:24:41 the new issue is whether there are different state machines for the multiple different flows that might be created 09:25:13 juberti: the last event is when the browser has finished ICE and it's got all the candidates that is can get 09:25:17 fluffy: that often happens in <50ms 09:25:21 so we definitely need that event 09:25:42 juberti: the middle event is not needed when you use trickle candidates, and it's essentially a timeout 09:26:07 jonathan: one issue where the 40second timeout is potentially interesting, trying to connect and nothing is working 09:26:22 at the NULL you can switch from pinwheel to failure message 09:26:41 juberti: that makes even more argument for the "now I think it's a good time callback" 09:26:58 stefanh_: I have a problem with this in-between event because it depends on the other side 09:27:41 adambe: so theres an event for every candidate, and one final event 09:29:07 You can always try the host candidates — you never know, they might work. 09:29:25 and there are always host candidates 09:29:56 stefanh_: resolution is: there will be 1 event for each candidate, and one event for "no more candidates". 09:29:56 PROPOSED RESOLUTION: there will two kind of events: one for each candidate (to allow trickling), one when the browser has exhausted all possibilities 09:30:18 the middle event is left up to the application 09:30:23 RESOLUTION: there will two kind of events: one for each candidate (to allow trickling), one when the browser has exhausted all possibilities 09:30:27 adambe: next topic is the renegotiation event 09:31:26 [Shouldn't we make PeerConnection derive from EventTarget, to make it possible to use addEventListener/removeEventListener in addition to on... functions?] 09:31:32 the idea here is to have a callback or an event that would help the developer to know when to actually create a new offer on answer 09:31:39 +1 dom 09:32:04 ekr: I don't know if this is needed, but I have a question, but will this be fired whenever addstream is called? 09:32:12 fluffy: yes, that's the current thinking 09:32:47 adambe: the name should probably be negotiationneeded instead of renogotiationneeded since it can happen the first time too. 09:33:01 ekr: so if I add two streams, I get two of these callbacks? 09:33:12 juberti: the callback only fires when it's actually needed 09:33:58 adambe: this is quite a big topic, I don't know if we have enough to discuss it here. should the callback be triggered or not depending on the state... 09:34:33 ekr: this is problematic in the naive implementation of gUM that is calls onaddstreams when it responds. now I call gUM twice if the negotiationadded is called twice 09:34:52 juberti: only setLocalDescription changes the state, so calling createOffer without setting it won't call it 09:35:33 adambe: if you do two addstreams in the same event loop iteration, it should only result in 1 event 09:35:59 Martin_: but this would be in the gUM callback which almost certainly isn't in the same event loop iteration 09:36:34 ekr: but what happens when I get this callback when I'm still waiting for createOffer to return?! 09:36:43 adambe: perhaps we need more call flows & examples before we can dig into this 09:37:18 stefanh_: we're only discussing here for tracks or streams, does this also happen when hardware is removed/added, or there is a browser-level mute? 09:37:27 Executive summary: I'm worried about race conditions. 09:37:42 but we haven't decided which way to do these, and lot of other things to consider 09:38:19 ekr: i'm not against this functionality just that it's defined in a way that doesn't result in problems 09:38:37 juberti: this call flow seems to make sense to developers on webrtc-discuss 09:39:30 adambe: to make the API easy to use, this is important, but it's not crucial for the functionality 09:40:08 ???: do you have a any notion of replacing a stream or changing the characteristics? it introduces nasty issues 09:40:31 it's not unheard of to replace a m=audio line with another completely different line 09:40:34 Speaker is Paul Kyzivat 09:40:46 s/???/Paul_Kyzivat:/ 09:40:59 you have to keep both streams live and then decide which one to keep after a while 09:41:25 the question is: the model you're talking about, maybe it's not rich enough to handle those cases? what do you do to your stream to change a codec? 09:42:19 anant or dom, can you try joining the hangout again? 09:43:29 ekr has joined #webrtc 09:43:29 burn: as far as constraints are defined now, the browser can change the stream midway as long as it satisfies the constraints, even if it need a codec change 09:43:56 the "first one here" is another bug... 09:44:34 fluffy: one use case is when the browser switching to a narrow/wideband 09:45:19 richard: if we just look at need to renegotiate in SDP, I don't think we want to support changing the media type for an m-line, in WebRTC. it would be OK for us to say once you've defined characteristics with a media line then make it be immutable 09:45:38 port => 0, or a=inactive 09:46:56 richard: if you need to renegotiate in order to add a new media line, you also want to list all codecs that are present in other lines, when creating an offer you want a list of all capabilities 09:47:19 juberti: in some cases you do, in some cases you don't. in the JSEP draft I say the cases where you'd need a full offer 09:47:34 but for some cases where you are only adding one track you don't need the full offer 09:47:46 richard: doesn't the application need to be able to define that/ 09:48:24 ???: does this renegotiation happen, for instance, when direction of an m-line is changed? 09:48:35 Tech interrupt: It seems we can get people into the hangout, but we need to invite them explicitly by email address, and only some people manage to invite them. Ping me if needed. 09:48:36 juberti: the only way to change the direction is via client setLocalDescription 09:48:42 s/???/Andrew Hutton/ 09:49:21 juberti: the whole idea is that when you get this negotiation callback, the developer creates an offer and ships it off 09:49:42 stefanh_: I would like to conclude this discussion… we are moving into IETF territory 09:50:08 the consensus seems to be that we need this callback, but editors need to define in what cases 09:50:45 adambe: other topics: constraints that we can add, new global object IceServers, createProvisionalAnswers, ICE restart 09:51:41 adambe: when we get a stream, how many places in the API can I have an effect on the workings of the system? what are the possibilities of introducing conflicting constraints 09:52:02 if we count tweaking sdp from string and back to object, we have 5 places, and it feels like a lot of places where we can tweak 09:52:37 juberti: 1, 2, 3, 4 are all needed, and 4 and 5 seem the same to me 09:53:19 ekr: is there a 4 in the spec? do we need it? 09:54:04 sdp.tweakOffer = function(f) { this = f(this); } 09:54:32 juberti: there will always be cases where we won't provide what the application wants (and they have to do it by hand), but for streams and gUM they are seperate. 09:55:37 adambe: I agree that the intention is to modify separate things, but we have to be careful that we don't introduce conflicting constraints 09:56:11 the reason or adding #4 is that, we should provide APIs to tweak the SDP 09:56:39 my brain seems to be failing: where is the constraints algorithm currently defined? 09:56:45 fluffy: I agree no-one should parse the SDP on their own, but I'm hoping that constraints will cover all the things we need to do 09:56:51 ekr, in getUserMedia 09:57:20 ekr, http://dev.w3.org/2011/webrtc/editor/getusermedia.html#methods-3 more specifically 09:58:21 ekr: I'm less concerned about 1vs2 than I am about 2vs3 09:58:43 stefanh: wouldn't it be confusing if one constraint in getUserMedia could also be set/overriden in addStream? 09:59:22 oh, I see, it's just not where I expected. Thanks 10:00:21 juberti: we need to have a clear indication about what constraints go into which API calls. you can't pass ICE restart into gUM 10:01:01 (I think this means the constraints registry should make which constraint for which context abundantly clear) 10:01:34 juberti: there's a 2nd parameter to the constructor where you put ICE constraints 10:02:00 fluffy: some are perfectly willing to put relays for audio, but not putting video. constraints will be different for two different cases 10:02:29 fluffy: let's do an easy one like aspect ratio. If I set aspect ratio in #1, will that be remembered, or do I call it everytime? 10:02:46 Markus has joined #webrtc 10:03:08 juberti: 1 gets carried over to 2; but if I add the stream to two different streams, then I can override 10:03:51 correction: 5 doesn't exist 10:03:51 harald: this particular point illustrates that setting constraints have to fade at some point, because in the current setup it is easy to define conflicting constraints 10:04:08 ekr: 5 exists, 4 doesn't 10:04:17 oh, you're right 10:04:35 Ted has got the video reflected into webex for the folks on webex 10:04:59 burn: I think that there will be subtle differences in interpretations of constraints in the different cases unless we define the context 10:05:06 dom: does the registry have a context? 10:05:15 burn: currently doesn't but we can add it once we know what we want 10:05:31 s/have a context/ask for context for constraints/ 10:06:16 adambe: for ICEServers, we have two suggestions: list of string, list of list of strings 10:06:18 DiMartini has joined #webrtc 10:06:19 so, I think we still didn't work out the merge algorithm 10:06:24 dom: first easy change is to make it a dictionary 10:06:28 OR when it's needed. 10:06:30 we can't hear whoever that was 10:06:33 adambe: I think you're right 10:06:39 CAn the chairs keep this issue open? 10:07:09 it will be kept open 10:07:18 stefanh_: thanks 10:07:46 (the actual syntax would be "DOMString[] servers", not "DOMString servers[]") 10:10:06 Mauro has joined #webrtc 10:12:17 adambe: do we have any requirements of different ICE constraints on different servers 10:12:59 harald: that might make sense 10:13:57 can someone explain how SRV interacts with this while you are at it? 10:14:21 action anant: write up a spec for IceServer object, and compare 10:14:26 Created ACTION-46 - Write up a spec for IceServer object, and compare [on Anant Narayanan - due 2012-06-18]. 10:14:32 dom: in your example, PeerConnection has null as the value, the draft doesn't allow null. 10:14:45 anant: I think we should allow null and the browser should have defaults. 10:15:06 adambe: for createAnswer, do we need the offer argument or can it automatically grab it from the pc? 10:15:09 Martin_, I'd think that'd be defined by the STUN/TURN URI definition? 10:15:12 (on top of make it nullable, we should also make it optional then) 10:16:32 fluffy: no-one could come any reason for why we couldn't remove the argument 10:18:29 JonLennox, it's pretty vague in the STUN URI draft 10:18:30 ACTION: Anant to provide a code example showing continuation for createAnswer 10:18:31 Created ACTION-47 - Provide a code example showing continuation for createAnswer [on Anant Narayanan - due 2012-06-18]. 10:19:00 Martin_, should be fixed there then 10:19:29 JonLennox, I'll take it up with the authors 10:21:57 harald: this the 3rd redesign in 3 months, and I dont' want a redesign without a compelling reson 10:22:30 6 months ago, I would settle for appealing reasons, but at this point I'd rather have a compelling reason 10:22:46 fluffy: we haven't designed error handling yet, this may fall in this category 10:22:54 s/in 3 months/in 6 months/ 10:23:25 harald: want to get into SdpType before lunch. having them twice is wrong, we should settle that 10:23:30 ekr: we should have a new method call 10:23:36 that was sarcasm 10:24:18 harald: we should try the polling method. who would like to have SdpType inside or outside? 10:25:45 harald: 1st question: do you have an opinion? 10:26:00 7 opinions 10:26:19 how many prefer to have the type inside the sdp object: 5 10:26:40 how many prefer to be outside: 2 10:27:07 conclusion: put the sdptype inside, remove the additional parameter 10:27:21 harald: we can have the discussion about mutability later 10:27:38 You missed the fourth and fifth questions, which are who thinks that the colour of the bike shed doesn't matter 10:28:06 ekr: certain things are errors, but mutating it to wrong values is an error 10:29:23 lunch! 10:32:00 derf i would prefer that it be mutable, but yes, that could be a less elegant workaround 10:32:51 it shall be green: http://mamdblueroom.files.wordpress.com/2010/11/bikeshed2.jpg 11:26:56 people starting to gather in the Kista room 11:29:46 DiMartini has joined #webrtc 11:30:02 scribe: burn 11:32:36 Topic: Statistics API proposal (http://www.w3.org/2011/04/webrtc/wiki/images/7/7d/June_11_Stats.pdf) 11:33:14 adambe has joined #webrtc 11:33:33 hta: vital need for statistics, but often left until the last minute, so i wrote something 11:34:22 -> http://lists.w3.org/Archives/Public/public-webrtc/2012Jun/0040.html Stats API proposal, from Harald 11:34:32 hta: statistics not intended for end user, mainly for service provider. Is everything actually still working? 11:34:54 ... since service provider's only access is API, stats should be there 11:35:25 ... should reuse meanings in other statistics collection approaches 11:35:59 Mauro has joined #webrtc 11:36:15 ... MediaStreamTrack is the core unit for collecting stats. Feedback from recipient to sender is important. 11:36:59 ... since all of the data we care about is time-varying, need to timestamp everything 11:37:37 ... means we will need to sync clocks (or equivalent), but lots of world knowledge here. 11:38:29 ... user JS calls GetStats() on pc, then callback returns info 11:38:46 ekr has joined #webrtc 11:39:07 Martin_ has joined #webrtc 11:40:22 ... model includes a pointer to track, local/remote data sets, data items are key/value pairs with keys in a new (?) registry 11:40:59 ... define some MTI stats such as packets and bytes, IP:Port 11:42:01 ... anyone can propose new statistics for registry. Need to distinguish between unsupported statistics data item and no result for that item. 11:42:21 ... need aggregated statistics (MediaStream, all PC) 11:42:52 ... maybe schedule periodic callbacks as well. The latter two may not need to be in version 1 11:43:31 ... one challenge is that not all info is known to browser 11:43:56 one comment on OS audio path, echo cancelation often estimates the round trip 11:44:57 ... another is that synchronized stats are needed for aggregation, but can't always exactly correlate sender and recipient data 11:46:12 ... (jumps to "issues solved elsewhere") JS solves this 11:46:38 anant: setInterval doesn't control when callbacks occur 11:47:36 dom: you made this async because collection can take time? 11:48:25 hta: if i can't guarantee getting back to you within 10ms, i shouldn't block. sometimes may need to call out to external module that could take time, although usually it won't. 11:48:34 adam; can you say "collect for 10 secs" 11:49:12 hta: don't want to. count in the core and use callbacks to compare and do the calculation 11:49:20 s/adam; /adam: / 11:49:41 dom: in zakim, eg, can ask who is making noise and it will wait for 10 secs 11:49:45 hta: should be done at JS level 11:49:54 stefan: have you been thinking about the data channel? 11:50:03 hta: no 11:50:11 stefan: i don't think we should have stats 11:50:31 cullen: web sockets doesn't' have stats but is visible to browser 11:50:51 randell: info is useful to app. bytes queued are available in websockets 11:50:54 s/browser/server/* 11:50:57 s/browser/server/ 11:51:08 cullen: at least need bytes xmitted and received 11:51:17 randell: per data channel, or global? 11:51:20 cullen: not sure 11:51:54 hta: difference from media is in data channel app sees the bytes, but not for media 11:52:19 cullen: want to know what happened on network 11:52:28 randell: there could be other useful info 11:52:59 magnus: about data channel, also have partial reliability option. may need to know reliability stats 11:53:24 hta: RFP for ???? MIB exists? 11:53:34 juberti has joined #webrtc 11:53:37 nobody implements that AFAIK 11:53:48 s/RFP/RFC/ 11:54:08 hta: (continuing with slides) another challenge is model problems 11:54:13 MagnusW has joined #webrtc 11:54:41 ... eg, where to count in FEC streams, where stats go for removed streams, how you count for multi-stream tracks 11:55:09 s/????/SCTP/ 11:55:15 -> www.ietf.org/rfc/rfc3873.txt SCTP Management Information Base (MIB) 11:55:25 adam: where are counters in the first place? 11:55:56 hta: conceptually they are attached to a MediaStreamTrack. You need a handle to the track to get data 11:56:04 dom; why not just leave the object 11:56:07 adam: +1 11:56:15 s/dom; /dom: / 11:56:21 s/why not just leave the object/why not put the stats method on the track object itself/ 11:56:27 adam: it can remain as an ended or finished track 11:56:43 I like HTA idea of never removing a track 11:57:12 jonathan lennox: there are post-repair stats for IPC (??) 11:57:40 s/IPC/RTCP/ 11:57:43 ... there are also multiple remotes. result of tomorrow's discussions may make this more complex 11:58:13 hta: don't want to support transport relays on multicast in v1 or rule out doing it in the distant future 11:59:06 ... with multi-stream tracks, how do I count only once even though only sent once 11:59:58 ted: just count once. if you count for a particular track, you are right. However, adding up counts for all tracks will not add up to the number of bytes sent. Not a problem as long as app author knows what they did 12:00:25 justin: track in multiple streams might be sent more than once due to different encodings 12:00:36 randell: could be different processing on tracks too 12:00:47 justin: should show up multiple times 12:02:18 hta: maybe instead of MediaStreamTrack as selector, could query track for what to query to find out about its stats. Then ask PC for the info. 12:02:36 anant: what is same stream/track is added to multiple peer connections 12:02:41 tuexen has joined #webrtc 12:02:57 cullen: sounds too complicated. better just to know what are all the objects to query 12:03:08 stefan: why can't this go on the track? 12:03:24 ... its all on the receiving side 12:03:39 (several): disagree 12:03:58 stefan: then the sides need to agree in advance on this info 12:04:02 hta: yes, RTCP 12:04:53 magnus: need a clear model for how to handle multiple encodings of same media source. 12:05:47 justin: on remote side, what would they see if you had different encondings? Two tracks, right? Because different SSRCs. Maybe then we need to clone track rather than using multiple times 12:06:12 cullen: this would get with propagating use up to gUM for camera changes, etc. 12:06:42 (missed some) 12:07:36 randell: adding add'l semantics on top of media stream tracks that already exist. 12:08:15 ... network media tracks add info on local streams/tracks 12:08:44 ... tracks in PC are not necessarily the same as those returned from getUSerMedia 12:10:33 anant: make media stream tracks immutable so you can't change their characteristics after creation. it has fixed properties. if you want to display different resolutions in different images, then those are different tracks. can derive one track from another. 12:10:45 Gonzalo has joined #webrtc 12:10:57 justitn: but if want to change resolution, will need to create a brand new track. 12:11:06 ekr: what if other side changes resolution 12:11:17 s/justitn/justin/ 12:11:27 GangLiang has joined #webrtc 12:11:40 justin: benefit of making immutable? 1-1 identity is nice, but why does that mean you can't change an existing track 12:12:16 anant: avoids having to change constraints that may conflict for derived tracks, where we would have to distinguish between changeable params and others that arent 12:12:23 I was observing that there are four MediaStream sub-types; LocalIdealMediaStream, LocalPacketizedMediaStream, RemoteIdealMediaStream, RemotePacketizedMediaStream 12:12:25 .. can deal with remote changes differently 12:12:57 randell: if track is sourced from video element, source-encoded, then you change the track? 12:13:11 derf: this could happen at every frame!!! 12:13:25 s/frame/keyframe/ 12:13:27 anant: should be forced to create a new track if characteristics change 12:13:37 justin: can happen just by grabbing scroll handle 12:13:43 Ralph has joined #webrtc 12:13:48 randel: encoder might do this itself 12:14:06 anant: SDP doesn't have all that? 12:14:13 (several): no 12:14:41 jimb: perhaps anything is SDP shouldn't be changeable, but everything else is okay? 12:15:05 cullen: SDP does specify an envelope within which you can operate. I would still expect to be able to change SDP 12:15:41 randell: request resolution changes may be able to happen without SDP changes, sometimes might. 12:15:47 ekr: benefit of immutable? 12:16:51 RRSAgent has joined #webrtc 12:16:51 logging to http://www.w3.org/2012/06/11-webrtc-irc 12:17:04 RRSAgent, draft minutes 12:17:04 I have made the request to generate http://www.w3.org/2012/06/11-webrtc-minutes.html dom 12:17:05 anant: ?? has fixed size. video doesn't know hat resolution is being received on track. more complex now in fixed output if track is changing under the covers. 12:17:10 randell: already handled today 12:17:11 s/??/video/ 12:17:30 justin: happens for html you download too 12:17:46 RRSAgent, make log public 12:18:03 RRSAgent, draft minutes 12:18:03 I have made the request to generate http://www.w3.org/2012/06/11-webrtc-minutes.html dom 12:18:07 justin: want to avoid downscaling 12:18:38 Ralph has left #webrtc 12:18:46 randell: always latency between UI resize and change in the source. ALso may not cause a resize (say if different parties have different sizes for same stream) 12:19:33 justin: may go from small to large display and need fuller sending, but that doesn't change other small images. 12:19:36 ... many reasons for this 12:19:42 I want to insert myself on Q 12:20:14 Zakim has joined #webrtc 12:20:17 q+ fluffy 12:20:22 stefanwenger: may or may not be value of renegotation for change of resolution, but there are *many* SDP params that can change (framerate) during stream lifetime 12:21:02 ... idea that stuff that sits in SDP without renegotiation not true for 264 and, i believe, VP8 12:21:19 s/stefan/stephan/ 12:21:26 cullen: we agree that two different windows is two tarkc objects. we just don't agree with immutability of a track 12:21:55 jimb: what is immutability? can a track change from audio to video? of course not, so that's one kind of immutability 12:22:29 hta: will modify proposal to have another layer of indirection so that in simple case we can get just one piece of info back but to allow more complexity 12:22:59 dom: question about privacy. some of the info available (remote ip and port) might be additional. 12:23:14 hta: don't see anything yet that hadn't already been exposed 12:23:31 ... did say that data must be possible to be anonymized 12:24:13 anant: API is getStats, callback. Perhaps instead should be event that can be registered for regular returns 12:24:36 hta: concerned about timers that no one is still around to listen to 12:25:06 richard: RTCP also has ??? that should be returned / received 12:25:31 s/???/application data/ 12:25:32 randell: data channel API would be better way to transmit such info. 12:25:59 hta: if we find later that there is other info available in browser that other browser needs, RTP may be way to communicate it 12:26:21 hta: application data has multiple meanings 12:26:37 +1 lenox 12:26:45 lennox: app data is stuff for your app, not something standardized. if standardized, not "applicaitn data" 12:27:14 ddruta: question about remote sources for stats. where does app connect. 12:27:27 hta: whatever is sending RTCP reports . 12:27:41 druta: should we have param that specifies URI? 12:27:58 hta: perhaps could extend that way, but I need to see the use case before we go beyond remote browser 12:28:17 stefan: what's next? 12:28:33 hta: will come up with new proposal that can handle multiple stats per track. 12:28:42 dom: will be separate spec, or part of main one? 12:28:48 hta: if quick, should be part of main doc 12:29:03 q? 12:29:09 q- 12:29:52 Topic: P2P Data API 12:30:36 scribe: DanD 12:30:38 hta has joined #webrtc 12:30:47 Topic: Data API 12:31:16 -> http://www.w3.org/2011/04/webrtc/wiki/images/4/45/WebRTC_interim-june-2012_Data_API.pdf P2P Data API slides 12:31:29 RRSAgent, draft minutes 12:31:29 I have made the request to generate http://www.w3.org/2012/06/11-webrtc-minutes.html dom 12:31:57 adambe Showing example from the slides 12:32:34 .. example creating a datachannel with an active peerconnection 12:32:42 s/adambe/adambe:/ 12:33:46 fluffy: We need to add the same thing that we do for media for data 12:35:03 jesep: there will be no offer answer for datachannel 12:35:32 s/jesep/jesup/ 12:35:43 fluffy: I'm on board with this proposal 12:36:39 anant: Complicates the case as it combines the everything in one connection 12:37:17 adambe: we talked about negotiation call back 12:37:51 .. you will only have to create an offer for the first channel 12:38:41 Richard: Why isn't data treated like the other media? 12:39:12 hta: We had this discussion on the mailing list 12:39:41 mic please 12:39:56 dom: there are differences between media and data 12:40:39 hta: I proposed for unichannels for datachannel 12:41:26 Richard: It seams to be the need to create a construct datachannels 12:43:01 fluffy: we need to write down and we need to negotiate the lines in SDP. We're going in the right direction 12:43:56 adambe: You are right. It can be a container for multiple datachannels 12:44:39 fluffy: how do I know how to receive datachannels? 12:44:40 DiMartini has joined #webrtc 12:45:15 @dan - you get a callback on the PeerConnection that tells you there is a new data stream 12:45:32 you need some out of band info to know what it might contain 12:45:38 I think we can do a little better than than 12:47:01 Ted: I agree with Cullen. Designing it on the fly in the room is not productive 12:47:32 jesup: I can write up a proposal 12:47:53 adambe: we have a facility but is not in Javascript 12:48:10 ACTION: Jesup to write up possible directions for datachannels in peerconnection and relationship with media streams/tracks 12:48:10 Sorry, couldn't find user - Jesup 12:48:16 burn: It seams that we're treating datachannel as a track 12:48:38 .. we don't have a container to hold all the datachannel 12:49:05 ACTION: Stefan to pester Jesup to write up possible directions for datachannels in peerconnection and relationship with media streams/tracks 12:49:11 Created ACTION-48 - Pester Jesup to write up possible directions for datachannels in peerconnection and relationship with media streams/tracks [on Stefan Håkansson - due 2012-06-18]. 12:50:29 justing: datachannels are very application specific 12:50:38 s/justing/justin/ 12:51:01 fluffy: I'd like to challenge this. CLUE might be able to use this 12:51:54 hta: We need to add the use case for data channel standardidation 12:53:08 can we get the slides sent to public-webrtc for the benefits of the minutes and the absent? 12:53:32 jesup: going over the slides 12:53:43 Sent! 12:54:19 jesup: Open Issues are when can you send data on the datachannel 12:54:36 -> http://lists.w3.org/Archives/Public/public-webrtc/2012Jun/att-0063/W3_Interim_June_2012_Data_Channel.pdf Data Channel Issues, slides by Jesup Randell 12:55:49 jesup: Second issue is when can we call create datachannel 12:56:19 adambe: how can I connect datachannel if I don't have a peerconnection? 12:57:16 dom: p2p data is very useful for developers with or without media 12:57:36 .. we should not make the assumption that media is used 12:58:23 jesup: proposal to create offer 12:59:03 .. to create datachannel before createoffer 12:59:30 erk: We need a datachannel container as burn suggested 12:59:41 s/erk/ekr/ 13:00:51 ekr: It is an expessive task 13:02:15 jesup: renegotiation need is application specific 13:02:59 Stefan: you cannot treat renegotiation needed with delay 13:03:17 q+ 13:04:00 Richard: If we don't have a construct for data channels 13:04:57 .. first datachannel is special 13:04:59 (note that data channels have at least two different types: reliable and non-reliable; I'm not sure how that is dealt with when some channels are reliable, and others are not) 13:06:10 Ted: We have to consider resource utilization (radio) when keeping these datachannels alive 13:07:03 jesup: If you decide you're done with the datachannel you can drop it 13:08:46 ..when there's no data it makes sense to shut it down. If you do shut it down you're left with nothing. Back to square 0 13:09:40 .. I don't have an objection 13:10:17 Paul: to support exposing this object. If there are errors there's no place to report them 13:10:31 ack fluffy 13:10:44 markus has joined #webrtc 13:11:00 fluffy: agreed with the error handling and add statistics to the case 13:12:17 burn: I'd like to see this explicit object. 13:12:29 from far enough away, everything looks the same 13:12:42 q- 13:13:17 .. from an API perspective it looks like a track 13:13:18 €3 13:13:32 hta: doesn't really match 13:14:36 JonLennox: You need to know that you can't create the objects 13:16:34 have we come to a conclusion about the mystery data track object? is this discussion part of Randell's previous action item 13:16:42 jesup: THe question is when can you call Send (from the slide proposal) 13:17:43 ..if we allow before send we can reuse code written for websockets 13:18:16 fluffy: I'm not worried about interoperability with websockets. More interested on error handling 13:18:56 jesup: being application specific, application can figure out 13:19:51 hta: if app really needs this it can build it. If you don't have early data it can fake it. I don't favor early data 13:21:43 JonLennox: it's not clear to me what's the different between I'm connected and I can't send data to I just can't send data 13:22:21 Ted: There's no such thing as early data. It's just data 13:23:45 jesup: I you can create the connection before, better 13:24:10 hta: should we poll for this? 13:24:22 .. a lot of people have oppinions 13:25:03 .. decision not to support early data 13:25:23 ..coffee break 13:25:43 Stefan: there was support for container 13:25:54 ACTION: Adam to work with Randell on a proposal for a data channel container 13:25:59 Created ACTION-49 - Work with Randell on a proposal for a data channel container [on Adam Bergkvist - due 2012-06-18]. 13:49:40 scribe: stefanh_ 13:51:46 First topic after coffee: 13:52:00 Report on status Audio WG. 13:52:05 (Dom talking) 13:52:20 adambe has joined #webrtc 13:52:38 THere has been some controversy over what API to pick from two proposals. 13:53:05 However, now the group has agreed on one API: the Web Audio API 13:53:25 Next topic: Next steps as we continue develop the APIs. 13:54:12 Document stages FPWD LCWD (several of them usually) CR 13:54:28 At CR we have to prove that the spec is implementable 13:54:45 and that different implementations implement the spec in the same way 13:54:58 testsuites are created for this purpose 13:55:27 slides at http://www.w3.org/2012/Talks/dhm-webrtc-testing/#%281%29 13:55:54 one or more testcases for each MUST in the spec 13:55:58 scribe: burn 13:56:19 dom: similarly for MUST NOT 13:56:48 ... why do we need to do this? of course the process requires it, but more importantly interoperability is crucial for adoption and success of standards 13:57:22 ... additionally, writing test cases *REALLY* exercises the spec language, pointing out where interpretations need to be clarified 13:58:36 ... Although test cases are required for Candidate Recommendation, it's best to start as soon as the spec begins to stabilize. There is an obvious trade-off between getting it done early and being forced to update tests often as the spec changes. 13:59:34 ... but tests can be written for stable parts of the spec. Some people/orgs are test-driven, requiring a test to be provided for every change request, but this can result in many changes. 13:59:59 ... Best is not to wait too long. We should set up the testing framework before Last Call, and ideally begin writing tests as well. 14:01:02 ... Often no one in the group wants to write tests. However, often others outside the group find it fun. It is a great way to improve the specification and does not require agreeing to the intellectual property statements that members must agree to. 14:01:49 ... It's also a good way to really understand how the spec works -- if you can't write a test for it, the problem may be with the spec. 14:03:34 ... Best practice is to have one or more test facilitator(s) per spec to oversee work. The facilitators do not have to write all the tests, just ensure they are written properly, getting done, etc. 14:04:52 ... Most JS-based working groups now use testharness.js (assertion-building primitives), with a repository per spec in dvcs.w3.org. Each group needs to decide on the process for submission and review. 14:06:05 ... Process could be "submit, review, approve" or "submit, approved" until proved wrong. If there is a formal review process details about the review need to be defined in advance. 14:07:47 burn: review process does not have to be laborious or complex. can just have writers review other writers' tests, and vice versa. 14:08:12 dom: (now showing test case(s) he wrote for getUserMedia) 14:09:06 dvcs.w3.org/hg/media-capture/file/de85fe3f590f/submitted/W3C/ (if I got it right) 14:09:14 Mauro has joined #webrtc 14:09:48 Josh_Soref has joined #webrtc 14:10:29 (now looking at dvcs.w3.org/hg/media-capture/file/de85fe3f590f/submitted/W3C/video.html) 14:12:08 library provides two different kinds of tests: synchronous and asynchronous 14:14:16 dom: in this example, he calls getUserMedia and verifies three assertions: there is a LocalMediaStream, no audio tracks were returned, and at least one video track was returned. 14:14:28 s/library/dom: library/ 14:14:49 anant: why do you call t.step inside the callback? 14:14:55 dom: that might be a bug. 14:15:32 hta: what's the procedure for running these against implementations? 14:16:06 dom: browsers usuallly run the tests on their own. If they don't pass and they think the test or the spec is wrong, they then contact the WG 14:17:11 ... also, the second js library allows for integration into various test frameworks for automated testing (for tests that do not require human judgement) 14:19:24 ... Now for specifics for WebRTC. First, how do you test constraints interoperable? Second, how do you have peers to connect to? Also server-side components that we may need ref implementations for. We also need to make sure there is not a failure in the protocol itself (beyond the API). 14:20:14 JonLennox: if ICE connection fails, need to do XXX. These kinds of tests are needed as well. 14:20:28 dom: yes, network conditions need to be simulated as well. 14:21:53 scribe: stefanh_ 14:22:19 markus has joined #webrtc 14:22:47 Return to JSEP discussion 14:23:32 juberti: should we create a sw test harness with virtual input devices virtual network etc.? 14:23:57 hta: dom is already in contact with chrome test people 14:24:11 ekr: we will do this for firefox 14:24:40 cullen: when the discussion starts we can contribute 14:24:50 yang has joined #webrtc 14:25:05 Scribe: dom 14:25:23 hta: we're expecting a Mozilla volonteer for testing! 14:25:27 Topic: Back to JSEP 14:25:36 JSEP again. 14:26:11 adambe: we talked about sdptype on media description 14:26:53 ... you could set the type as provisional either as a param to createAnswer, or by setting the attribute in the generated answer 14:27:12 justin: as far as I know, the only meaning of provisioning vs final answer, 14:27:24 ... the final answer ends the offer/answer exchange 14:27:36 ... it only affects the state machine, not the actual offers/answers that are generated 14:27:50 ... so the only effect of that parameter would be to set the type to pranswer 14:28:24 ... based on previous discussions, we have already identified that the type attribute needs to be mutable 14:28:40 ... I also object to this ad-hoc parameter on the method 14:28:50 ekr: I think I agree with Justin here 14:29:40 cullen: setLocal would behave different with pranswer 14:30:44 ... I would put it as a constraint 14:31:03 richard: there seems to be a potential need for the answer to inform the offer 14:31:13 ... whether or not the intention behind it is provisional or not 14:31:56 martin: the decision is always made by the application 14:32:36 justin: it actually matters: there are some cases in which treating an answer as a pranswer is ok, but it's not ok to treat a pranswer as an answer 14:32:44 richard: OK from which perspective? 14:33:16 justin: at the callee side, the person generating the answer, the app decides whether to mark it as a pranswer or an answer 14:33:37 ... the caller receives something; if he deals a pranswer as an answer that's bad 14:33:48 s/deals a/deals with/ 14:33:59 ... it's probably OK in the reverse 14:34:17 Jerome has joined #webrtc 14:34:32 richard: in SIP, pranswers are not exposed 14:35:50 justin: if a caller treats an answer as a pranswer, then the callee assumes that the state machine is in a stable state when it is not 14:36:17 adambe: to summarize, we can either treat is as a constraint, or use the fact that the type attribute is mutable in the offer object 14:36:34 ... so, should we have a constraint for it? 14:37:14 justin: a constraint would probably be fine 14:37:22 dom: what would we need several ways to do this? 14:37:34 cullen: linked to error handling 14:37:59 ... this depends on things we haven't looked at, so I don't think we can really make a decision 14:38:32 ekr: if it turns out we need to know that type, I don't think we should stuff into constraints 14:38:39 ... It really doesn't seem like a constraint 14:39:31 What I'm saying is that if we do decide we need this, putting it in a constraint seems pretty gross 14:39:43 it's not clear to me why it's any better than an extra argument 14:39:53 Gonzalo has joined #webrtc 14:39:56 Obviously, it's just a taste issue 14:40:34 adambe: so, we remove the additional argument; if we need it as a constraint, we'll add it back later 14:43:28 [discussion about the value of constraints as a host for this] 14:43:56 justin: I would prefer we avoid a bunch of positional parameters 14:44:03 ... a dictionary with options would be much better 14:44:21 dan: constraints were not designed for parameters 14:44:30 adambe: yeah, I think we should have a settings dictionary 14:46:46 ACTION: adam to look at replacing mediaconstraints in createAnswer with a settings dictionary 14:46:51 Created ACTION-50 - Look at replacing mediaconstraints in createAnswer with a settings dictionary [on Adam Bergkvist - due 2012-06-18]. 14:48:02 harald: what on earth does it mean for the error callback to be optional? 14:50:10 ... I see no reason to make it optional since the app stops when error occurs 14:50:22 anant: continuation would help here as well 14:50:34 martin: this is similar with things done e.g. in XHR 14:51:32 setTimeout 14:51:47 tim: making it required would at least raise the chances that people copy & pasting the code would deal with error 14:52:14 anant: another approach is to deal with errors as part of a single callback signature à la node.js 14:53:08 node.js uses doSomething(function(err, value) { }); It's a nice pattern. 14:54:26 adambe: moving on to ICE Restart 14:54:59 ... should we have an explicit updateIce() method to reset the IceServers configuration 14:55:23 Mauro has joined #webrtc 14:56:56 justin: in RFC@@@ says that restarting ICE is done by changing @@@ 14:57:15 stefanh has joined #webrtc 14:57:29 scribe: stefanh 14:57:31 RFC 5245, changing ufrag and password 14:57:37 discussion on restart ice 14:57:45 usernam+password change 14:58:18 (scribe a bit lost) 14:58:56 scribe: dom 14:59:04 general design: most apps will never call update ICE 14:59:32 but what drove is that an app might be after a while willing to supply non-realay candidates 15:00:26 Ted: is there not a need to be able to restart ICE but the app does not supply username+frag 15:00:36 justin: what we need 15:00:37 scribe: stefanh 15:00:53 api call "generate new one and restart ice" 15:02:18 the new username+password must be supplied to the server 15:02:40 adambe: can the server even generate all info? 15:02:52 does it have all info (like msid)? 15:03:20 thompson: an advanced server can do this 15:03:48 justin: we don't need the extra parameter 15:04:26 magnusw: can someone tell me how this works if it is the browser that detects that an ICE restart is needed. 15:04:51 cullen: "onrennegotiaonfeedback" signals this. 15:05:03 Jerome has joined #webrtc 15:05:49 lennox: new I/F available: should signal to app 15:06:51 Mauro has joined #webrtc 15:07:32 what if you have a perfectly usable 2G connection but moves into WiFi coverage 15:07:39 what should happen 15:08:28 should be discussed tomorrow 15:09:09 justin: what should happen when new candidates are trickled 10min after start? 15:10:56 cullen: what is the difference betwenn a mandatory constraint and a setting? 15:11:03 The logic I understood of ICE was that once you converge, the way you change in the future is to do an "ICE Restart". The old selected pair is still live until a new pair is selected. 15:12:41 cullen asking for guidance on settings/constraints/dictonaries 15:12:49 Zakim has left #webrtc 15:13:15 DiMartini_ has joined #webrtc 15:14:07 ekr: should we replace parameters with dictonaries 15:14:31 cullen: editors will take liberties and wait for yelling 15:15:21 hta: chairs to bring back to rtcweb that how interface changes happen is unclear 15:15:58 Resolution: IceRestart to be removed 15:16:35 RFC 5245 9.1.2.1 "Existing Media Streams with ICE Running" is equivalent to trickle candidates before ICE has completed; 9.1.2.2 "…with ICE Completed" says you have to send the existing selected candidate unless you're doing an ICE Restart. 15:16:37 does it matter that Zakim left? 15:17:12 9.1.1 "ICE Restarts" says "during the restart, media can continue to be sent to the previously validated pair." 15:17:29 So adding a candidate is an ICE restart; you keep using the old selected pair until the restart succeeds. 15:23:57 JonLennox, does this imply that you need to gather on the existing network interfaces, or retry connectivity checks on previously failed candidates? 15:26:07 You can reuse the existing gather state if you want for the successful candidates, or re-gather. Whether you re-check previously failed candidates is a local decision, depending on whether you have some reason they'll start working now. 15:26:23 setRemote/setLocal should accept the union of object andf string 15:26:27 correct :) 15:26:42 What candidates to gather is the part of ICE that's the most subject to implementation choice 15:28:22 But the point is that once you're in the "ICE Completed" state the only way to change your set of candidates is through an ICE Restart. 15:29:08 From a w3c pov the interesting question is whether it's the application or the browser that needs to decide whether and when to do a re-gather. 15:29:19 (And how) 15:29:29 The next trick is working out a) how to trigger ICE restart and b) how to discover that an ICE restart is needed... 15:29:49 I think we have a, but I think we realize that we also need b 15:30:15 needed in a broad sense, including "possibly desirable" 15:30:32 DanB: you usuall have to touch the SDP when interoprating 15:30:36 exactly 15:31:15 anant: important to define for the normal web developer. 15:32:23 hta: we need to know what SDP things you'd like to munge before starting design an API for it 15:33:12 of course, if you go to the trouble of enumerating your use cases so precisely, you might as well drop the SDP altogether and build APIs for each use case. Understanding the use case is the hard part, designing APIs is easy. 15:36:51 RRSAgent, draft minutes 15:36:51 I have made the request to generate http://www.w3.org/2012/06/11-webrtc-minutes.html dom 15:38:04 ekr has joined #webrtc 15:38:59 tuexen has joined #webrtc 15:40:01 JonLennox has left #webrtc 16:07:43 ekr has joined #webrtc 16:15:18 ekr has joined #webrtc 16:36:08 ekr has joined #webrtc 16:55:01 mreavy has joined #webrtc 16:57:05 jesup|laptop has joined #webrtc 17:07:32 Martin_ has joined #webrtc 17:25:47 tuexen has left #webrtc 18:54:34 Martin_ has joined #webrtc 18:58:51 jesup|laptop has joined #webrtc