07:37:17 RRSAgent has joined #webrtc 07:37:17 logging to http://www.w3.org/2012/10/29-webrtc-irc 07:37:19 RRSAgent, make logs world 07:37:19 Zakim has joined #webrtc 07:37:21 Zakim, this will be RTC 07:37:21 ok, trackbot, I see UW_Web RTC()3:00AM already started 07:37:22 Meeting: Web Real-Time Communications Working Group Teleconference 07:37:22 Date: 29 October 2012 07:37:53 zakim, call rhone_1 07:37:53 ok, stefanh; the call is being made 07:38:34 - +44.190.881.aaaa 07:38:36 UW_Web RTC()3:00AM has ended 07:38:36 Attendees were +44.190.881.aaaa 07:39:06 zakim, call Rhone_1 07:39:06 ok, stefanh; the call is being made 07:39:07 UW_Web RTC()3:00AM has now started 07:39:08 +Rhone_1 07:39:38 zakim, who is on 07:39:38 I don't understand 'who is on', stefanh 07:39:53 + +44.190.881.aaaa 07:39:53 zakim, who is on the phone 07:39:53 I don't understand 'who is on the phone', stefanh 07:40:11 Hidetoshi has joined #webrtc 07:40:12 zakim, who is on? 07:40:12 I don't understand your question, hta. 07:40:21 zakim, who is on the phone? 07:40:21 On the phone I see Rhone_1, +44.190.881.aaaa 07:42:00 anant has joined #webrtc 07:42:01 gmandyam has joined #webrtc 07:42:32 frodek has joined #webrtc 07:42:57 Andy Hutton is on the phone 07:43:45 richt has joined #webrtc 07:46:07 burn has joined #webrtc 07:46:32 fluffy has joined #webrtc 07:46:44 martin has joined #webrtc 07:47:08 ekr has joined #webrtc 07:47:19 tomoyuki has joined #webrtc 07:47:23 adambe has joined #webrtc 07:47:40 SungOk_You_ has joined #webrtc 07:47:43 kotakagi has joined #webrtc 07:47:43 hta: the best use of face-to-face time is to be specific 07:48:06 ...: people pay more attention campared to mailing lists 07:48:16 ... we've tried to make the agenda specific 07:48:41 ... we might go with presenters proposal 07:49:07 ... there also be discussions 07:50:06 ... we should record off-topic topics and move them to the AOB session 07:50:15 dom has joined #webrtc 07:50:23 stefanh: fist session is about API functionality we haven't addressed yet 07:50:41 ... this might be the least concrete item on the agenda 07:50:42 RRSAgent, pointer? 07:50:42 See http://www.w3.org/2012/10/29-webrtc-irc#T07-50-42 07:50:53 ... what de we need to do now and what can we postpone 07:50:56 Topic: API functionalities missing in PeerConnection API 07:51:16 ... API topics 07:51:27 ... width, hegiht sent over a PeerConnection 07:51:33 i/ hta:/scribenick: adambe 07:51:35 ... priority 07:51:43 ... is media flowing? 07:51:44 Zakim, who's on the phone? 07:51:44 On the phone I see Rhone_1, +44.190.881.aaaa 07:51:52 ... how much bandwith is used 07:52:00 ... how much can be used 07:52:08 ... how to reject media streams 07:52:13 ... echo control 07:52:21 ... one thing missing on the slides 07:52:28 ... should we support security descriptions 07:52:52 Present+ adambe, hta, stefanh, derf, burn, dan_druta, richt, anant, dom, juberti, jim, matthew, ekr, fluffy 07:52:53 matthew has joined #webrtc 07:52:58 (a use case is presented) 07:53:16 ... one peer sends video with two different resolutions to two other peers 07:53:23 ... are people ok with this? 07:53:30 fluffy: we should support this 07:53:48 burn: you're showing the entrence and the consumer side 07:53:51 stefanh: yes 07:54:36 hta: there are multiple ways to achive this reuslt 07:54:51 ... first question is.. do we need to support this? 07:54:59 ... the answer is yes 07:55:05 ... then how should we solve it 07:55:14 stefanh: this is the most difficult slide in my deck 07:55:33 ... application knows about the receiving side 07:55:50 ... or the receiving side could tell the sender 07:56:03 DanD has joined #webrtc 07:56:03 ... third possibilty is that the app isn't involved 07:56:39 q? 07:56:41 q+ 07:56:50 q+ 07:56:52 matthew: even if the receiver is involved the sender needs to be involved 07:57:09 justin: there needs to be some higher limit 07:57:26 matthew: there might be a lot of contstraints 07:57:38 ack fluffy 07:57:49 fluffy: this is one of the reasons we need constraints 07:58:05 stefanh: we shouldn't modify the sdp unless we have very good reasons 07:58:06 juberti has joined #webrtc 07:58:17 ack ekr 07:58:18 hta: we currently don't use a speakers queue 07:58:44 ekr: what do we expect to happen if the receiver asks for a different aspect ratio 07:58:58 ... should the PeerConnection rescale 07:59:01 ...? 07:59:32 justin: the sender might need to chose the closest thing 08:00:11 hta: we want people to separate the case where you really require something compared to the case where you really can't live without something 08:00:24 side comment: generally we either need to fully specify the SDP the is used to negotiate things like this OR we need contraints. unfortunately when there's contraints, we *also* need to fully specify the SDP that flows between them... unless we choose to have it *only* be an API issue ("direct manipulation" vs. "constraint setting") 08:00:47 hta: is the sending app or sending PeerConnection informe 08:01:15 s/hta/stefan/ 08:01:53 Present+ Magnus 08:02:37 justin: information about the consumer dimensions could be sent as a session description 08:03:08 fluffy: the connection to the video tag is interesting 08:03:30 ... would it be reasonable to adjust the send size to the consumer size? 08:03:49 ... this was a driver for renegotiation callback 08:04:39 DanD has joined #webrtc 08:04:44 martin: you don't have the consumer in the initial negotiation 08:04:52 fluffy: it's not always true 08:05:00 dan_romascanu has joined #webrtc 08:05:08 Jim_Barnett has joined #webrtc 08:05:39 Bo_Chen has joined #WebRTC 08:05:58 derf: css also impacts this 08:06:16 Bo_Chen has left #webrtc 08:06:19 fluffy: a video tag might be specified with a size or not 08:07:08 stefanh: there could be several video tags that wants to affect the sender side 08:07:26 hta: there's a ultimate fallback video size 08:07:45 burn: smart browsers might behave differently 08:08:30 matthew: smart browser decisions must be overidden if the developer wants to do something else 08:09:28 burn: if we have an API then the browser must take input from the API into account... otherwise the browser can do its magic 08:09:36 stefanh: what is the conclusion? 08:10:22 ... the receiving side can influence, but we also need an API to let the developer tweak 08:11:13 ekr: do we want information from the receiver to bubble back all the way to the camera on the sender side? 08:11:38 gape has joined #webrtc 08:12:14 burn: a browser can use any valid value in a contraint range 08:12:38 matthew: if several consumers (local, remote).. who wins? 08:13:24 kensaku has joined #webrtc 08:14:17 ekr: some constrains are enforced when set and some constrains seems to be enforced continiously 08:14:17 kensaku has left #webrtc 08:14:47 dom has joined #webrtc 08:14:53 kensaku_ has joined #webrtc 08:15:09 burn: we might need a constraints that says "do not change video size" 08:15:59 stefanh: recap on proposed conclusion 08:16:26 ... receiving side as driver with an API for the app to influence 08:16:37 matthew: there's two ways to implement this 08:17:26 fluffy: we don't know if we'll use RTCP or SDP to negotiate video size 08:17:54 matthew: even if we go with RTCP we need an API to influence how the browser should behave 08:18:10 stefanh: let's move on 08:18:27 ... next slide 08:18:47 ... if the receiver detaches a stream from the consumer.. what should happen, 08:18:49 ...? 08:19:20 ekr: what if sender offers something that the receiver doesn't want? 08:19:28 stefanh: we'll get to that in a later slide 08:20:42 fluffy: we have two operations.. mute (undetectable from the sender side) and to say "don't send me packets" 08:22:01 justin: how do you say that I only want a subset of the offered set of streams 08:22:21 ... we don't have a good way to express that today 08:23:07 stefanh: next slide 08:23:19 ... requeseting a certain bandwith 08:23:37 ... there's an IETF draft talking about this 08:24:28 DanD: I propose a priority param to addStream() 08:25:58 ... we can discuss how the priority information should be handeled but we should decide on a mechanism to specify the intent 08:26:40 sakih has joined #webrtc 08:26:44 stefanh: addStream() is only called once per stream, it's a problem 08:27:07 DanD: we're the right group to specify the priority intent 08:27:19 burn: intent means it might not happen 08:27:27 hmm...s/constraint/intent/g ? 08:27:39 s/intent/pref/ 08:27:42 ? 08:27:50 that works too 08:28:15 there's a difference between "preferences" and "absolute limits" 08:28:35 i "prefer" 720P, but there's no way i ever want >2560 horizontal pixels 08:28:45 no, constraint != intent 08:28:56 DanD: at least the browser sholud be able to say that I marked you packets in a certain way 08:29:22 intent == hint, discussions about hints lead to a decision to support both mandatory and optional constraints 08:29:25 if you just go with direct manipulation then the API only has "settings", and the difference between "constraint" and "preference" is JS code 08:30:17 but the moment you let the two ends talk to each other via possibly-unmodified SDP blobs then you need places on the monster where it can be poked with a stick 08:30:18 Göran: we should describe this case in more detail 08:31:41 ... can the network trust the diff-serv code points set by the app 08:31:53 fluffy: in some environment you can't 08:32:09 ... they might provide information 08:32:17 ... but a separate request is needed to verify 08:32:43 DanD has joined #webrtc 08:32:50 Göran: we need more discussion around use cases 08:34:04 fluffy: I think this should be a topic for the AoB section 08:34:17 (people agree) 08:34:32 yahui has joined #webrtc 08:34:53 dom has joined #webrtc 08:34:53 hta: new topic - Security for Qos flow labels 08:35:48 ekr: there might be two API surfaces needed: tie constraints to media flow, (missed the other one) 08:36:19 DanD: I wan't a request that should be handeled by the trusted environment 08:36:50 BoHu_ChinaUnicom has joined #webrtc 08:37:15 npdoty has joined #webrtc 08:37:45 matthew: even if diff-serv cps isn't supported a system may enforce priority anyhow (we need to support this case as well) 08:38:49 hta: new topic for AoB - Control of the DSCP interface 08:39:00 stefanh: next slide 08:39:03 Suresh has joined #webrtc 08:39:08 ... other side of the same coin 08:39:22 ... feedback on bw.. 08:39:57 martin: I thin we need generic feedback on constraints set 08:40:16 sakkuru_ has joined #webrtc 08:40:28 ... there might be existing mechanisms 08:40:39 ... for others we might need to add something 08:41:31 matthew: e.g., if video has highter priority over slides, the app might want to know if the slides can't be sent at all 08:42:13 dom has joined #webrtc 08:42:27 stefanh: next slide 08:42:35 ... sender side pause/resume 08:43:03 ... we currently have enable/disable on MediaStreamTrack 08:43:11 ... every consumer is affected 08:43:31 ... we could have enabel/disable on PeerConnection 08:43:53 burn: we don't need that since you could clone media streams 08:44:10 jmarcon has joined #webrtc 08:44:18 yahui has joined #webrtc 08:45:08 hta: we implemented enable and disable as affecting the associasion between a stream and track 08:45:49 yahui_ has joined #webrtc 08:45:59 stefanh: next topic, AGC 08:46:11 fluffy: the text on the slides looks good to me 08:47:25 conclusion here was that we don't need to prioritize the agc/noise settings, it's not a preference, it's a setting 08:47:39 it might also be necessary to change this on the fly 08:47:41 burn: what happens if you turn AGC on and it's not available 08:47:51 fluffy: it should be a on/off setting 08:47:55 Wonsuk has joined #webrtc 08:48:05 derf: I hope there's a way to enumerate settings 08:48:10 we need a way to enumerate settings, for sure 08:48:15 fluffy: we should require that 08:48:19 cmills has joined #webrtc 08:48:35 juberti_ has joined #webrtc 08:48:52 agc/noise is a property of a track 08:48:54 hta: AGC should be on track lever 08:49:02 s/lever/level 08:49:09 stefanh: next topic 08:49:14 ... rejecting streams 08:49:25 martin: we need to know if multiple streams are offered 08:49:42 ... we need basic methods on the session description 08:50:10 derf: example: you offer me 10k streams.. how do I reject 08:51:41 DanD: it's not only if your device can do something.. there's also a question if your service can support this 08:52:18 martin: we need to know what you get before you can say what you want to accept 08:53:29 hta: if we have a mechanisms for the receiver to turn off a stream at any point.. would it be sufficient to turn it off rather than not accepting it? 08:53:53 kotakagi has joined #webrtc 08:53:57 matthew: it might be a resource question 08:54:15 markus has joined #webrtc 08:54:54 ekr: I interpret it as: you set the remote description and you see what streams are offered 08:55:37 stefanh: is the sending app informed about a rejected streams 08:55:40 ... ? 08:56:23 hta: if the use case for rejecting streams is to save resources then the sender needs to know 08:57:00 matthew: it's important how quickly can this be done 08:57:04 Stephane has joined #webrtc 08:57:17 fluffy: can someone send a proposal to the list? 08:58:02 dom_ has joined #webrtc 09:00:54 (I missed to scribe a lot of stuff while I was talking) 09:01:05 stefanh: next thing - AEC 09:01:27 fluffy: one param you need is what's going to the speakers 09:01:39 new issue that is related to this, and one that I will bring up later when we talk about this: SDP describes RTP sessions. The one m= section can have multiple tracks. How do we learn of these other than just waiting for arrival of packets on one of those? 09:02:18 adambe said: I sent a proposal to the list with inbound and outbound streams as different objects, which might make this discussion easier; missed having feedback on that. 09:03:12 another issue that's related to the last slide and not yet decided (and different in different implementations) is what to offer/send before user consent on a sending device occurs. one approach is to say "recvonly" and change to "sendrecv" when the consent happens, the other is to say "sendrecv" and send muted audio + black video until consent is received. recvonly->sendrecv takes the extra round trip to enable. 09:03:17 (scribe is missing a lot of stuff here) 09:03:33 burn: why do we need API for this? 09:03:41 fluffy: you might want to turn it off 09:03:53 burn: could this be a browser control? 09:04:16 someone: music is a use case where you wan't to turn EC off 09:04:44 matthew: broadcast is also a use case where you want to turn AEC off 09:05:39 martin: if the browser and user wants differents things, the user setting should win 09:06:36 stefanh: final slide - SDES 09:06:52 ... wait until RTCWeb has discussed this 09:06:54 ekr: yes 09:07:10 stefanh: that was easy 09:07:37 stefanh: summary slide 09:09:10 martin: you could get two different tracks - one with AEC and one without 09:10:34 dsinger has joined #webrtc 09:11:53 hta: new AoB (MC TF) to topic - Multiple open of camera/mic? 09:12:24 martin: AGC, NR should be fairly simple 09:12:57 burn: rather than doing this right now we should sumarize what we have decided the last hour and update the summary 09:13:23 hta: there are things that needs to be discussed and some that just can be edited in 09:13:31 Acoustic Echo Cancellation 09:13:34 DanD has joined #webrtc 09:13:56 stefanh: we're 15 minutes before schedule 09:14:41 tomoyuki has joined #webrtc 09:16:44 anant has joined #webrtc 09:17:27 coffee break 09:18:47 juberti_ has joined #webrtc 09:19:42 Hidetoshi has left #webrtc 09:19:48 kotakagi has joined #webrtc 09:19:48 hta has joined #webrtc 09:31:34 tomoyuki has joined #webrtc 09:36:57 tomoyuki has joined #webrtc 09:37:49 dom has joined #webrtc 09:38:53 -Rhone_1 09:39:11 juberti_ has joined #webrtc 09:39:51 zakim, who is on? 09:39:51 I don't understand your question, hta. 09:39:57 zakim, who is on the phone? 09:39:57 On the phone I see +44.190.881.aaaa 09:40:01 anant has joined #webrtc 09:40:51 anyone remote actually here? 09:41:24 zakim, call Rhone_1 09:41:24 ok, stefanh; the call is being made 09:41:25 +Rhone_1 09:41:41 burn has joined #webrtc 09:43:49 Stephane has joined #webrtc 09:49:24 jinhong has joined #webrtc 09:50:10 getting started, markus is the scribe 09:50:31 topic - SDP 09:50:50 fluffy showing slides 09:51:00 Hidetoshi has joined #webrtc 09:51:16 Ruinan has joined #webrtc 09:52:09 issues: what SDP do createOffer and createAnswer create and how they can be manipulated before passing them back to the browser 09:52:41 tomoyuki has joined #webrtc 09:53:01 DanD has joined #webrtc 09:53:46 matthew: some changes are ok from SDP syntax perspective but not for the browser to act upon 09:53:49 frodek has joined #webrtc 09:54:27 goals: clear definition of SDP and error handling rules 09:55:45 adambe has joined #webrtc 09:56:23 how are new ICE candidates added to the set SDP 09:57:29 Matthew: when I ask which SDP is in use is it the one I have set or can it be something slightly different? 09:58:09 gmandyam has joined #webrtc 09:58:20 constraints: can be used to enable common use cases, but do not solve what can be changed 09:58:28 nsakai has joined #webrtc 09:58:32 s/topic - SDP/topic: SDP handling/ 09:59:15 burn: constraints can affect what SDP gets generated in the first place so it does not need to be modified anymore 09:59:41 -Rhone_1 09:59:53 - +44.190.881.aaaa 09:59:55 UW_Web RTC()3:00AM has ended 09:59:55 Attendees were Rhone_1, +44.190.881.aaaa 10:00:08 (remote audio dropped) 10:00:21 kotakagi has joined #webrtc 10:00:31 UW_Web RTC()3:00AM has now started 10:00:39 + +44.190.881.aaaa 10:00:40 jinhong has joined #webrtc 10:01:05 fluffy: the place to define SDP use is in the JSEP draft - latest draft has a start 10:01:40 remote audio not working 10:02:03 Zakim, call rhone_1 10:02:03 ok, dom; the call is being made 10:02:05 +Rhone_1 10:03:42 matthew: state transitions need to be taken into account, can't call everything multiple times 10:05:45 wbat ca 10:06:14 specifically, setRemoteDescription("answer") is restricted to only-call-once even though we are saying that enforcement of these transitions is up to the JS 10:06:15 what can be changed between create* and setLocal/Remote 10:06:37 use cases: remove codec, change bw limit etc. 10:07:05 justin: enable/disable bundle is one case 10:07:42 adam: rejecting audio, getting video - is that with munging SDP? 10:08:02 fluffy: no, if we have explicit API then don't use SDP mungling 10:08:28 matthew: have a detailed set of cases 10:09:18 tomoyuki has joined #webrtc 10:09:28 fluffy: grouping of cases: 10:10:40 fluffy: don't do RTCP mux via settings, not SDP 10:11:00 matthew: ptime for codecs 10:11:12 matthew: want to fix it 10:12:26 jmarcon has joined #webrtc 10:12:37 matthew: will take my cases to the list 10:14:04 several people agree most things being discussed should be done via other mechanisms than changing SDP 10:14:55 dsinger has joined #webrtc 10:15:10 burn: nervous about limiting too much what in SDP can be modified 10:16:46 fluffy: changing SDP on the way between browsers can be done flexibly, changing between create* and set* in the same browser more limited 10:17:16 Bo_Chen has joined #WebRTC 10:17:58 justin: don't understand why there is big difference between different manipulation "loops" 10:19:37 wseltzer has joined #webrtc 10:20:00 fluffy: positive list of what can be changed is needed, not the list of what can't be 10:20:47 provide a list of changeable things that is *guaranteed* to work 10:21:11 kensaku has joined #webrtc 10:21:17 matthew: errors need to be specific on what is wrong 10:21:52 sakkuru has joined #webrtc 10:22:06 argument over what the current spec (JSEP?) says... 10:23:26 burn: many kinds of modifications will be needed before sending SDP out 10:23:44 tlr has joined #webrtc 10:23:55 burn: what you send out does not match with what you set with setLocal? 10:24:14 who was speaking? 10:24:43 stefanh has joined #webrtc 10:25:05 matthew: jsep-02 has fixed the ice password issue 10:25:40 fluffy: need to have the use cases that motivate changes 10:26:30 justin: needs coming up in the future anyway... 10:27:40 Wonsuk has joined #webrtc 10:27:44 how much and what state does createOffer create? devices with HW codecs? 10:28:02 jsep-02 fixed the "createOffer is optional" language, though whether or not createOffer creates state is true or not is questionable 10:28:36 tomoyuki has joined #webrtc 10:28:46 Suresh has joined #webrtc 10:29:11 matthew: though, there's clearly an implication of that b/c of the validity window of the offer. 10:29:23 i.e. during the callback. 10:30:09 indeed 10:31:00 martin: set down the list of things that MUST be possible to change 10:31:12 burn: is everything else MUST reject? 10:31:25 people have different interpretations... 10:33:13 explicit list of things that MUST be changeable, explicit list of things that MUST not be changed and what falls in between the browser need to explicitly error report if it won't support it 10:33:28 there is a list of things that we MUST be able to change; there is a list of things that MUST NOT be able to change, which trigger an error; everything else the browser MUST either accept or reject with an error 10:33:35 silent failure is incompatible with the assert on the 2nd slide. either the browser fires an error (invalidating the assert) or it is lying to you in order to make that assert. 10:34:20 the above three comments (markus, martin, matthew) try to record the consensus in the meeting 10:35:58 hsivonen has joined #webrtc 10:36:10 AndyHutton: Configuration/settings? how do they relate to the MUST, MUST NOT, ... 10:36:44 fluffy: start with the list of use cases to get the MUST-be-changeable list 10:37:39 Milan_Patel has joined #webrtc 10:37:56 matthew: listing MUST-items... 10:38:24 cullen taking notes... 10:38:58 adam: we will have APIs for some of these things anyway 10:39:17 Jim_Barnett has joined #webrtc 10:40:44 kotakagi has joined #webrtc 10:40:56 kotakagi2 has joined #webrtc 10:41:40 fluffy: if we have an API to control what createO/A gives, is that not enough, do we still need to change SDP for those "features" 10:41:59 justin, matthew: there may be cases where SDP change is still needed 10:43:11 fluffy: use cases are still not clear 10:45:03 burn: do not worry about MUST-list anymore because anything on the MUST NOT list can still work... 10:46:52 still sensing consensus on having three lists: 1. MUST be changeable, 2. MUST NOT be changeable, 3. (default) Browser MUST give an error if it does not support it 10:47:34 fluffy: next issue 10:47:51 when can two different video flows use the same m-line 10:48:38 Proposal: all codec parameters are the same, "content-label" is the same, are in same MediaStream 10:50:57 Stephane has joined #webrtc 10:51:04 (hta, fluffy, martin debate the details) 10:54:14 next: How does createOffer know to offer receiveOnly flow? 10:55:11 want to receive video but don't have video camera 10:57:20 kotakagi has joined #webrtc 10:57:46