IRC log of webrtc on 2014-04-28

Timestamps are in UTC.

15:52:00 [RRSAgent]
RRSAgent has joined #webrtc
15:52:00 [RRSAgent]
logging to http://www.w3.org/2014/04/28-webrtc-irc
15:52:02 [trackbot]
RRSAgent, make logs world
15:52:02 [Zakim]
Zakim has joined #webrtc
15:52:04 [trackbot]
Zakim, this will be RTC
15:52:04 [Zakim]
ok, trackbot; I see UW_WebRTC()12:00PM scheduled to start in 8 minutes
15:52:05 [trackbot]
Meeting: Web Real-Time Communications Working Group Teleconference
15:52:05 [trackbot]
Date: 28 April 2014
15:52:17 [dom]
Meeting: WebRTC teleconference
15:52:26 [dom]
Chair: stefanh, hta
15:52:38 [dom]
Agenda: http://lists.w3.org/Archives/Public/public-webrtc/2014Apr/0040.html
15:52:53 [dom]
dom has changed the topic to: WebRTC call April 28 RECORDED; Agenda: http://lists.w3.org/Archives/Public/public-webrtc/2014Apr/0040.html
15:55:13 [Zakim]
UW_WebRTC()12:00PM has now started
15:55:20 [Zakim]
+ +1.403.244.aaaa
15:55:22 [stefanh]
stefanh has joined #webrtc
15:56:33 [Zakim]
+[Microsoft]
15:56:45 [JimBarnett]
JimBarnett has joined #webrtc
15:56:45 [fluffy]
Zakim, I am aaaa
15:56:46 [Zakim]
+fluffy; got it
15:58:54 [Zakim]
+ +46.8.50.51.aabb
15:59:26 [Zakim]
+stefanh
15:59:26 [Zakim]
+Jim_Barnett
15:59:35 [fluffy]
are there any minutes of prev meeting we need to approve ?
15:59:44 [hta]
hta has joined #webrtc
15:59:53 [stefanh]
http://lists.w3.org/Archives/Public/public-webrtc/2013Dec/0081.html
15:59:56 [hta]
zakim, who is here?
15:59:56 [Zakim]
On the phone I see fluffy, [Microsoft], +46.8.50.51.aabb, stefanh, Jim_Barnett
15:59:58 [Zakim]
On IRC I see hta, JimBarnett, stefanh, Zakim, RRSAgent, Bernard, fluffy, jeff, timpanton, dom, adam, heath, stryx`, derf_, schuki, Josh_Soref_, timeless_, trackbot, decadance,
15:59:58 [Zakim]
... slightlyoff
16:00:02 [Zakim]
+gmandyam
16:00:08 [Zakim]
+ +aacc
16:00:10 [Zakim]
+ +91.22.39.14.aadd
16:00:10 [gmandyam]
gmandyam has joined #webrtc
16:00:11 [ekr]
ekr has joined #webrtc
16:00:12 [hta]
zakim, aabb is me
16:00:12 [Zakim]
+hta; got it
16:00:13 [Zakim]
+Milan_Patel
16:00:17 [ekr]
zakim, who is here?
16:00:17 [Zakim]
On the phone I see fluffy, [Microsoft], hta, stefanh, Jim_Barnett, gmandyam, +aacc, +91.22.39.14.aadd, Milan_Patel
16:00:20 [Zakim]
On IRC I see ekr, gmandyam, hta, JimBarnett, stefanh, Zakim, RRSAgent, Bernard, fluffy, jeff, timpanton, dom, adam, heath, stryx`, derf_, schuki, Josh_Soref_, timeless_, trackbot,
16:00:20 [Zakim]
... decadance, slightlyoff
16:00:39 [ekr]
Hmm… I have no idea which phone number it thinks I am
16:00:53 [ekr]
but in any case, I am on the phone
16:01:08 [Zakim]
+??P1
16:01:10 [DanD]
DanD has joined #webrtc
16:01:10 [dom]
Zakim, ??P1 is me
16:01:10 [Zakim]
+dom; got it
16:01:33 [Zakim]
+Dan_Druta
16:01:39 [ekr]
zakim, who is here?
16:01:39 [Zakim]
On the phone I see fluffy, [Microsoft], hta, stefanh, Jim_Barnett, gmandyam, +aacc, +91.22.39.14.aadd, Milan_Patel, dom, Dan_Druta
16:01:41 [Zakim]
On IRC I see DanD, ekr, gmandyam, hta, JimBarnett, stefanh, Zakim, RRSAgent, Bernard, fluffy, jeff, timpanton, dom, adam, heath, stryx`, derf_, schuki, Josh_Soref_, timeless_,
16:01:41 [Zakim]
... trackbot, decadance, slightlyoff
16:02:03 [ekr]
perhaps I am aacc, but without the previx, it is hard to tell.
16:02:06 [Zakim]
+??P16
16:02:15 [Zakim]
+??P8
16:02:28 [Zakim]
+ +46.1.07.14.aaee
16:02:28 [Zakim]
+Stephane_Cazeaux
16:02:30 [Zakim]
+[IPcaller]
16:02:46 [adambe]
adambe has joined #webrtc
16:02:54 [mreavy]
mreavy has joined #webrtc
16:03:07 [dan_romascanu]
dan_romascanu has joined #webrtc
16:03:11 [dom]
Zakim, aaee is probably adambe
16:03:12 [Zakim]
+adambe?; got it
16:03:12 [stephane]
stephane has joined #webrtc
16:03:18 [Zakim]
+??P4
16:03:25 [adam]
Zakim, I am ??P4
16:03:25 [Zakim]
+adam; got it
16:03:52 [Zakim]
+jesup
16:03:56 [Zakim]
+??P9
16:04:26 [Zakim]
+ +1.408.902.aaff
16:04:28 [dom]
Zakim, ??P9 is probably milan_patel
16:04:28 [Zakim]
+milan_patel?; got it
16:04:35 [stefanh]
Proposed agenda: http://lists.w3.org/Archives/Public/public-webrtc/2014Apr/0040.html
16:04:50 [jesup]
jesup has joined #webrtc
16:05:04 [Suhas]
Suhas has joined #webrtc
16:05:06 [ekr]
mt is here as well
16:05:21 [Zakim]
+ +1.214.414.aagg
16:05:34 [Zakim]
- +1.214.414.aagg
16:06:03 [Milan_Patel]
Milan_Patel has joined #webrtc
16:06:06 [Zakim]
+??P13
16:06:52 [dom]
ScribeNick: dom
16:06:55 [dom]
scribe: dom
16:06:57 [juberti]
juberti has joined #webrtc
16:07:09 [dom]
Topic: Admin
16:07:37 [stefanh]
Minutes: http://lists.w3.org/Archives/Public/public-webrtc/2013Dec/0081.html
16:07:58 [dom]
StefanH: approving minutes from our scoping meeting discussions on Dec 19?
16:08:09 [dom]
RESOLVED: Dec 19 minutes approved
16:08:20 [mt_]
mt_ has joined #webrtc
16:08:22 [jib]
jib has joined #webrtc
16:08:39 [mt]
mt has joined #webrtc
16:08:47 [dom]
Stefanh: [reviewing proposed agenda]
16:09:06 [Zakim]
+ +1.267.934.aahh
16:09:20 [dom]
Topic: May F2F agenda
16:09:29 [stefanh]
http://lists.w3.org/Archives/Public/public-webrtc/2014Apr/att-0045/DC_f2f_planning_WebRTC.pdf
16:09:29 [Zakim]
+ +1.425.610.aaii
16:09:33 [jib]
zakim, I am aahh
16:09:33 [Zakim]
+jib; got it
16:09:42 [dom]
-> http://lists.w3.org/Archives/Public/public-webrtc/2014Apr/att-0045/DC_f2f_planning_WebRTC.pdf Proposed agenda for May F2F
16:09:56 [dom]
stefanh: slide 2 describes the overall schedule of the 3 days meeting
16:10:06 [dom]
... mornings will be used by the IETF RTCWeb WG
16:10:08 [juberti]
Zakim, who's here?
16:10:08 [Zakim]
On the phone I see fluffy, [Microsoft], hta, stefanh, Jim_Barnett, gmandyam, +aacc, +91.22.39.14.aadd, Milan_Patel, dom, Dan_Druta, ??P16, ??P8, adambe?, Stephane_Cazeaux,
16:10:11 [Zakim]
... [IPcaller], adam, jesup, milan_patel?, +1.408.902.aaff, ??P13, jib, +1.425.610.aaii
16:10:11 [Zakim]
On IRC I see mt, jib, juberti, Milan_Patel, Suhas, jesup, stephane, dan_romascanu, mreavy, adambe, DanD, ekr, gmandyam, hta, JimBarnett, stefanh, Zakim, RRSAgent, Bernard, fluffy,
16:10:11 [Zakim]
... jeff, timpanton, dom, adam, heath, stryx`, derf_, schuki, Josh_Soref_, timeless_, trackbot, decadance, slightlyoff
16:10:20 [dom]
... we have the afternoons; the first one will be used by the Media Capture TF
16:10:46 [dom]
... Tuesday and Wednesday will be for the WebRTC WG, for which the chairs are proposing the agenda described on slide 3
16:11:01 [dom]
... Justin sent out an updated proposal for the "doohickey"
16:11:37 [ekr]
q+
16:11:37 [dom]
... [reviewing detailed agenda described on slide 3]
16:11:46 [dom]
... This is a strawman proposal on which we're seeking feedback
16:11:46 [juberti]
q+
16:11:49 [dom]
... incl on what we're missing
16:12:08 [dom]
cullen: I assume the doohickey will take more time than allotted
16:12:18 [dom]
... it would be good to come out of the meeting with a complete proposal
16:12:33 [dom]
ekr: I agree; we should steal time from admin and stats to add to doohickey
16:12:45 [dom]
... (e.g. leave only 15 min for admin and 15 min for stats)
16:13:03 [dom]
cullen: we have a spare hour on Tuesday, we may not need to steal any time
16:13:10 [dom]
hta: on stats: the API seems to be well agreed upon
16:13:19 [fluffy]
q?
16:13:20 [dom]
... but the actual stats have not been reviewed in details
16:13:26 [ekr]
q-
16:13:38 [dom]
... before the meeting, I'll make a proposal, incl. possibly moving them to a separate document
16:13:49 [dom]
... but the group needs to look through the stats
16:14:06 [dom]
ekr: I would suggest we do that by email, and only discuss controversial ones at the F2F
16:14:11 [dom]
hta: OK, makes sense to me
16:14:25 [dom]
juberti: +1, but I want to make sure we review them
16:14:39 [dom]
... overall, the agenda seems to match the topics we need to discuss
16:14:51 [dom]
... on error handling, I have a proposal on TURN server errors
16:14:59 [dom]
... not sure about what other things would need to be reviewed
16:15:05 [dom]
... Another item is review of scope
16:15:14 [dom]
... when can we declare victory?
16:15:24 [dom]
stefanh: to me, that's part of the schedule discussion
16:15:36 [dom]
juberti: but waiting till Wed. for that seems to be a recipe failure
16:15:43 [ekr]
I am indifferent to when we discuss it
16:15:46 [juberti]
q-
16:15:47 [dom]
... we should discuss it early one since that affects the rest of what we discuss
16:16:32 [dom]
hta: the meeting should be about decisions, after having made progress on the list
16:16:41 [dom]
... until we make progress on the list, I'm not sure how to progress here
16:16:51 [Zakim]
+ +1.703.628.aajj
16:17:07 [dom]
stefanh: we'll look more into when to schedule scoping based on that feedback
16:17:26 [dom]
... if the group agrees on the topics, we'll reach out to individuals to prepare each of them
16:17:37 [dom]
... for instance, the doohickey proposal will need to be hashed out on email
16:18:11 [dom]
hta: ideally, people charged with proposals would get the discussions started on the list well before the meeting
16:18:22 [dom]
... so that we can record our agreements at the meeting
16:18:41 [dom]
juberti: let's assign owners now
16:18:51 [dom]
stefanh: doohickey should be for justin, ok?
16:18:53 [dom]
juberti: will do
16:19:11 [dom]
stefanh: for error handling, we would like to constitute a small team
16:19:22 [dom]
... around ekr
16:19:26 [Zakim]
-milan_patel?
16:19:34 [dom]
... the idea would be to go through the spec and state where we are wrt error handling
16:19:47 [dom]
... hopefully most of it should be ok, but there should be proposals where we're not
16:19:54 [dom]
ekr: happy to do that
16:20:00 [dom]
stefanh: stats for hta?
16:20:02 [dom]
hta: yup
16:20:12 [dom]
stefanh: for identity, martin or ekr?
16:20:16 [dom]
ekr: I volunteer martin
16:20:25 [dom]
mt: works for me
16:20:42 [dom]
stefanh: for interop issues, we're suggesting Alexandre Gouaillard to drive this
16:20:53 [fluffy]
q+
16:21:09 [dom]
... alex has been very active in discussion groups on WebRTC implementation and has lots of experience there
16:21:17 [dom]
Alexandre: would be happy to prepare something for the meeting
16:21:36 [dom]
cullen: alex, could you describe some of the things you're thinking of for interop issues?
16:21:40 [ekr]
q+
16:21:44 [dom]
alexandre: e.g. the data channels
16:21:50 [dom]
... interop issues between FF and Chrome
16:22:00 [dom]
... a few more items that makes it hard
16:22:04 [ekr]
+1
16:22:16 [dom]
cullen: let's focus on where the spec leads to defects, rather than implementation bugs
16:22:19 [dom]
ekr: +1
16:22:37 [dom]
... 3 categories: really unclear spec, ambiguous spec, implementation bugs
16:22:44 [dom]
... only the first 2 are useful
16:23:02 [dom]
... the 2nd case is when reasonable people can interpret the spec differently
16:23:20 [dom]
Alexandre: agree we shouldn't discuss implementation bugs
16:23:48 [dom]
stefanh: for the schedule/scoping, this would be down to hta and me
16:24:11 [dom]
hta: it would perhaps be logical to move scoping to end of Tuesday
16:24:26 [dom]
... this topic can be very time consuming, so I want a timeboxed slot
16:24:42 [dom]
... end of Tuesday would probably work well, allowing also people to sleep over the discussions
16:24:48 [dom]
cullen: will there be a proposal ahead of time?
16:24:56 [dom]
hta: there will, otherwise we will cancel that agenda item
16:25:09 [dom]
Topic: Schedule and scoping
16:25:21 [dom]
scribenick: stefanh
16:25:58 [stefanh]
Dom: Last time we talked about scoping was on an earlier telco
16:26:28 [stefanh]
.....Last week I proposed a new way to scope: freeze what we have in the spec now, and move that to LC
16:26:45 [Zakim]
Zakim has left &webrtc
16:26:45 [ekr]
q+
16:26:46 [stefanh]
....additional stuff should be in separate documents.
16:27:10 [fluffy]
q-
16:27:23 [stefanh]
....We need to agree on that we need a scope, and secondly what is in and out of that scope.
16:27:35 [ekr]
could you please restate the proposal?
16:28:14 [stefanh]
Ekr: sound like we're having the DC discussion now
16:28:24 [stefanh]
Dom: no, trying to prepare us for DC
16:29:08 [stefanh]
Dom: first part of my proposal is to agree that we need to agree on that there is a set of features in v1 and features that are out
16:29:19 [fluffy]
q+
16:29:32 [stefanh]
....we need to agree that we need to freeze
16:30:00 [stefanh]
Ekr: Agree, but the spec is a subset of what we need before freezing, e.g. doohickeys
16:30:00 [juberti]
q+
16:30:17 [stefanh]
Hta: anything more than doohickeys
16:30:31 [stefanh]
ekr: I can produce a list
16:30:35 [dom]
ack ekr
16:30:43 [dom]
ack fluffy
16:30:48 [ekr]
q+
16:30:56 [stefanh]
cullen: the w3c process means freezing
16:31:19 [stefanh]
...the question is if we're close to the point when we can freeze
16:31:30 [stefanh]
....the other question is what we need to add
16:31:59 [stefanh]
Dom: We should done sooner rather than later, and that input was given by app developers.
16:32:44 [stefanh]
...at the meeting in May we need a list of items in v1.0, and I think it should not be much more than what is in the doc now.
16:33:01 [stefanh]
Cullen: do you think we have consensus to add doohickeys?
16:33:29 [stefanh]
Dom: have nothing against adding, but we should not add a dozen of more features.
16:34:26 [stefanh]
...can we agree that we can develop a list of features before the May?
16:34:44 [stefanh]
...what additional features are needed?
16:34:51 [dom]
ack juberti
16:34:56 [ekr]
q-
16:35:19 [stefanh]
Justin: I think we need doohickeys, stats, and turn error handling
16:36:08 [stefanh]
Dom: can we give out an action to start building a list?
16:36:27 [stefanh]
Justin: the data is out there, just look in mailboxes
16:37:22 [stefanh]
Justin: we need to have the discussion, but I will dig out the data we already have.
16:37:54 [dom]
dom has left &webrtc
16:38:17 [stefanh]
Harald: I will produce a proposal, but will take input from people having input to give.
16:38:35 [dom]
scribenick: dom
16:38:41 [stefanh]
End of schedule discussion.
16:38:55 [stefanh]
Next: Constraints in WebRTC
16:39:04 [dom]
Topic: Use of "constraint compromise" in WebRTC
16:39:17 [dom]
-> http://lists.w3.org/Archives/Public/public-webrtc/2014Apr/att-0048/ConstraintsPC-mt.pdf Martin's slides
16:39:40 [stefanh]
Martin: motivated by Suhas sending a proposal on doohickeys
16:39:40 [dom]
Martin: this was triggered by the discussion of what doohickeys might look like
16:39:48 [dom]
... I think it has some important points
16:40:00 [dom]
... not sure I agree with everything it it yet :)
16:40:10 [dom]
... [slide 3]
16:40:37 [dom]
... this is what we have to control the peer connection at this time
16:41:14 [dom]
... the RTCPeerConnection constructor, updateIce
16:41:25 [dom]
... the arguments for createOffer
16:41:44 [dom]
... you also get control surface via SDP modifications
16:41:54 [dom]
... still aspirational
16:42:03 [ekr]
mt, send a pull request for JSEP
16:42:19 [Zakim]
+??P37
16:42:25 [Zakim]
+??P39
16:42:48 [dom]
... addStream arguments
16:42:48 [Zakim]
-??P37
16:43:19 [dom]
... slide 4 describes the additional control surface provided by doohickeys
16:43:26 [dom]
... with track-specific control
16:43:49 [dom]
... e.g. distinguishing on-hold vs receive-only
16:44:26 [dom]
... it opens up a lot of other possibilities; could be used as a bus for more stuff, e.g. stats, state
16:44:29 [dom]
... [slide 5]
16:44:46 [dom]
... the existing control surface doesn't let you provide what's possible
16:44:57 [dom]
... nor what is currently being done
16:45:10 [dom]
... the control surface is "do X", but doesn't tell you whether X is occurring
16:45:10 [fluffy]
q+
16:45:27 [dom]
... these features are probably needed in a number of cases
16:45:40 [dom]
... we need to identify these
16:46:13 [dom]
cullen: doohickeys is bound to a given peer connection, independently on how many pc a track was added to
16:46:25 [dom]
martin: indeed
16:46:58 [dom]
cullen: in terms of capabilities discovery, we need to be careful that this is a negotiation between the local and remote ends
16:47:04 [lgombos]
lgombos has joined #webrtc
16:47:09 [dom]
martin: clearly
16:48:08 [dom]
... that's worth keeping in mind while we look to drawbacks of constraints where the constraints ability to negotiate among actors is not needed (as I claim)
16:48:21 [dom]
... which one was one of the origins of constraints for the camera API
16:48:49 [dom]
... (in addition to giving latitude to browsers in picking some values, which is also useful e.g. for bandwidth)
16:49:14 [dom]
... another drawback of constraints is that feature detection is not really possible
16:49:21 [Zakim]
+ +1.604.210.aakk
16:49:28 [dom]
... and there is less certainty about what browsers do
16:49:45 [Erik]
Erik has joined #webrtc
16:49:47 [Zakim]
-[IPcaller]
16:50:03 [dom]
... slide 7 shows how constraints would be used to detect capabilities (although the example is probably contrived here)
16:50:16 [dom]
... then apply, and check state
16:50:39 [dom]
... slide 8 shows the same without constraints
16:51:13 [dom]
... slide 9 looks at values where giving leeway to browsers would be useful
16:51:26 [timpanton]
q+
16:51:41 [fluffy]
q+
16:51:42 [dom]
... "advanced" type of settings allow for codependent settings
16:51:45 [fluffy]
q-
16:51:46 [fluffy]
q+
16:51:54 [dom]
ack tim
16:52:04 [dom]
q+ timpanton
16:52:05 [dom]
ack fluffy
16:52:09 [jib]
q+
16:52:13 [juberti]
q+
16:52:15 [dom]
cullen: this makes sense to me
16:52:35 [Suhas_]
Suhas_ has joined #webrtc
16:52:39 [dom]
... mute/unmute is something on which there is direct control
16:53:14 [dom]
... but resolution switching is more complex and would more likely benefit from a range of possible values
16:53:21 [dom]
... as allowed by constraints
16:53:36 [dom]
... I think it's probably the same set of things as in gUM
16:53:57 [dom]
martin: I'm starting to get that same conclusion myself, despite my initial violent reaction to that idea
16:54:06 [dom]
... constraints make more sense to me know
16:54:15 [ekr]
q+
16:54:26 [dom]
cullen: if we talk about maxBandwith instead of bandwidth, it becomes clearer this is more something like mute
16:54:29 [fluffy]
ack fluffy
16:54:44 [dom]
martin: @@@missed
16:55:07 [ekr]
I note that VideoEngine has minBandwidth
16:55:11 [jesup]
q+
16:55:14 [mt]
it was the point that we continually get requests for minimum bandwidth
16:55:15 [dom]
hta: the only sensible semantic of min bandwidth is "if congestion control tells me that I'm below that bandwidth, throw an error and stop sending"
16:55:28 [hta]
q?
16:55:34 [dom]
timpanton: when we first discussed constraints a very long time ago, we wanted to express them as aspirations
16:55:46 [hta]
q+
16:55:50 [dom]
... letting developers express what they want to achieve rather than direct the browser directly
16:56:12 [dom]
... if they want to emphasize e.g the speed of movement, developers should be able to express it
16:56:25 [dom]
... we've failed to develop a list that would match these aspirations
16:56:47 [dom]
... but it might be easier to look at this from a more abstract approach rather than looking at the bandwidth level
16:56:47 [Zakim]
+ +1.613.435.aall
16:56:58 [dom]
martin: there is definitely situations where you want to cap bandwidth
16:57:16 [dom]
... but in general, you're right; I think the other constraints match what you describe
16:57:20 [robin]
robin has joined #webrtc
16:57:31 [dom]
q- tim
16:57:31 [dom]
ack jib
16:57:51 [dom]
jib: I agree with martin's list of constraints drawbacks; it misses one:
16:57:55 [Zakim]
-??P39
16:57:56 [fluffy]
q+
16:58:15 [dom]
... constraints were designed in a space where you need to do as much as possible in a single call (before of the permission prompts)
16:58:21 [mt]
q+
16:58:49 [dom]
... given that we don't have this here, it seems to me we should limit ourselves to a more traditional approach where you make a call, get an error and then make another updated call
16:59:12 [dom]
... I think we should start simpler, e.g. with just settings
16:59:25 [dom]
... if it fails, then we move to the more complex solution
16:59:30 [dom]
ack juberti
16:59:34 [dom]
juberti: agree with jib
16:59:55 [dom]
... we've backed away on many fronts on constraints because of the complexity to bring to implementations
17:00:02 [dom]
s/to bring/it brings/
17:00:40 [dom]
... the fact that we don't have the one-shot limitation here means we likely don't need constraints
17:01:04 [dom]
... I'm strongly on the opinion we should have direct API enveloppe, and not use constraints unless we absolute need it
17:01:07 [dom]
ack ekr
17:01:12 [juberti]
q-
17:02:50 [dom]
ekr: independent settings design works for me, as long as we make sure that things that are not in fact independent are treated as such
17:03:07 [dom]
... e.g. framerate and bandwidth consumption
17:03:19 [dom]
juberti: if you set things in an inconsistent state, you would get an error
17:03:42 [mt]
x.maxBandwidth = 100; x.minBandwidth = 10000; // second fails
17:03:49 [dom]
ekr: in hardware codec, frame size, bandwidth and framesize are not independent properties
17:04:15 [dom]
... constraints leave more room to browsers for picking the right properties
17:04:16 [fluffy]
q?
17:04:18 [stefanh]
q?
17:04:27 [dom]
... I'll go back and see if this is really an issue
17:04:36 [dom]
jesup: I share some of ekr's concerns about this
17:04:56 [dom]
... esp. how would I deal with an error when I set these things independently
17:05:09 [dom]
... let's see what ekr comes up with
17:05:18 [ekr]
I'm not trying to obstructionist here.
17:05:27 [ekr]
If I can't come up with a number of good examples, I'll STFU
17:05:56 [JimBarnett]
we can add an applyConstraint call to Constrainable that sets/modifies a single property and leaves other constraints in place.
17:06:03 [dom]
... when there is not enough bandwidth, apps may adapt differently (e.g. drop some streams)
17:06:20 [JimBarnett]
If it's just a question of API simplicity (for the app developer - not the UA)
17:06:31 [dom]
... one of the downside is distinguishing bandwidth vs quality, which is hard
17:06:35 [dom]
hta: I'm getting a déjà-vu from 2 years ago
17:06:46 [mt]
q?
17:06:49 [mt]
ack jesup
17:06:52 [mt]
ack hta
17:07:06 [dom]
... we had the same discussion; the big argument was that, when you want to change the state of something, you have to change everything at once
17:07:28 [dom]
... because of changing one thing at a time may lead you to inconsistent states
17:07:44 [dom]
... the argument was to set all these things at once
17:08:17 [dom]
... if we expose a 100 knobs with a "apply" step with ad-hoc rules on inconsistent state sounds scary
17:08:41 [dom]
... constraints seems like a reasonable approach to describe what you want and let the browsers deal with the complexity
17:08:49 [jib]
q+
17:09:05 [dom]
... the main motivation for constraints was to avoid these meaningless microstates or these ad-hoc processes
17:09:24 [dom]
cullen: the resolution + aspect ratio + framerate is a good example
17:09:38 [dom]
... I agree we don't want a more complicated mechanism that we need
17:09:48 [dom]
... I disagree with the prompt claim
17:10:18 [dom]
... what you request through the doohickey may trigger a permission prompt to the other end, with a possible human intervention
17:10:28 [dom]
s/the prompt/the no-prompt/
17:10:58 [dom]
... if you think we don't need constraints here, I don't understand why we would need them in gUM
17:11:03 [Zakim]
-gmandyam
17:11:20 [juberti]
q+
17:11:31 [dom]
... we're talking about reserving resources which are not completely independent
17:11:34 [dom]
ack fluffy
17:11:48 [ekr]
q+
17:11:58 [lgombos]
lgombos has joined #webrtc
17:12:03 [Suhas]
ack
17:12:11 [dom]
ack mt
17:12:15 [fluffy]
q+
17:12:17 [fluffy]
q-
17:12:22 [ekr]
So I assume that the way this behaves is that if you do something that would require extra offers
17:12:24 [ekr]
that you can do:
17:12:32 [ekr]
frob, frob, frob, frob: createOffer()
17:12:35 [dom]
martin: jib pointed out that gum has a commitment due to user prompt
17:12:53 [dom]
... I think you get the same kind of commitment with the SDP blob that gets sent over
17:13:05 [dom]
... that's what tipped me over to constraints
17:13:13 [dom]
... it sucks, but the bar has been set pretty low
17:13:30 [dom]
... we don't want to use constraints for everything (e.g. send/no send)
17:13:38 [stefanh]
ekr, each "frob" would generate a "negotiatinneeded" event
17:13:46 [ekr]
stefanh: agreed
17:13:47 [mt]
q-
17:13:50 [dom]
... but for things that need to be negotiated and where browsers could use leeway, constraints are teh best things we have for the moment
17:13:50 [ekr]
but I hope you could ignore them
17:14:05 [fluffy]
So to summrize Martin, for things wehre constraints make snese becuase we negotaiton or changes by browser at run time, constraints make sense. For things like sending / notSending, they do not.
17:14:08 [dom]
ack jib
17:14:10 [jeff]
jeff has joined #webrtc
17:14:10 [jeff]
jeff has joined &webrtc
17:14:12 [dom]
Zakim, close the queue
17:14:12 [Zakim]
ok, dom, the speaker queue is closed
17:14:16 [fluffy]
And I am +1 on what Martin
17:14:27 [dom]
jib: constraints don't have the monopoly of settings multiple things at once
17:14:33 [dom]
... you get that from simple dictionaries
17:14:44 [dom]
... I think constraints may mean different things to different people
17:15:01 [stefanh]
ekr, yes you can ... I was thinking about a badly designed app that would just listen to all of them and do createOffer setLocal.......
17:15:16 [dom]
... cullen, is the person on the other side a separate actor? are we sure we need e.g. overconstrained events?
17:15:16 [ekr]
stefanh: that would be a sad app
17:15:20 [dom]
cullen: I'm sure we do
17:15:31 [dom]
jib: let's try it both ways as an experiment
17:15:31 [stefanh]
yes, but we will see those too
17:15:59 [dom]
... given the complexity of constraints, I think we need to look into alternatives
17:16:03 [stefanh]
ekr: but I may be wrong - thinking out loud
17:16:16 [dom]
... I don't think we need a full and/or set of settings for dealing with these codependencies
17:16:20 [stefanh]
q?
17:16:28 [dom]
cullen: send something away, and I'll explain where I think it doesn't work
17:16:41 [dom]
jib: I suggest we look at the two approaches and compare
17:17:12 [dom]
juberti: I don't think we need the entire constraints syntax to deal with the dependency between framerate/resolution
17:17:28 [dom]
... the other things we've talked about (send/no-send, bitrate, ...) don't seem to need constraint
17:18:03 [dom]
... I would rather find ourselves try the simple way, fail and move to constraints, rather than start form the assumption we definitely need it
17:18:08 [dom]
ack juberti
17:18:11 [dom]
ack ekr
17:18:35 [dom]
ekr: I think we have the two proposals matching jib's
17:18:41 [dom]
... suhas and justin
17:19:03 [dom]
cullen: suhas covers more stuff than would need to be covered by constraints
17:19:38 [dom]
ekr: cullen has a use case where he claims you need constraints
17:19:46 [dom]
... if you can disprove that, do it
17:20:19 [dom]
jib: I think we should start from scratch, and see if we end up identifying needs that constraints fulfill
17:20:40 [dom]
cullen: how do you deal with constraints set on one side and not the other?
17:20:47 [Zakim]
-Stephane_Cazeaux
17:20:49 [dom]
... I think you're pushing for removing constraints from gum
17:20:56 [ekr]
q+
17:21:12 [hta]
Q?
17:21:14 [dom]
jib: I don't see it that way; we're reusing constraints because we have it, not because we need it
17:21:38 [fluffy]
q?
17:21:38 [dom]
cullen: the resolution/bandwidth use case exists, you can't simply wish it away
17:21:45 [dom]
jib: I'm not wishing it away
17:21:58 [juberti]
I think this use case can be handled, without constraints.
17:22:44 [dom]
ekr: two possible position: we don't need a bulk-setting mechanism (constraints being one of various options); we need a resolution-conflict mechanism, but constraints aren't it
17:22:56 [dom]
... justin's point is the former, that seems possible
17:23:03 [dom]
... 2nd one seems crazy to me
17:23:14 [dom]
... does the browser need to resolve conflicts?
17:23:31 [dom]
hta: let's move this to the list, consensus is not emerging on this
17:23:32 [Zakim]
+Stephane_Cazeaux
17:23:36 [dom]
Topic: Privacy & Security
17:23:51 [stefanh]
I've had a look
17:23:54 [dom]
hta: I sent a proposal for a privacy & security section in WebRTC
17:24:02 [dom]
... has anyone looked at this?
17:24:11 [dom]
[several]: glanced at it briefly only
17:24:25 [dom]
hta: is it good enough to put it in a draft?
17:24:37 [dom]
... please take a look and send comments to the list
17:24:55 [dom]
Topic: AOB
17:25:18 [dom]
[crickets]
17:25:31 [dom]
stefanh: actions I noted
17:25:33 [dom]
... harald will propose a scope list with input from others
17:25:39 [dom]
... ekr will lead error handling for F2F
17:25:41 [dom]
... hta stats
17:25:45 [dom]
... martin identity
17:25:48 [dom]
... alex interop
17:25:51 [dom]
... justin doohickey
17:26:08 [dom]
hta: some people have promised to do stuff around constraints
17:26:28 [dom]
... cullen promised to show one use case that can be satisfied with only settings (I think?)
17:26:32 [dom]
cullen: don't remember having said that, but OK
17:26:56 [dom]
juberti: should we focus on the core doohickey stuff in place and see the settings/constraints stuff later?
17:27:08 [dom]
... or are they too intertwined?
17:27:26 [dom]
hta: I suggest doing the non-intertwined core first sounds reasonable
17:27:40 [dom]
cullen: I think the resolution/bandwidth needs to be part of what doohickeys solve
17:27:44 [dom]
... independently of how
17:27:47 [Zakim]
- +aacc
17:27:55 [Zakim]
-??P8
17:27:59 [Zakim]
-Jim_Barnett
17:28:01 [Zakim]
-hta
17:28:02 [Zakim]
-adam
17:28:02 [Zakim]
- +1.703.628.aajj
17:28:02 [Zakim]
-dom
17:28:03 [Erik]
thanks dom
17:28:04 [Zakim]
- +1.408.902.aaff
17:28:04 [Zakim]
-adambe?
17:28:05 [Zakim]
-Milan_Patel
17:28:05 [Zakim]
-Dan_Druta
17:28:07 [Zakim]
-stefanh
17:28:07 [Zakim]
-jesup
17:28:08 [Zakim]
-Stephane_Cazeaux
17:28:08 [Zakim]
-??P13
17:28:12 [Zakim]
- +1.604.210.aakk
17:28:15 [Zakim]
- +1.613.435.aall
17:28:17 [Zakim]
-jib
17:28:33 [Zakim]
- +1.425.610.aaii
17:28:34 [Zakim]
-fluffy
17:28:45 [dom]
RRSAgent, make log public
17:29:14 [dom]
Zakim, who's on the call?
17:29:14 [Zakim]
On the phone I see [Microsoft], +91.22.39.14.aadd, ??P16
17:29:20 [dom]
Zakim, drop ??P16
17:29:20 [Zakim]
??P16 is being disconnected
17:29:21 [Zakim]
-??P16
17:29:23 [dom]
Zakim, drop [Micr
17:29:23 [Zakim]
[Microsoft] is being disconnected
17:29:25 [Zakim]
-[Microsoft]
17:29:27 [dom]
Zakim, drop aadd
17:29:27 [Zakim]
+91.22.39.14.aadd is being disconnected
17:29:28 [Zakim]
UW_WebRTC()12:00PM has ended
17:29:28 [Zakim]
Attendees were +1.403.244.aaaa, [Microsoft], fluffy, +46.8.50.51.aabb, stefanh, Jim_Barnett, gmandyam, +aacc, +91.22.39.14.aadd, hta, Milan_Patel, dom, Dan_Druta, +46.1.07.14.aaee,
17:29:28 [Zakim]
... Stephane_Cazeaux, [IPcaller], adambe?, adam, jesup, +1.408.902.aaff, milan_patel?, +1.214.414.aagg, +1.267.934.aahh, +1.425.610.aaii, jib, +1.703.628.aajj, +1.604.210.aakk,
17:29:29 [Zakim]
... +1.613.435.aall
17:29:38 [dom]
Zakim, bye
17:29:38 [Zakim]
Zakim has left #webrtc
17:29:43 [dom]
RRSAgent, bye
17:29:43 [RRSAgent]
I see no action items