07:42:15 <RRSAgent> RRSAgent has joined #webrtc
07:42:15 <RRSAgent> logging to http://www.w3.org/2016/09/22-webrtc-irc
07:42:37 <Zakim> Zakim has joined #webrtc
07:42:46 <vivien> RRSAgent, make logs public
07:43:27 <vivien> Meeting: WebRTC F2F Day 1
07:48:22 <dom> dom has joined #webrtc
07:50:33 <vivien> Agenda: https://www.w3.org/2011/04/webrtc/wiki/September_22_-_23_2016#Agenda
07:50:50 <vivien> Chair: Harald, Stefan
07:51:36 <vivien> agenda+ WebRTC PC - Queing and order of operations, negotiation needed
07:52:05 <vivien> agenda+ WebRTC PC - Errors (not) thrown
07:52:15 <kinjim> kinjim has joined #webrtc
07:53:12 <vivien> agenda+ WebRTC PC - Events not defined
07:57:21 <hta1> hta1 has joined #webrtc
07:57:23 <Hiroki> Hiroki has joined #webrtc
07:57:54 <kotakagi> kotakagi has joined #webrtc
07:58:19 <wonsuk> wonsuk has joined #webrtc
07:59:22 <frodek> frodek has joined #webrtc
07:59:55 <jib> jib has joined #webrtc
08:01:19 <Hiroki__> Hiroki__ has joined #webrtc
08:01:42 <Hiroki__> Hiroki__ has left #webrtc
08:02:01 <adamR> adamR has joined #webrtc
08:02:49 <Shijun> Shijun has joined #webrtc
08:03:41 <vivien> agenda+ mediacapture-main - Interactions between Permissions and Media: State of play
08:03:55 <vivien> agenda+ mediacapture-main - Issues to resolve
08:03:58 <adambe> adambe has joined #webrtc
08:04:05 <vivien> agenda+ mediacapture-main - Test suite status
08:04:14 <vivien> agenda+ mediacapture-depth
08:04:48 <vivien> agenda+ mediacapture-output
08:04:58 <vivien> agenda+ Getting other docs to CR
08:05:17 <kotakagi> kotakagi has left #webrtc
08:06:09 <adamR_> adamR_ has joined #webrtc
08:06:36 <jesup> jesup has joined #webrtc
08:07:21 <dom> Topic: Intro
08:07:28 <vivien> present+ Andy, Bernard, DanB, Jan-Ivar, AdamB, Dom, AdamR, Cullen, Stefa, Harald, Vivien, Taylor
08:07:36 <vivien> s/Stefa/Stefan/
08:07:47 <dom> Hta: the aim of the group is now to get WebRTC 1.0 out of the door, get it to CR state as soon as we can
08:07:54 <dom> ... so that we can say we have completed this task
08:07:57 <mreavy> mreavy has joined #webrtc
08:08:10 <dom> ... we have other documents that we will talk about after lunch today that also need to be completed
08:08:14 <dom> ... the media capture stuff
08:08:46 <burn> burn has joined #webrtc
08:08:47 <dom> Stefan: High level agenda: we're gonna start this morning by hammering issues about peer connection
08:09:00 <vivien> present+ Peter
08:09:14 <dom> ... this afternoon we will focus on media capture documents; mainly getUserMedia, but also depth and audio output
08:09:28 <dom> ... Friday, morning will focus on sender/receiver, dtmf and stats
08:09:54 <dom> ... In the afternoon, we will discuss the certificate and IdP stuff with EKR joining us at 1pm sharp
08:09:58 <dom> ... then ICE, test suite and summary
08:10:25 <dom> ScribeNick: dom
08:10:41 <vivien> Remote participant: Sung-Young Son
08:11:17 <dom> Topic: PeerConnection issues
08:11:23 <dom> Topic: Issue 782
08:11:35 <Kangchan> Kangchan has joined #webrtc
08:11:38 <dom> -> https://github.com/w3c/webrtc-pc/issues/782 pc.createOffer(); pc.addTrack(track); should not include track
08:12:01 <dom> AdamB: the crux of this is to make it consistent what ends up in an offer
08:12:09 <dom> ... there is a pull request that proposes a solution for this
08:12:26 <dom> ... right now we have split up createOffer step in a set of synchronous steps and a set of queued steps
08:12:39 <vivien> present+ Frode_Kileng
08:12:52 <RRSAgent> I have made the request to generate http://www.w3.org/2016/09/22-webrtc-minutes.html vivien
08:12:59 <dom> ... if we bundle the set of tracks in the synchronous steps, we get the agreed upon effect
08:13:22 <dom> Cullen: that behavior seems surprising to me
08:14:07 <dom> JIB: we've had users confused that tracks added after createOffer were included in the negotiation
08:14:10 <adambe> adambe has joined #webrtc
08:14:33 <dom> ... the main thing is to have it predictable
08:14:58 <dom> ... even if that particular pattern is not something that is particularly expected to be used
08:15:26 <achronop> achronop has joined #webrtc
08:15:26 <adambe> adambe has joined #webrtc
08:15:52 <vivien> -> https://docs.google.com/presentation/d/1bs-UP1Wge-RuweB0b3DgR4pmlmuBc2SwWb0G3D36jG4/edit#slide=id.p Slides (google docs)
08:15:57 <dom> Cullen: I still think this is a surprising behavior for an asynchronous operation
08:16:05 <RANG_LEE> RANG_LEE has joined #webrtc
08:16:10 <vivien> present+ AlexG
08:16:59 <dom> JIB: now that we have that proposal, I think this is predictable
08:17:39 <dom> AdamR: people shouldn't do this; this works, I don't think it's worth discussing it so much
08:17:47 <dom> Cullen: but then we should do it for all our async calls
08:17:59 <dom> PeterT: I'm not sure this is worth all this complexity
08:18:21 <dom> AdamR: what does our implementation do at the moment?
08:18:23 <dom> JIB: it's complicated
08:18:29 <DrAlexG> DrAlexG has joined #webrtc
08:18:34 <dom> ... right now we always queue createOffer
08:18:38 <dom> ... and we have bugs
08:18:46 <RRSAgent> I have made the request to generate http://www.w3.org/2016/09/22-webrtc-minutes.html vivien
08:18:55 <dom> ... it may depends on whether this is the first session or not
08:20:08 <Kangchan> Kangchan has joined #webrtc
08:21:09 <dom> DanB: what would be a dev expect when writing such a code?
08:21:09 <dom> Dom: this is an anti-pattern of programming; the only thing we need is predictable outcome
08:22:31 <dom> AdamB: if addTrack was promise-based, we wouldn't have that issue
08:22:50 <dom> PeterT: the fundamental problem is for addTrack that returns synchronously
08:23:49 <dom> AdamB: one part of the question is whether there are other methods that would need this handling
08:24:00 <dom> ... I don't think there are other places than createOffer/Answer
08:24:20 <dom> JIB: I like this overall, but am concerned when the queue is empty
08:24:37 <dom> ... and PeterT's concern is relevant
08:25:11 <dom> PeterT: even if we agree we want this behavior, I've commented on the Pull Request; we can improve the description of the behavior
08:25:47 <dom> ... I'm still not sure this is worth the effort though
08:26:12 <dom> JIB: I think we need: syncrhonous steps, queue synchronous steps, and then queued asynchronous steps
08:26:21 <dom> s/queue /queued /
08:26:37 <dom> ... I think we can massage the PR to do that
08:27:10 <dom> HTA: JIB, will you write the test case to reflect this?
08:27:13 <dom> JIB: I will
08:27:21 <dom> ... and work with AdamB to update the PR
08:27:46 <dom> PeterT: whatever change we make, createAnswer needs to be consistent
08:28:29 <dom> HTA: it seems like everyone is willing to live with this behavior, given that we need consistent behavior
08:28:48 <dan> dan has joined #webrtc
08:28:49 <dom> PeterT: I'm not sure I'm willing to live with adding complexity to the spec
08:29:09 <dom> HTA: but what's the alternative that achieves consistant behavior?
08:29:22 <dom> PeterT: what about the other direction?
08:29:30 <dom> ... when the second-added track gets added to the offer
08:30:57 <dom> Dom: not clear that this is less complex
08:32:12 <dom> JIB: I think it also much more likely to be race-y
08:33:12 <dom> DanB: let's maybe get these people to work together and revisit it tomorrow
08:33:21 <dom> Topic: Issue 787
08:33:33 <dom> -> https://github.com/w3c/webrtc-pc/issues/787 Integrate RTCRtpTransceiver into set local/remote steps
08:34:20 <dom> AdamB: we need to integrate the transceivers in createA/O and setL/RD
08:34:29 <dom> ... JSEP has already pretty good text on this aspect
08:35:08 <dom> ... I've written up a proposal to use a provisional mid
08:35:36 <dom> ... which gets discarded if a transceiver gets it from the remote side
08:35:48 <dom> PeterT: why do we need a provisional mid?
08:36:03 <dom> AdamB: if we do addTrack and then createOffer
08:36:21 <dom> PeterT: the mid is generated but not shown in the object until setL/RD
08:36:49 <dom> ... this feels like this is something that only needs to be specified in JSEP
08:37:33 <vivien> [ FYI, The WebEx session is now being recorded ]
08:37:46 <dom> AdamB: when setLD has succeeded, we need a mid — so the idea is that we get it from JSEP
08:38:18 <dom> ... I'll work on a PR in that direction
08:38:34 <dom> Bernard: we just need to refer to the right JSEP section
08:39:26 <vivien> present+ Maire_Reavy_(webex), Alex_Chronopoulos_(webex), Randell_Jesup_(webex), Shijun_Sun_(webex)
08:39:41 <dom> AdamB: so the PR is essentially a reference to JSEP that explains that it defines how the mid gets defined
08:39:58 <dom> Topic: Issue 645
08:40:13 <dom> -> https://github.com/w3c/webrtc-pc/issues/645 public negotiation-needed flag as readonly
08:40:24 <Kangchan> Kangchan has joined #webrtc
08:40:42 <dom> AdamB: we got the request to expose the negotiation-needed flag as a public read only attribute
08:41:14 <dom> ... I'm not sure I'm convinced by the arguments
08:41:29 <dom> JIB: we do expose other states for which we have events
08:41:45 <dom> AdamB: but these other states are more than just boolean
08:42:16 <dom> ... my proposal is to do nothing
08:42:53 <dom> JIB: if you add tracks and data channels not in the same event loop, you might have a race condition with the negotiated-needed event
08:43:56 <dom> PeterT: if we were to have this, we need to be careful with when the state is set
08:44:03 <olivexu> olivexu has joined #webrtc
08:44:05 <dom> JIB: but that's we already do with other events
08:45:14 <dom> Dom: feels to me that this is a new feature that doesn't solve critical use cases; and we don't do new features at this point
08:46:58 <dom> AdamB: are we clear on whether we send negotiation needed every time or just when the state changes?
08:47:52 <dom> AdamR: the spec is clear - it's only when it changes
08:49:35 <dom> [more discussion that this may not be as clear]
08:49:51 <dom> HTA: a test case would help determine the negotiation needed behavior
08:49:59 <dom> AdamB: I can take a stab at it
08:50:01 <dom> JIB: will help
08:50:20 <dom> Dom: so the conclusion is "no" to 645 but we may need to clarify the negotiation needed behavior
08:50:23 <dom> Topic: Issue 746
08:50:36 <dom> -> https://github.com/w3c/webrtc-pc/issues/746 Need to specify what happens if `createDataChannel` is called with an invalid ID
08:50:53 <dom> Taylor: there are a number of cases where you can have an invalid id for the data channel
08:51:50 <Jinho> Jinho has joined #webrtc
08:52:20 <dom> [looking at example on slide 13]
08:53:51 <dom> Taylor: My proposal is to indicate the error in both cases with the onerror event
08:54:26 <dom> JIB: the 65535 case is always an error
08:54:50 <dom> PeterT: we need a way to signal the case when we gave you a data channel but don't have any id left to associate with it
08:55:03 <dom> Cullen: onerror seems pretty reasonable
08:55:50 <dom> HTA: do we need to discuss what to put as error?
08:55:56 <dom> Dom: we'll find something in WebIDL
08:56:02 <dom> Taylor: do we need to?
08:56:09 <dom> Dom: we need to have a defined name
08:56:13 <dom> Topic: Issue 727
08:56:25 <dom> -> https://github.com/w3c/webrtc-pc/issues/727 removeTrack: throw exception if sender is not in connection's set of senders
08:57:04 <dom> Taylor: the proposal here is to throw an exception when trying to remove a sender from the wrong peer connection object
08:57:15 <dom> Cullen: this sounds reasonable
08:57:21 <dom> JIB: wouldn't be hard to implement either
08:58:00 <dom> [consensus we should do this]
08:58:07 <dom> Stefan: will you also write the test case, taylor?
08:58:10 <fluffy> fluffy has joined #webrtc
08:58:11 <dom> Taylor: sure
08:58:16 <dom> Toipc: Issue 526
08:58:34 <dom> -> https://github.com/w3c/webrtc-pc/issues/526 NetworkError event is not defined and might not be needed
08:59:04 <dom> AdamB: we have this NetworkError in the spec that we don't define and that we fire when the transport of a data channel is closed with a failure
08:59:31 <dom> ... that behavior is borrowed from Web Sockets; they only fire a simple error event, and then a close event with more info
09:00:05 <adamR> adambe: https://www.w3.org/TR/dom/#error-names-0
09:00:08 <dom> Cullen: the underlying issue is that we have lots of errors where we don't give information about the reason errors
09:00:24 <dom> AdamB: we brought this to the WebIDL meeting yesterday
09:00:57 <dom> ... and they recognized the issue and said they would fix it
09:01:55 <dom> Cullen: 50% of our errors need more information, and standardized information
09:02:22 <dom> Bernard: there are lots of stuff missing
09:02:46 <adamR> adambe: Rather, https://www.w3.org/TR/WebIDL-1/#idl-DOMException-error-names
09:03:38 <dom> HTA: the WebIDL model is that errors are simple events
09:04:26 <dom> JIB: browsers don't behave the same in error reporting already e.g. on the error stack
09:04:39 <dom> Cullen: are you really proposing we don't standardize error reporting?
09:05:22 <dom> AdamB: in this specific case, the problem arises from our difference with Web Sockets - they have a close event with a message
09:05:43 <dom> JIB: in general, it seems like we should not diverge from Web Sockets
09:06:01 <dom> AdamR: FWIW, there is "NetworkError" in WebIDL
09:07:01 <dom> RESOLUTION: we will change our close event to match with Web Sockets
09:07:38 <dom> HTA: right now, we're not planning to do work on the bag of errors issue?
09:08:06 <dom> ... the WebIDL folks indicated they wanted to bring it to EcmaScript, which may take a lot of time
09:08:47 <dom> Cullen: I think we need to discuss this in more depth
09:12:22 <thp> thp has joined #webrtc
09:22:06 <Shijun> Shijun has joined #webrtc
09:27:48 <frodek> frodek has joined #webrtc
09:27:58 <kazho> kazho has joined #webrtc
09:33:06 <fluffy> fluffy has joined #webrtc
09:34:37 <jesup> The room seems to have hung up....
09:34:55 <jesup> fluffy: ^
09:35:07 <thp> It was pretty in-audible anyhow.
09:35:33 <jesup> Weren't they still in coffee break?
09:36:04 <fluffy> Back from coffee break in 5 min
09:37:12 <vivien> jesup, you are right
09:37:25 <vivien> rejoining now
09:39:35 <vivien> jesup, we are back (even if still in break)
09:41:08 <vivien> present+ Tim_Panton_(webex)
09:43:59 <adamR> adamR has joined #webrtc
09:44:01 <burn> zakim, who's here?
09:44:01 <Zakim> Present: Andy, Bernard, DanB, Jan-Ivar, AdamB, Dom, AdamR, Cullen, Stefa, Harald, Vivien, Taylor, Peter, Frode_Kileng, AlexG, Maire_Reavy_(webex), Alex_Chronopoulos_(webex),
09:44:05 <Zakim> ... Randell_Jesup_(webex), Shijun_Sun_(webex), Tim_Panton_(webex)
09:44:05 <Zakim> On IRC I see adamR, fluffy, frodek, Shijun, thp, Jinho, olivexu, dan, adambe, achronop, burn, mreavy, jesup, wonsuk, hta1, kinjim, Zakim, RRSAgent, anssik, vivien, jihye, kaku,
09:44:05 <Zakim> ... mt_____, timeless, Josh_Soref, derf, miguelao, slightlyoff, decadance, geheimnis`, stryx`, pehrsons, trackbot
09:45:06 <oh9405> oh9405 has joined #webrtc
09:45:18 <dom> dom has joined #webrtc
09:45:26 <wonsuk> wonsuk has joined #webrtc
09:45:39 <DrAlexG> DrAlexG has joined #webrtc
09:46:15 <vivien> present+ Sung-Young_Son_(webex)
09:46:34 <hta1> present+ Harald Alvestrand
09:46:52 <dom> ScribeNick: DrAlexG
09:47:00 <DrAlexG> jib talking
09:47:05 <dom> Topic: Interactions between Permissions & Media: State of play
09:47:15 <DrAlexG> ... there is this new thing called permission specs
09:47:38 <DrAlexG> it started as an API, but it evolved into that. Query() to read states for permissions.
09:47:49 <jlee27> jlee27 has joined #webrtc
09:47:54 <DrAlexG> ... prompt / granted / denied are the return vlues
09:48:04 <DrAlexG> ... that control access to the camera / mic
09:48:20 <DrAlexG> ... separate to that we have the permission to use the algorithm which return only granted or denied
09:48:50 <DrAlexG> ... is the permission is set to prompt (default) you have to ask the user ,otherwise, you return whatever the value is
09:49:30 <DrAlexG> ... the UA may update the value. The permission specs is not completely explicit on the HOW, and that s because each browser can behave slightly differently (that explains the MAY)
09:50:00 <DrAlexG> ... the behavior between HTTP and HTTPS is explicated in the spec, and i won trepeat it here, but there are some flexibility
09:50:10 <DrAlexG> .. the impact is that, it messes up our language a little bit.
09:50:25 <DrAlexG> ...we used to have temporary permission and stored permissions.
09:50:48 <DrAlexG> ... some users requested that the UA gives visibility to those stored values [just like cookies]
09:51:06 <DrAlexG> ... now we have three different permission: per use, per round, and persistent per origin
09:51:11 <DrAlexG> .. the last t wo are HTTPS only
09:51:16 <DrAlexG> ... any question on that ?
09:51:29 <DrAlexG> cullen speaking
09:51:41 <DrAlexG> ... per round means per refresh kind of thing?
09:51:44 <DrAlexG> jib speaking
09:52:22 <DrAlexG> ... yes. Permission are persistent until the end of the page. It is already defined in the permission Spec.
09:52:42 <DrAlexG> stefan: the permission spec also introduce the "settings" part
09:52:56 <DrAlexG> dom: why per round is only for https?
09:53:05 <DrAlexG> jib speaking
09:53:10 <dom> s/per round/per realm
09:53:22 <dom> s/per round/per realm/g
09:54:06 <DrAlexG> .... permission spec try to standardize that in explaining what the UA can / cannot do. UA can do whatever it wants as long as it fits the user intend (and that is not defined anywhere). It cannot however use any info ration over http.
09:54:14 <DrAlexG> ... since http is intrinsically insecure.
09:54:36 <DrAlexG> jib: next slide
09:55:19 <DrAlexG> ... issues to resolve. long threaded
09:55:57 <vivien> -> https://github.com/w3c/mediacapture-main/issues/387 Reinstate strong language on permission ending when tracks stop, lost by editorial mistake #387
09:55:57 <DrAlexG> ... #387: the spec has a privacy problem.
09:57:32 <DrAlexG> ... discussion on freedom of implementation, while behavior (ask the user) is standardized.
09:57:51 <vivien> -> https://github.com/w3c/mediacapture-main/issues/389 Camera light and "disabled" tracks #389
09:59:49 <DrAlexG> ... one way to address this would be to implement the per-use permission rule.
10:00:02 <DrAlexG> ... we should at least revisit our intend.
10:00:11 <DrAlexG> ... that was only discussed in washington DC in 2014
10:00:28 <hta1> s/only// (we discussed it at many other times)
10:02:23 <DrAlexG> ... discussing visual indicators in the UA, with screenshots from chrome
10:03:10 <DrAlexG> cullen: i assume the desire behavior would be: if I pause video, the red indicator on the tab would stay because i m still getting audio, but the cam led would go off.
10:03:23 <thp> Does this cover the case that a site has a 1000:1 duct cycle and takes snapshots every 10 mins?
10:03:59 <kinjim> kinjim has joined #webrtc
10:04:18 <DrAlexG> harald: the problem is, the cam led is not under the control of the software, but the hardware. Nowadays, the only way to turn the cam led off one need to release the camera hardware (capturer) all together.
10:04:34 <DrAlexG> ... eventually, the cam / driver might takes time, or even keep the light on.
10:05:10 <DrAlexG> cullen: we could make the cam maker do the right thing ....
10:05:22 <DrAlexG> jib: the point here was to provide feedback to user.
10:05:35 <DrAlexG> cullen: yes, i was just trying to define the desirable behavior of camera
10:05:42 <DrAlexG> jib: ok, let s see next slide
10:06:01 <DrAlexG> ... #389 allow "on-air" cam light off on mute/disabled
10:06:19 <DrAlexG> ... short of physically unplugging camera,
10:06:54 <DrAlexG> vivian: does this happen to video only, oraudoi as well
10:07:10 <dom> s/vivian/vivien/
10:07:19 <DrAlexG> jib: it applies to both, as far as the tab indicator is concerned, but not for the led.
10:08:16 <DrAlexG> dan: so we keep the tab indicator (red dot) on, if *anything* is on (audio and video)
10:08:50 <DrAlexG> cullen: there is a privacy concern, even for computers that don't have cam led.
10:08:59 <DrAlexG> harald: we should add some wording about this.
10:09:34 <DrAlexG> jib: for the indicator itself, i think we should have as strong a language than we have for security prompt (since it is under our control, unlike cam led)
10:10:03 <DrAlexG> dom: check full screen mode
10:10:09 <dan> s/dan/burn
10:10:33 <DrAlexG> dan: we might not speak about "indicator" but ways of letting the user know wether: it is possible or not, it is happening or not.
10:10:40 <dom> s/check full screen mode/I agree with the purpose and privacy guarantees we want to get; I'm not sure we can enforce them since showing indicators can be difficult; think of limited mobile screens, or apps in full screen mode
10:10:43 <RANG_LEE> RANG_LEE has joined #webrtc
10:11:09 <vivien> s/oraudoi/or audio/
10:11:16 <vivien> present+ Varun
10:11:43 <DrAlexG> #387/389 make indicator a must - group agrees
10:11:58 <dom> s/group agrees//
10:12:19 <DrAlexG> cullen: do we still have text about the indicator staying on for some time, even if the cam was only on for a small amount a time.
10:12:24 <olivexu> olivexu has joined #webrtc
10:12:40 <DrAlexG> jib: good, I think we should definitely do that (leave the indicator on).
10:14:28 <DrAlexG> adamB: do we need extra language in the specs for that?
10:20:00 <dom> HTA: we should mandate the tracking of the 2 states (on air / accessible), and strongly encourage make them "visible" to the user
10:20:17 <dom> DanB: we could go even further and mandate making the changes to these states visible to the user
10:20:20 <dom> Dom: I like that
10:20:21 <DrAlexG> jib: next slide
10:20:24 <dom> DanB: I'll work with JIB on that
10:20:40 <vivien> -> https://github.com/w3c/mediacapture-main/issues/350  New permission definitions are wrong. #350
10:20:45 <DrAlexG> #350 language ok, one behavioral change
10:21:06 <DrAlexG> ... no reprompt in GUM for sources already live on stage
10:22:50 <wonsuk> wonsuk has joined #webrtc
10:25:18 <DrAlexG> jib: quite frankly, since we are using the permission spec, apart from http, if you have indicator, the UA can do whatever you want with respect to prompts
10:25:31 <DrAlexG> ... we exchanged strong prompt policy for strong indicator policy
10:25:38 <RRSAgent> I have made the request to generate http://www.w3.org/2016/09/22-webrtc-minutes.html vivien
10:25:48 <DrAlexG> cullen: I'd like someone to explain to me why it is a good thing.
10:25:51 <oh9405_> oh9405_ has joined #webrtc
10:26:54 <DrAlexG> harald: think about a page that would take a snapshot (authorized)  and then 4 hours later (using the permission given before) switch it back on and do something evil.
10:27:36 <DrAlexG> ... now, we have indicators to show the use and the CAPACITY of using it (even if it s not in use).
10:28:03 <DrAlexG> cullen: ok, so that s only an HTTP problem (since in HTTPS the permission are stores).
10:28:53 <DrAlexG> harald: if there is no indication of capacity, we need to prompt.
10:29:21 <DrAlexG> cullen: then, going back to that use case, if we tsp using the cam, then capacity is also lost.
10:29:41 <DrAlexG> s/tsp/stop/
10:30:30 <vivien> s/stores/stored/
10:31:11 <kinjim> kinjim has joined #webrtc
10:31:47 <DrAlexG> jib: I should clarify that the query() interface behave differently in chrome and FF today. after a successful call to GUM, a call to query() would still return "prompt" in FF, to show it's a one-use media stream.
10:32:16 <DrAlexG> ... <how about permission goes away with garbage collection>
10:33:43 <DrAlexG> jib: i think the HTTP requirement comes from IETF, so we (w3c) cannot modify it right now.
10:33:59 <DrAlexG> dom: so .... what was the conclusion here?
10:34:58 <DrAlexG> discussion jib/adamb/cullen/dom on a sumamry
10:35:11 <cpn> cpn has joined #webrtc
10:35:15 <DrAlexG> s/sumamry/summary/
10:36:48 <DrAlexG> cullen: the specs should say very clearly how long the permission lasts in any case. I do not think that http or https is so different, you just do not access storage if over http, but the information might be stored.
10:37:00 <DrAlexG> ... i am more worried about the maximum amount of time the UA stores it.
10:38:14 <DrAlexG> jib: we have 3 access police snow.
10:38:28 <DrAlexG> cullen: i don t think we need the per-realm one, we do not have use case for it.
10:39:49 <DrAlexG> jib: edge does it like that
10:40:11 <DrAlexG> shinjun: one use case is to attach to a user profile.
10:41:20 <DrAlexG> ... second use case is when you are on a web site, just finished a call, and a second call comes in, you don t want to be prompted again, bad UX
10:41:36 <DrAlexG> dom: that s fine, but what is not right is to not prompt over HTTP
10:41:58 <dom> s/is to not prompt/is to require to prompt/
10:42:24 <DrAlexG> harald: if we are clear that accessibility device indicator is protection enough, then we should be done?
10:44:16 <DrAlexG> jib: we should allow some browser to implement stronger privacy policies.
10:45:14 <DrAlexG> cullen: we just need to be very clear about the intend, and about the length of permission. There are now 2 use cases, one from shinjun and one from harald.
10:45:59 <DrAlexG> shinjun ........
10:46:10 <DrAlexG> jib/dom: can you rephrase
10:46:33 <DrAlexG> shinjun: we spoke about stronger indicators: on-air (for usage) and another one for permission.capacity
10:47:34 <DrAlexG> jib: if i understand correctly, even if we have strong indicators, we still need to have strong security.
10:47:55 <DrAlexG> danB: you need to be sure the user understand what the indicator mean, in term of security
10:48:20 <DrAlexG> jib> true, and the language about that that was in our spec, is now in a separate document.
10:50:38 <DrAlexG> cullen: if the permission spec would apply, then permission would go away as soon as we stop using it.
10:52:06 <DrAlexG> jib: HTTP is simple: nothing than per-use is allowed.
10:56:52 <DrAlexG> harald: I think we are circling on that one.
10:57:27 <DrAlexG> ... you only need, really, two variable, one showing if the camera is in use or not, one showing wether you have permission to use the cam or not.
10:58:04 <DrAlexG> jin: oh, i m very clear about this.
10:58:34 <DrAlexG> cullen: speaking about it it s not clear, but i want to believe that once written it will become clear for the rest of us.
10:58:46 <DrAlexG> danb: i know how to deal with that. jib and I will take care of it.
10:59:08 <DrAlexG> stefan: can you do it by tomorrow? it s more efficient to deal with it while we are all here.
10:59:13 <DrAlexG> danB.
10:59:39 <DrAlexG> harald: last 1~2 slides. let's do it and go to lunch
10:59:53 <vivien> -> https://github.com/w3c/mediacapture-main/issues/380 Remove redundant list-devices permission. #380
10:59:59 <DrAlexG> jib: #380 device labels + devicechange and stop()
11:00:40 <DrAlexG> jib: firing the ondevicechange on all tabs using the hardware was not great.
11:01:05 <DrAlexG> jib: labels: if you had permissions, you could see the labels, otherwise you would shave an empty string.
11:01:29 <DrAlexG> ... if permissions were revoked while you were using the cam, you keep the label for as long as you use it.
11:02:15 <DrAlexG> ... we propose to have separate device info permission weaker than GUM permission
11:02:27 <dom> (bikeshedding - "device-info" probably ought to be "usermedia-info" or "usermedia-device-info")
11:05:46 <DrAlexG> all: we might need an UI in the UA for that ?
11:06:07 <DrAlexG> dom: is there any AI on this?
11:06:35 <DrAlexG> DanB: is it true that the only way to have DeviceInfo "granted" is when at one point GUM was also "granted"
11:06:52 <DrAlexG> jib: as it is today: yes, but the UA can overrule this.
11:07:10 <DrAlexG> ... we could you have in the future one browser that always show the labels.
11:15:23 <DrAlexG> danb: what is the conlusion here?
11:15:27 <DrAlexG> harald: do It!
11:15:38 <DrAlexG> danb: do ..... what?
11:16:58 <dom> dom: what I find confusing is that by using "weaker than" as a concept, we're putting ourselves in a corner that didn't exist before
11:21:17 <DrAlexG> ptatcher: there is a lot to explain to the user before he can understand all that.
11:21:31 <DrAlexG> jib: exposing all that to the user is wrong in the first place.
11:22:08 <DrAlexG> danb: per use for GUM and per-realm permission for deviceinfo is OK
11:22:25 <DrAlexG> dom: we might need additional info
11:22:34 <DrAlexG> jib: yes, we might want that.
11:23:27 <DrAlexG> ptatcher: we might want to prevent user to get labels, but still provide audio access.
11:24:49 <vivien> present+ Dan_Druta
11:26:36 <DrAlexG> danB: the UA needs to have perfect clarity of the permission you are asking it. The consequence is that you cannot ask for one specific cam, and get permission for more than that.
11:27:04 <DrAlexG> ... people have concerns, and are willing to see a text wording the proposal, but that s the best we can achieve, here, now.
11:27:36 <DrAlexG> jib: list what we agree on
11:27:45 <DrAlexG> ..... <proposal 1: opposed by all>
11:30:54 <DrAlexG> cullen: use case which drove this: the cam was per-use, we are beyond that use, but in the same realm, and we want the deviceinfo to be NOT denied, even though GUM permission would be "prompt" or "denied" (NOT "granted")
11:31:41 <RRSAgent> I have made the request to generate http://www.w3.org/2016/09/22-webrtc-minutes.html vivien
11:31:55 <hta1> Lunchtime. We will be back in 1 hour (1:30 local time).
11:32:58 <frodek> frodek has joined #webrtc
12:02:57 <hta1> hta1 has joined #webrtc
12:12:17 <hta1> hta1 has joined #webrtc
12:22:54 <adamR> adamR has joined #webrtc
12:22:59 <dom> dom has joined #webrtc
12:24:20 <vivien> vivien has joined #webrtc
12:25:10 <dom> RRSAgent, draft minutes
12:25:10 <RRSAgent> I have made the request to generate http://www.w3.org/2016/09/22-webrtc-minutes.html dom
12:25:16 <frodek> frodek has joined #webrtc
12:26:43 <kinjim> kinjim has joined #webrtc
12:29:06 <adambe> adambe has joined #webrtc
12:31:57 <hta2> hta2 has joined #webrtc
12:39:51 <fluffy> fluffy has joined #webrtc
12:41:22 <dom> ScribeNick: adambe
12:41:48 <dom> Topic: Media Capture Depth
12:42:01 <kinjim> kinjim has joined #webrtc
12:42:13 <burn> burn has joined #webrtc
12:42:46 <ningxinhu> ningxinhu has joined #webrtc
12:43:10 <ningxinhu> https://w3c.github.io/mediacapture-depth/
12:43:21 <ningxinhu> https://github.com/w3c/mediacapture-depth/issues
12:43:41 <AndyH> AndyH has joined #webrtc
12:43:51 <adambe> ningxinhu: Give some info about implementation feedback and demos
12:43:52 <vr000m> vr000m has joined #webrtc
12:44:38 <adambe> ... implementors would like to explicitly define depth map
12:44:53 <adambe> ... depth value is 16 bit integer
12:45:40 <jesup> Remote can't hear the person speaking, if they can be closer to the mic we might have a chance
12:45:52 <adambe> ... now we can drop the conversion algorithm
12:46:39 <adambe> ... depth value is distance from point to camera
12:46:56 <adambe> jib: we're not talking about the depth constraint now, are we?
12:47:00 <vivien> present+ Ningxin_Hu
12:47:07 <adambe> ningxinhu: no. Depth value in depth map
12:47:23 <adambe> ... other update is changes to video element
12:47:29 <adambe> ... how to render the depth screen
12:47:40 <wonsuk> wonsuk has joined #webrtc
12:48:05 <adambe> ... we want to leave @@@ to implementations
12:48:33 <dom> s/@@@/video rendering/
12:48:33 <dom> s/video/on-screen/
12:48:50 <RANG_LEE> RANG_LEE has joined #webrtc
12:49:32 <adambe> dom: to clarify, this is about default rendering in a video element
12:49:53 <adambe> dom: video is not the most interesting usage of depth streams
12:51:11 <ningxinhu> https://github.com/w3c/mediacapture-depth/issues/131
12:52:14 <adambe> ningxinhu: implementors have suggested a new image data type for depth
12:53:50 <adambe> ... issue 131
12:53:59 <ningxinhu> https://codereview.chromium.org/2121043002/
12:54:22 <DrAlexG> DrAlexG has joined #webrtc
12:55:17 <Kangchan> Kangchan has joined #webrtc
12:55:45 <adambe> fluffy: it's seems weird to choose the red channel
12:56:04 <adambe> fluffy: so it's actually a single channel image
12:56:29 <ningxinhu> https://jsfiddle.net/astojilj/wq1kwu0t/
12:56:35 <adambe> ningxinhu: (is showing a demo)
12:56:41 <kinjim> kinjim has joined #webrtc
12:58:20 <adambe> ... use can use js to track your hand
12:58:27 <adambe> ... with the joints
12:58:42 <adambe> s/use/you/
12:59:34 <adambe> stefanh: regarding implementations, you mention chromium
12:59:54 <adambe> ... you mention a v2, how far are you from a v1?
13:00:12 <dom> s/a v1/CR for V1/
13:00:19 <adambe> ningxinhu: we need to reach consensus on two issues
13:00:28 <adambe> ... canvas stuff and Web GL
13:00:47 <adambe> dom: why isn't the webgl stuff on the issues list?
13:01:08 <adambe> ningxinhu: implementors don't want to put hard requirements on the spec
13:01:48 <adambe> fluffy: devs would like to have near and far values
13:01:54 <adambe> ningxinhu: we have that in v1
13:02:11 <adambe> stefan: what about tests
13:02:22 <adambe> ningxinhu: I need to check that
13:02:31 <adambe> dom: have we gone through wide review?
13:02:37 <adambe> chairs: no, not yet
13:02:43 <adambe> dom: we should do that soon
13:02:56 <adambe> dom: we can talk about the processs
13:03:50 <adambe> burn: is presenting
13:04:10 <adambe> dom: in the mcap doc there's a select setting algorithm
13:04:16 <adambe> s/dom/burn/
13:04:43 <vivien> Topic: Mediacapture-main -  Membership Level: Startu
13:04:52 <vivien> s/ Membership Level: Startu//
13:04:54 <adambe> burn: mistake to only execute algorithm at gum() or applySettings()
13:04:57 <adambe> ... this was a mistake
13:05:14 <ericc> ericc has joined #webrtc
13:05:44 <adambe> burn: (talks about constraints example in slides)
13:05:49 <vivien> s/Mediacapture-main -/Mediacapture-main - Issue 394: Browser's ability to dynamically change settings mistakenly removed
13:05:52 <adambe> burn: (issue 394)
13:06:15 <vivien> -> https://github.com/w3c/mediacapture-main/issues/394  Browser's ability to dynamically change settings mistakenly removed #394
13:06:58 <adambe> burn: example deals with a setting that becomes impossible for the browser to keep
13:07:19 <adambe> burn: do we have agreement that it should work as described in slides?
13:07:29 <Shijun> Shijun has joined #webrtc
13:07:34 <adambe> burn: people are agreeing
13:08:01 <adambe> burn: I will make a PR
13:08:22 <adambe> burn: yay :)
13:09:41 <adambe> peter: can't the UA do re-selection at any time??
13:10:14 <adambe> burn: you can do re-selection unless we don't end up in a overconstrained case
13:11:14 <adambe> burn: goal is to give UA freedom, without violating script wishes
13:12:21 <dom> Topic: Media Streams & Capture Test Suite
13:12:39 <adambe> DrAlexG: I'm going to talk about the status of the test suite for Media Capture and Streams
13:13:15 <adambe> ... currently gum and webrtc specs have the most advanced test suites
13:13:39 <adambe> dom: (explains conditions for CR)
13:14:01 <adambe> ... almost impossible to get out of CR without reasonable tests
13:14:37 <adambe> DrAlexG: how much can two browsers share and still be interpreted as two separate implementations?
13:14:58 <adambe> dom: they need to be "different enough"
13:15:23 <adambe> fluffy: the point is: we're the specs good enough for two implementations to be produced
13:15:43 <adambe> ... a lot of code shared between two of the implementations
13:16:19 <adambe> dom: the director will not be diving into the implementations
13:17:26 <adambe> jesup: regarding cullens comment
13:17:36 <adambe> ... not of code is shared at the DOM level
13:17:42 <adambe> ... more at lower level
13:18:17 <adambe> DrAlexG: question of interop different between gum and webrtc docs
13:18:49 <adambe> burn: this is about testing the spec, not immplementations
13:19:19 <adambe> peter: what about referenced specs
13:19:27 <adambe> dom: up to this group to decide
13:19:49 <adambe> ... there's no end to the testing you can do
13:19:58 <adambe> DrAlexG: let's talk about this tomorrow
13:20:52 <adambe> ... (talking about test coverage slide)
13:21:29 <adambe> jib: are you adding tests that aren't working in any browser?
13:21:32 <adambe> DrAlexG: yes
13:22:00 <adambe> ... there are things that can be easy fixed
13:22:19 <adambe> ... for example: MediaStreamTrack.getTracks
13:22:50 <adambe> ... and new things related to the constrainable pattern
13:23:04 <adambe> jib: how do you determine test coverage
13:23:10 <adambe> DrAlexG: manually!
13:23:34 <jinho_> jinho_ has joined #webrtc
13:23:56 <olivexu> olivexu has joined #webrtc
13:24:39 <adambe> ... some parts of the spec is hard to test
13:24:56 <adambe> ... for example camera behavior
13:25:11 <adambe> fluffy: people have made fake cameras for testing
13:25:32 <adambe> DrAlexG: hard to test tricky cases
13:25:43 <adambe> ... e.g., when timing is involved
13:26:04 <adambe> ... sources are loosely defined; it can be a lot of different thingns
13:26:35 <adambe> ... hard to check if source is stopped when all track have ended
13:27:07 <adambe> jib: we have a hack in firefox where we look at labels
13:27:23 <adambe> DrAlexG: that won't work for long
13:27:46 <adambe> dom: we should only test that the final result is the same
13:28:20 <adambe> ... algorithms are a clear way to define behavior
13:28:24 <Jun> Jun has joined #webrtc
13:28:41 <dom> applyConstraints ends with a note that says "Any implementation that has the same result as the algorithm above is an allowed implementation"
13:29:00 <adambe> jib: how are you testing SHOULD-statements
13:29:04 <adambe> dom: we don't test them
13:29:18 <vivien> present+ Eric_Carlson
13:29:33 <adambe> DrAlexG: tricky to test security permission prompts
13:30:02 <adambe> ... web bluetooth have had the same problem
13:30:14 <dom> "Conformance requirements phrased as algorithms or specific steps may be implemented in any manner, so long as the end result is equivalent. " https://w3c.github.io/mediacapture-main/getusermedia.html#conformance
13:30:15 <adambe> dom: issue has been reported to the web driver WG
13:30:36 <adambe> DrAlexG: (showing slide about test results from March 2016)
13:30:54 <adambe> DrAlexG: adapter.js is almost a part of the browser today
13:31:17 <adambe> dom: we can't give adapter.js to the director :)
13:32:06 <adambe> hta2: adapter.js hints that the functionality is there but the name is wrong
13:34:49 <adambe> DrAlexG: summing up test status
13:35:46 <adambe> dom: are any implementors planning to upstream tests?
13:35:56 <adambe> DrAlexG: all browsers have their own tests
13:36:25 <adambe> dom: there have been efforts in other groups to upstream tests
13:36:59 <adambe> bernard: my opinion is that won't work well for advanced test cases (e.g. with a conferencing server involved)
13:37:37 <frodek> frodek has joined #webrtc
13:38:29 <adambe> DrAlexG: there's room for collaboration
13:39:19 <adambe> hta: the chrome team has been working hard on importing tests
13:39:38 <adambe> ... and converting tests to w3c platform tests
13:40:21 <adambe> ... I've been thinking about suggesting a fake device for the web driver spec
13:41:36 <adambe> DrAlexG: (talks about Apple's approach to give test consent to getUserMedia)
13:41:53 <adambe> dom: having this is the web driver would be useful
13:41:54 <wenyu_dong> wenyu_dong has joined #webrtc
13:42:20 <adambe> jib: this is different between browsers
13:42:40 <adambe> dom: it wouldn't have to be with the web driver
13:43:14 <adambe> DrAlexG: it's up to us or the BT group to make this happen
13:43:41 <adambe> dom: I can help this activity but not be the (web) driver
13:43:51 <adambe> s/(web)//
13:44:37 <dom> Topic: Media Capture Output
13:44:57 <dom> -> https://w3c.github.io/mediacapture-output/ Audio Output Devices API
13:45:04 <adambe> hta: basically says: here's how you tell a media device which devicec to send audio to
13:46:02 <adambe> ... (showing slide with controversial topics)
13:46:19 <dom> -> https://github.com/w3c/mediacapture-output/issues/19 Reserved values for ID don't seem like the right solution
13:47:51 <adambe> dom: there was an issue in mcap if we should have a minimum length of ids to avoid collisions
13:48:04 <adambe> ... that issue was closed pointing to the above issue
13:48:28 <jinho> jinho has joined #webrtc
13:49:02 <frodek> frodek has joined #webrtc
13:52:44 <adambe> fluffy: how do I get the device id for speakers
13:53:00 <adambe> hta: the speaker device is in the enumerated devices set
13:53:32 <wonsuk> wonsuk has joined #webrtc
13:53:38 <adambe> fluffy; so I get a label on the speakers after a gum() request?
13:53:42 <adambe> jib: yes
13:54:20 <adambe> hta: fingerprinting is the cause to restrict access to labels
13:55:16 <adambe> dom: there might be future versions of enumerate devices that's disconnected from webrtc
13:56:13 <dom> https://github.com/w3c/mediacapture-main/issues/173
13:58:01 <adambe> jib: many ways to solve this; we think all of them are ugly
13:58:52 <dom> https://lists.w3.org/Archives/Public/public-media-capture/2015Jun/0015.html
14:01:29 <adambe> dom: someone from the audio output spec should get an AP to come up with a solution
14:03:24 <adambe> dom: issue 19 is assigned to ###
14:04:28 <dom> s/###/hta for guido
14:07:23 <adambe> Topic: Mediacapture-image
14:08:02 <adambe> hta: showing slide about a request to go to CR
14:17:17 <kinjim> kinjim has joined #webrtc
14:28:38 <hta1> hta1 has joined #webrtc
14:32:18 <jesup> Are we all done, or are people coming back after coffee?  Note that the room has left the conference...
14:33:44 <achronop> achronop has joined #webrtc
14:35:58 <fluffy> fluffy has joined #webrtc
14:38:55 <ericc> ericc has joined #webrtc
14:39:39 <olivexu> olivexu has joined #webrtc
14:44:03 <Hiroki> Hiroki has joined #webrtc
14:48:05 <jinho_> jinho_ has joined #webrtc
14:48:59 <vivien> jesup, sorry we got disconnected during the break
14:49:13 <vivien> (same thing as this morning's break)
14:49:21 <jesup> no problem.
14:54:51 <RRSAgent> I have made the request to generate http://www.w3.org/2016/09/22-webrtc-minutes.html vivien
14:58:42 <dom> ScribeNick: vr000m
14:58:48 <dom> Topic: DTMF issues
14:58:52 <wonsuk> wonsuk has joined #webrtc
14:59:10 <vr000m> bernard: PR #784
14:59:16 <dom> -> https://github.com/w3c/webrtc-pc/pull/784  interToneGap and duration fixes #784
14:59:22 <vivien> present+ Tim_Panton_(webex)
14:59:53 <vr000m> problem is there is a default and optional
14:59:54 <vivien> present+ Randell_Jesup_(webex), Shijun_Sun_(webex)
15:00:15 <vr000m> bernard: remove the default
15:00:28 <RRSAgent> I have made the request to generate http://www.w3.org/2016/09/22-webrtc-minutes.html vivien
15:01:18 <vr000m> jib: if it is a method, then the argument is default
15:01:25 <dom> -> https://www.w3.org/TR/WebIDL-1/#dfn-optional-argument-default-value "Optional arguments can also have a default value specified." in WebIDL
15:01:30 <vivien> present+ Patrick_Rockhill_(webex)
15:01:42 <vr000m> adambe: you always need a default value unless it is option
15:02:48 <vr000m> burn: if what you want to do is: you want to specify a way to use the last set of values you want to use. such that you want to override it
15:03:01 <vr000m> fluffy: do not like that, it is unintuitive
15:04:05 <vr000m> hta1: if you call the insertDTMF(2, 500) and then call insertDTMF(2), then what is the expected behaviour?
15:04:32 <vr000m> hta1: in some DTMF engines it clears the tone
15:04:59 <vivien> s/problem is there/bernard: problem is there/
15:05:02 <vr000m> decision it is is as is
15:05:58 <vr000m> bernard: the conclusion keep what we have, and is fine from webidl.
15:06:48 <vr000m> dom: It is fine from webidl, but is there an underlying issue we are not addressing
15:07:17 <vr000m> fluffy: can there be more than one DTMF agent
15:07:42 <vr000m> bernard: there is one for each RTP sender
15:08:41 <dom> Conclusion: we need to remove "if insertDTMF was called without specifying the duration. " from the description of the insertMethod operation
15:08:46 <vr000m> bernard: issue 799
15:08:46 <dom> (and likewise for intertonegap)
15:09:58 <dom> -> https://github.com/w3c/webrtc-pc/issues/799 Issue 799 Unclear when a DTMFToneChangeEvent is fired with an empty string
15:12:27 <dom> Additional conclusion on 782: we don't want to make values sticky
15:14:00 <vr000m> bernard: keep the empty string when all the tones have finished playback.
15:14:16 <vr000m> bernard: and not at the end of each tone
15:14:29 <dom> [conclusion: we accept PR 807]
15:14:32 <vr000m> hta1: we accept the proposal
15:14:47 <dom> -> https://github.com/w3c/webrtc-pc/issues/800 What happens if removeTrack() is called when DTMF tones are still in the toneBuffer?
15:15:06 <vr000m> bernard: what happens when a remove track is called when there are tones in the tonebuffer
15:15:45 <vr000m> bernard: PR #809 is the proposed fix
15:15:47 <dom> -> https://github.com/w3c/webrtc-pc/pull/809 What happens when insertDTMF is called for a stopped sender? (proposed fix)
15:16:41 <vr000m> bernard: there are a few cases i had in mind
15:16:59 <vr000m> bernard: if the sender is closed, then it should throw invalid state error.
15:17:38 <vr000m> bernard: if the sender is closing, then abort the process
15:17:53 <vr000m> fluffy: what happens if something is set to null.
15:18:21 <dom> s/what happens if something is set to null/do we send the "tones have been played" event?
15:18:32 <dom> hta: no, since tones were not played
15:21:20 <vr000m> fluffy: what if I call insertDTMF("ABCDEF...Z"), then call insertDTMF(""). Meanwhile, the DTMF engine had sent A through D. Then the empty string is executed, which will stop playing the event after the "D" tone is played.
15:21:46 <vr000m> fluffy: so the empty string flushes the previous buffer.
15:22:45 <dom> -> https://github.com/w3c/webrtc-pc/issues/714 STUN/TURN OAuth token auth parameter passing #714
15:22:50 <vr000m> bernard: Issue 714, 740
15:23:22 <kinjim> kinjim has joined #webrtc
15:23:47 <vr000m> burn: the person who reported the issue turned up at a standards webinar and reported it was not resolved.
15:25:42 <ningxinhu_> ningxinhu_ has joined #webrtc
15:26:07 <dom> -> https://docs.google.com/presentation/d/1lg4AeEKTdR5zJdvpmIxpIEn1tlKFW458EkeKHUVWo0Y/pub?start=false&loop=false&delayms=3000#slide=id.p Misi's presentation on OAuth + STUN/TURN
15:27:10 <shijun> shijun has joined #webrtc
15:30:30 <igarashi> igarashi has joined #webrtc
15:34:12 <dom> PeterT: is anyone implementing oauth for stun/turn
15:34:16 <dom> [no one]
15:34:28 <vr000m> fluffy: ask the TRAM WG to comment on the PR and issue
15:34:41 <dom> Dom: so part of the question is whether there is any hope of supporting oauth-based auth in 1.0
15:35:55 <vr000m> conclusion: no resolution, action on chair to ask TRAM.
15:36:24 <vivien> https://bugs.chromium.org/p/webrtc/issues/detail?id=4907
15:36:29 <vivien> https://bugzilla.mozilla.org/show_bug.cgi?id=1247616
15:37:46 <vivien> those issues are entitled "Support RFC 7635 (TURN OAuth)"
15:39:37 <vr000m> pthatcher: Issue #305.
15:39:54 <vr000m> fluffy: i thought we decided center and crop
15:40:27 <vr000m> pthatcher: what to do about incompatible aspect ratio
15:40:58 <vr000m> jib: we have replace track, this would only happen if there was a violation of what was negotiated
15:41:18 <vr000m> pthatcher: the only thing that is negotiated, we do not have a way to set aspect ratio
15:42:07 <vr000m> fluffy: this would only happen if the media is sent outside the negotiated scope.
15:42:32 <vr000m> fluffy: we do not want letterboxing, because it might be a lot of black... so I prefer center and crop
15:42:51 <vr000m> decision: center, scale, crop, in that order.
15:45:32 <vivien> Meeting adjourned for today
15:45:38 <vivien> see you tomorrow
15:45:45 <vivien> RRSAgent, draft minutes
15:45:45 <RRSAgent> I have made the request to generate http://www.w3.org/2016/09/22-webrtc-minutes.html vivien
15:45:54 <vivien> Zakim, clear agendum
15:45:54 <Zakim> I don't understand 'clear agendum', vivien
15:46:02 <vivien> Zakim, clear agenda
15:46:02 <Zakim> agenda cleared
15:46:26 <vr000m> vr000m has joined #webrtc
15:49:26 <frodek> frodek has left #webrtc
15:50:41 <hta1> hta1 has joined #webrtc
15:54:53 <wonsuk> wonsuk has joined #webrtc
16:28:55 <hta2> hta2 has joined #webrtc
16:30:29 <wonsuk> wonsuk has joined #webrtc
16:30:40 <wonsuk_> wonsuk_ has joined #webrtc
16:40:14 <ericc> ericc has joined #webrtc
16:40:42 <vivien> vivien has joined #webrtc
16:53:24 <ericc> ericc has joined #webrtc
17:02:49 <Hiroki> Hiroki has joined #webrtc
17:55:38 <hta1> hta1 has joined #webrtc
18:02:30 <ericc> ericc has joined #webrtc
18:53:32 <ericc> ericc has joined #webrtc
20:19:07 <adambe> adambe has joined #webrtc
21:37:38 <hta1> hta1 has joined #webrtc
22:13:49 <adamR> adamR has joined #webrtc
22:17:24 <adamR_> adamR_ has joined #webrtc
22:30:11 <ericc> ericc has joined #webrtc
22:49:12 <Hiroki> Hiroki has joined #webrtc
22:51:57 <Hiroki_> Hiroki_ has joined #webrtc
23:34:58 <ericc> ericc has joined #webrtc