15:48:34 <RRSAgent> RRSAgent has joined #webrtc
15:48:34 <RRSAgent> logging to http://www.w3.org/2011/10/31-webrtc-irc
15:48:44 <francois> RRSAgent, make logs public
15:49:09 <Kepeng> Kepeng has joined #webrtc
15:49:17 <francois> Meeting: WebRTC WG F2F Santa Clara - Day 1/2
15:49:19 <Kepeng> test
15:49:32 <francois> Chair: Harald_Alvestrand, Stefan_Hakansson
15:49:45 <fluffy> fluffy has joined #webrtc
15:49:58 <fluffy> test ?
15:50:02 <francois> Agenda: http://www.w3.org/2011/04/webrtc/wiki/October_31_-_November_1_2011
15:50:03 <junyayamada> junyayamada has joined #webrtc
15:50:08 <hiroki> hiroki has joined #webrtc
15:50:15 <burn> fluffy, no tests to run today?
15:50:40 <Mohammed> Mohammed has joined #webrtc
15:50:45 <anant> anant has joined #webrtc
15:53:06 <stefanh> stefanh has joined #webrtc
15:53:48 <yu1> yu1 has joined #webrtc
15:59:10 <richt> richt has joined #webrtc
16:01:07 <pererik> pererik has joined #webrtc
16:01:33 <ceyrigno> ceyrigno has joined #webrtc
16:01:41 <francois> Present: Harald_Alvestrand, Stefan_Hakansson, Anant_Narayanan, Timothy_Terriberry, Francois Daoust, Rich_Tibbett, Dan_Burnett, Cullen_Jennings, Christophe_Eyrignoux
16:02:35 <francois> Scribe: francois
16:02:51 <francois> Stefan: [starting meeting. Reviewing agenda]
16:03:25 <gang> gang has joined #webrtc
16:03:59 <juberti> juberti has joined #webrtc
16:04:06 <francois> Zakim, this will be WebRTC
16:04:07 <Zakim> ok, francois, I see UW_(WebRTC)12:00PM already started
16:04:45 <adambe> adambe has joined #webrtc
16:04:56 <richt> ScribeNick: richt
16:05:27 <richt> <meeting starts>
16:05:32 <richt> stefanh: <goes through the morning agenda on the screen>
16:06:15 <richt> Topic: IETF Architecture Overview
16:06:19 <Kangchan> Kangchan has joined #webrtc
16:07:07 <manyoung> manyoung has joined #webrtc
16:07:32 <francois> zakim, dial Prospector_AB
16:07:32 <Zakim> ok, francois; the call is being made
16:07:33 <Zakim> +Prospector_AB
16:07:59 <derf> richt: He's normally hta.
16:08:55 <richt> hta: The goal for RTCWeb is real-time communication between browsers
16:09:14 <richt> hta: arbitrarily define that as within ~100ms
16:09:54 <richt> hta: Trying to drive a design by use cases. Must have a design that meet the priority use cases.
16:10:54 <richt> hta: we want to design general purpose functions.
16:11:34 <richt> ...one use case we're looking at is the interworking with legacy systems. We're fairly sure we want to make that work.
16:12:13 <juberti> yep, i can hear Harald. Thanks!
16:12:36 <richt> ...relays must be possible otherwise we don't have a universal solution.
16:13:00 <richt> hta: <goes through the basic architecture in his slide deck>
16:13:27 <ileana> ileana has joined #webrtc
16:13:31 <fluffy> Is there a place to download slides ?
16:14:41 <francois> Present+ Adam_Bergkvist, Kepeng_Li, Gang_Liang, Dan_Druta, Ileana_Leuca(obs), Vidhya_Gholkar
16:15:58 <richt> hta: All components (except RTCWeb implementing browsers) must be assumed evil.
16:16:42 <richt> hta: Keep trust to a minimum
16:16:52 <francois> Present+ Milam_Young(obs), Kangchan_Lee, Manyoung_Cho(obs), Narm_Gadiraju, Dong-Young_Lee(obs), Shunan_Fan, Mohammed_Dadas, Mauro_Cabuto(obs), Youngsun_Ryu, Youngwan_So, Tatsuya_Hayashi(obs), Ingmar_Kliche(obs)
16:17:09 <richt> hta: Need to look at mechanisms for establishing trust from a web page to a browser.
16:19:06 <richt> hta: data congestion must also be a priority.
16:19:24 <richt> s/data congestion/data congestion control/
16:19:38 <richt> hta: RTP exists. We will use it.
16:20:01 <richt> hta: encrypt everything
16:20:07 <richt> <this is controversial>
16:20:52 <francois> [@@ add link to Harald's slides when available]
16:21:13 <richt> hta: considering DTLS-SRTP key negotiation for that purpose.
16:21:46 <richt> hta: UI issues are important to the overall security.
16:22:07 <richt> hta: always fun to agree on codecs
16:22:22 <Youngsun> Youngsun has joined #webrtc
16:22:37 <richt> hta: connection management: least controversial proposal is ROAP
16:23:04 <richt> hta: We expect innovation in what-connects-to-what
16:24:20 <ekr_> ekr_ has joined #webrtc
16:24:46 <richt> ...ROAP does allow us to interconnect to SIP and XMPP based systems
16:25:00 <francois> RRSAgent, draft minutes
16:25:00 <RRSAgent> I have made the request to generate http://www.w3.org/2011/10/31-webrtc-minutes.html francois
16:25:25 <Youngsun> Youngsun has joined #webrtc
16:26:23 <richt> hta: lots of other pieces, media buffering, muting, game control.
16:26:26 <francois> Scribe: Rich
16:26:32 <richt> hta: a lot of that needs to be done in the browser.
16:26:34 <francois> ScribeNick: richt
16:27:21 <richt> DanD: ...caveated by keeping in mind that we want to allow innovation.
16:27:58 <richt> s/DanD:/burn:/
16:28:35 <Youngsun> Youngsun has joined #webrtc
16:28:42 <richt> hta: W3C has an Audio group defining interfaces for accessing audio data.
16:28:57 <richt> hta: hopefully we'll be able to use that but we need to confirm that down the line.
16:29:34 <richt> hta: All of this is captured in draft-ietf-webrtc-overview-00.txt
16:30:19 <richt> DanD: We know web is beyond browsers. We do have the ability to execute web apps in non-browser UAs.
16:30:34 <Kangchan> http://tools.ietf.org/html/draft-ietf-rtcweb-overview-01 ? or http://tools.ietf.org/html/draft-ietf-rtcweb-overview-02
16:30:40 <richt> DanB: We need to ensure that a browser endpoint can communicate with a non-browser endpoint.
16:30:46 <qpan> qpan has joined #webrtc
16:31:04 <burn> s/DanB: We/DanD: We/
16:31:15 <richt> hta: We need communication to devices that are not browsers.
16:31:40 <richt> hta: We should not lose track of the browser use cases first and foremost.
16:32:03 <richt> hta: One principle is that as long as the other side obeys the interface then it doesn't matter what it is.
16:33:02 <richt> DanD: Another comment RE: interdependencies with other groups. One example is on the discovery of the capabilities on other devices.
16:33:36 <richt> DanD: this might be a missing piece in our discussions to date.
16:34:07 <richt> anant: There are some capabilities in the proposal to negotiate.
16:35:18 <richt> cullen: If we figure out how the protocols work for interoperability then we might get this legacy interworking.
16:35:56 <Youngwan> Youngwan has joined #webrtc
16:36:52 <richt> s/cullen:/fluffy:/
16:37:26 <richt> <switch to Stefan's presentation>
16:37:31 <francois> s/draft-ietf-webrtc-overview-00.txt/draft-ietf-rtcweb-overview-02.txt/
16:38:34 <richt> stefan: <goes through some of the key use cases in his presentation>
16:39:51 <francois> -> http://www.w3.org/2011/04/webrtc/wiki/images/e/e1/Use_cases_and_reqs_v3.odp Slides on Use Cases and Requirements (odp format)
16:40:08 <richt> Web Real-Time Communication Use-cases and Requirements IETF draft: http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-06
16:42:58 <richt> s/<switch to Stefan's presentation>/Topic: Use-cases and Requirements/
16:44:01 <fluffy> Are these slides on web somewhere ? 
16:44:27 <juberti> francois, can you move the polycom closer to the mic? Stefan is a bit quieter than Harald and the VAD keeps cutting him out.
16:44:31 <junya> junya has joined #webrtc
16:44:51 <juberti> thanks
16:45:02 <richt> slides are here: http://www.w3.org/2011/04/webrtc/wiki/images/e/e1/Use_cases_and_reqs_v3.odp 
16:45:11 <fluffy> thanks
16:45:48 <vgholkar> vgholkar has joined #webrtc
16:46:22 <Suresh> Suresh has joined #webrtc
16:46:53 <Mani> Mani has joined #webrtc
16:47:28 <richt> hta: regarding the Distributed Music Band use cases. We're going to need really low latency. Concert-mode? We also need to distinguish between voice and music where we will remove noise from the former that is not suitable for the latter.
16:48:16 <richt> francois: Perhaps we should try to stick to something simple since the really low latency issue is a problem.
16:48:53 <richt> stefan: It's in the use cases document anyway so we can discuss further on that.
16:49:46 <francois> RRSAgent, draft minutes
16:49:46 <RRSAgent> I have made the request to generate http://www.w3.org/2011/10/31-webrtc-minutes.html francois
16:50:19 <richt> stefan: In the document there are a list of use cases where the discussion has died out.
16:51:02 <richt> ..or not concluded.
16:51:12 <richt> stefan: such use cases relate to different situations, E911, Recording, Emergency access, Security Camera. Large multi-party session etc.
16:51:45 <richt> ...these use cases could get added to the document if they get more support.
16:52:21 <richt> stefan: draft-jesup. I think we should cover both unreliable and reliable data channels for WebRTC data.
16:52:39 <igarashi> igarashi has joined #webrtc
16:52:40 <juberti> I agree, these data use cases should go into this doc.
16:52:56 <richt> stefan: draft-sipdoc. 4 requirements derived. I think this is  covered by the current use cases document
16:53:08 <juberti> We only have one use case for data in the current doc.
16:53:32 <richt> stefan: draft-kaplan. Doesn't introduce new use cases but does put a lot more requirements on the document,
16:53:50 <richt> s/on the document,/on the document./
16:54:05 <richt> stefan: Questions/comments on the use cases?
16:54:25 <richt> DanD: Observation: augmented reality is not covered.
16:54:38 <francois> -> http://www.w3.org/2011/04/webrtc/wiki/Main_Page#Use_cases_and_requirements Open issues on use cases and Req on WebRTC WG wiki
16:55:04 <francois> richt: we've been looking at that. We have the building blocks. Would be good to have a use case on this.
16:55:20 <francois> DanD: that's covered in some of these use cases but maybe something we could add
16:55:52 <francois> cullen: The ability to overlay a video stream on top of another would be good.
16:55:58 <francois> richt: you could do it with canvas
16:56:06 <francois> cullen: that has a big security implication.
16:56:16 <francois> ... will talk about it later on.
16:56:30 <francois> DanD: plus video might come from an ad-serving service.
16:56:53 <lgombos_> lgombos_ has joined #webrtc
16:56:55 <richt> fluffy: Back to the 1-800-FEDEX use case. Anything we can provide to scope that out futher?
16:57:06 <francois> i/<switch to /Topic: Use Cases and Requirements/
16:57:08 <Mauro_> Mauro_ has joined #webrtc
16:57:13 <richt> stefan: not my area of specialty so feedback on this use case would be good.
16:58:01 <richt> fluffy: The use cases puts emphasis on DTMF.
16:58:23 <Kepeng> Kepeng has joined #webrtc
16:58:29 <lgombos__> lgombos__ has joined #webrtc
16:58:33 <richt> burn: I agree that DTMF is extremely important. We have to support DTMF.
16:58:39 <lgombos> lgombos has joined #webrtc
16:59:18 <richt> stefan: let's take a break since we're waiting on next presenter.
17:00:34 <francois> Topic: Security requirements
17:02:17 <francois> Present+ Tatsuya_Igarashi(obs)
17:02:26 <JonathanJ> JonathanJ has joined #webrtc
17:07:14 <fluffy> Slides for next presso are at http://svn.resiprocate.org/rep/ietf-drafts/ekr/tpac2011/rtcweb-security.pdf
17:07:17 <francois> Present+ Eric_Rescorla
17:07:35 <juberti> brb
17:08:16 <John_> John_ has joined #webrtc
17:09:24 <hta> hta has joined #webrtc
17:13:32 <fluffy> Later today when we get the Peer Connection talk, slides are at 
17:13:33 <fluffy> http://svn.resiprocate.org/rep/ietf-drafts/fluffy/tpac2011/
17:15:16 <francois> Scribe: francois
17:15:54 <francois> ekr: IETF trying to work on thread models and security models. I don't think we're at the consensus level already, but here are the directions.
17:16:08 <francois> ... [showing slides, @@link]
17:16:57 <Suresh> link to the presentation please?
17:17:10 <adambe> adambe has joined #webrtc
17:17:28 <francois> ... Funny state: Browser threat model, browser protects you. It includes the notion that you're in an Internet cafe. Basic security technique is isolation.
17:17:44 <francois> ... Site A and site B sandboxed.
17:17:47 <ed> ed has joined #webrtc
17:18:08 <francois> ... Browser acts as a trusted base.
17:18:31 <narm_gadiraju> narm_gadiraju has joined #webrtc
17:18:41 <francois> ... IETF adds the Internet threat model: "you hand the packets to the attacker to deliver".
17:19:01 <francois> ... In the IETF oriented view of the universe, cryptography is the main technique.
17:19:29 <francois> ... We can't force people to use cryptography all the time.
17:19:52 <richt> richt has joined #webrtc
17:19:58 <francois> ... We need a solid protection under the browser threat model, and the best we can on the Internet threat model
17:21:07 <francois> ... 3 main issues: access to "local devices" (use my camera, microphone)
17:21:09 <francois> ... 3) Communications security. If we do our job right, we won't have to worry too much about that here.
17:21:10 <francois> ... 2) consent to communications, ties in with CORS, WebSockets
17:21:19 <francois> s/access to/1) access to/
17:21:21 <francois> ... Starting with access to local devices:
17:22:20 <francois> ... If you go to visit a malicious, you have no idea where your video is going to. It can bug you. Somehow we need the user to consent, but it's not clear when, how many times.
17:23:04 <francois> ... One thing I do want to mention is that people make a distinction between sending video to a site and sending video to another peer, but from a technical perspective, they are the same.
17:24:02 <francois> ... Permissions models: we need short-term permissions, click on a button for an Amazon customer service. Not a long-term permission.
17:24:08 <manyoung> manyoung has joined #webrtc
17:24:22 <francois> ... Until last night, I thought we needed long-term permissions.
17:24:58 <francois> ... Tim indicated that he was not sure browsers will want to do this.
17:25:16 <francois> ... Do you want to support long-term permissions? That's a question for the group
17:25:29 <francois> burn: you could also be a policy question.
17:25:44 <francois> cullen: the question here is: is it a requirement for the group?
17:26:10 <qpan> qpan has joined #webrtc
17:26:12 <francois> burn: went through it in another group. Informed user consent is needed but can take the form of downloading the browser.
17:26:53 <francois> ekr: Then, there's the notion of per-peer permissions.
17:27:37 <burn> s/you could also be a policy question./why isn't this just a browser policy question?/
17:27:56 <francois> ... Another example of the short-term case, showing an example of an injected ad.
17:29:11 <francois> ... [thoughts on UI for short-term permissions]
17:30:26 <francois> ... This has implications for the API.
17:30:34 <gang> gang has joined #webrtc
17:30:34 <francois> ... user clicks and calls Ford, but he's on Slashdot
17:30:40 <Youngsun_> Youngsun_ has joined #webrtc
17:30:42 <Youngwan> Youngwan has joined #webrtc
17:30:42 <francois> ... Dialog showing video call. There needs to be a non-maskable indicator of call status so that you know you're still on the call. You need to be consistently aware that the call is going on.
17:30:52 <hta_> hta_ has joined #webrtc
17:30:53 <francois> ... Access to microphone/camera linked with call permission.
17:32:04 <francois> ... Back to the example, Slashdot might have to be able to say a word.
17:32:18 <francois> ... [thoughts on UI for long-term permissions]
17:32:49 <Mauro_> Mauro_ has joined #webrtc
17:32:53 <francois> ... Interface should be different. Possible: door hanger style UI. You want an action that is less easy for people to do during a call.
17:33:29 <francois> ... There's a tension between convenience and security. It gives a lot of power to the site.
17:33:43 <francois> ... That's an open question whether we want to support that or not.
17:34:06 <francois> ... IETF has been assuming we want, so great feedback to have if we actually don't
17:34:27 <francois> ... [thoughts on peer-identity based permissions]
17:34:42 <juberti> I think we want to find a way to handle this. We don't want the web platform to miss something that will be present in native app platforms.
17:35:06 <dom> dom has joined #webrtc
17:35:27 <francois> cullen: what's important to you is where is that going. Our media is going to a different place than the Web site. The identity is important.
17:35:44 <francois> burn: same issue in the Speech XG.
17:36:12 <francois> hta: Usually, you can read the form and find the address in the form, but sometimes the address is constructed by the JavaScript.
17:41:04 <fluffy> fluffy has joined #webrtc
17:41:10 <Youngsun> Youngsun has joined #webrtc
17:41:11 <pererik> pererik has joined #webrtc
17:41:21 <Mauro> Mauro has joined #webrtc
17:41:22 <yu1> yu1 has joined #webrtc
17:41:23 <anant> anant has joined #webrtc
17:41:25 <manyoung_> manyoung_ has joined #webrtc
17:41:30 <YW> YW has joined #webrtc
17:41:32 <JonathanJ> JonathanJ has joined #webrtc
17:41:34 <igarashi> igarashi has joined #webrtc
17:41:34 <richt> richt has joined #webrtc
17:41:58 <burn> burn has joined #webrtc
17:42:46 <Kangchan> Kangchan has joined #webrtc
17:43:43 <hiroki> hiroki has joined #webrtc
17:43:53 <narm_gadiraju> narm_gadiraju has joined #webrtc
17:43:58 <ceyrigno> ceyrigno has joined #webrtc
17:44:03 <JohnS_> JohnS_ has joined #webrtc
17:44:06 <hta> hta has joined #webrtc
17:44:21 <gang_> gang_ has joined #webrtc
17:45:36 <gang_> gang_ has joined #webrtc
17:45:37 <francois> francois has joined #webrtc
17:45:49 <francois> ekr: Partial digression on network attackers. If I'm in an Internet Cafe, and an attacker manages to inject an Iframe, he can bug my computer, redirecting the call to him. The attacker controls the network on HTTP.
17:45:53 <francois> ... Assumption is that it's safe to authorize PokerWeb and then surf the Internet. It's basically the same on your Wifi if not secure enough. 
17:45:59 <francois> ... An open question is: should this facility be available on HTTP at all? Mandate HTTPS? 
17:46:09 <francois> ... e.g. an HTTPS page that loads jQuery through HTTP 
17:46:12 <francois> DanD: not all the devices have the ability to securely preserve a token. That would be a good way to solve the problem. 
17:46:22 <hta> Slides: https://svn.resiprocate.org/rep/ietf-drafts/ekr/tpac2011/rtcweb-security.pdf
17:46:45 <dom> dom has joined #webrtc
17:47:05 <dom> RRSAgent, pointer?
17:47:05 <RRSAgent> See http://www.w3.org/2011/10/31-webrtc-irc#T17-47-05
17:47:27 <francois> ekr: [thoughts on consent for real-time peer-to-peer communication]
17:47:28 <francois> ... From a protocol point of view, we have ICE. Remember that you cannot trust the JS.
17:47:28 <francois> burn: the point is you disabled security completely 
17:47:31 <francois> ekr: not entirely agree that it's the same thing 
17:48:37 <francois> ... Transaction ID needs to be hidden from the JavaScript
17:48:37 <francois> ekr: When I surf to HTTP gmail, any attacker can inject the JavaScript and redirect calls for him. 
17:48:39 <francois> ... In the context of SIP, we're already addressed most of communications security issues.
17:48:40 <francois> ... There's also protocol attack issue which hopefully should not be a real problem in the end.
17:48:46 <francois> ... otherwise security issue.
17:50:17 <francois> ... Assuming that ROAP style API is used, we're going to make it good to hide security settings from JavaScript.
17:50:25 <darobin> darobin has joined #webrtc
17:51:09 <Suresh> Suresh has joined #webrtc
17:51:41 <francois> AdamB: IDs might be owned by FaceBoox, and so on.
17:51:50 <francois> ekr: my view is: 3 basic scenarios. 1) Gmail to Gmail, Facebook to Facebook, etc. 2) Gmail to Facebook, etc. where you'll need federation of ID. 3) Identity separated from the service I use to make the call.
17:52:13 <francois> ... I have some possible solutions for that. Happy to discuss.
17:52:51 <francois> Cullen: My position is a bit stronger. This group wants encrypted calls, but if you can't tell who the call is going to, that's useless.
17:52:59 <francois> ... We need to take that into account.
17:54:24 <francois> hta: for many cases, I think it's quite ok to say that the call is encrypted to an identity and that this identity is verified by the fact that the guy I talk to presented himself.
17:54:49 <francois> cullen: I want to know the trust chain. If this call is being intercepted, I want to have some indication on that.
17:55:13 <francois> anant: slightly disagree with what Harald said.
17:55:30 <francois> ... The federated use case.
17:55:43 <francois> burn: how do you know that things are going to the right person?
17:55:57 <francois> Anant: given that we have that use case in the document, we have to touch upon that issue.
17:56:04 <[1]Mauro> [1]Mauro has joined #webrtc
17:56:08 <Mohammed> Mohammed has joined #webrtc
17:56:10 <francois> ... We want a completely peer-to-peer system in the end.
17:56:36 <francois> ekr: Is there a good way to bootstrap these systems? I think the answer is "yes".
17:56:57 <francois> RRSAgent, draft minutes
17:56:57 <RRSAgent> I have made the request to generate http://www.w3.org/2011/10/31-webrtc-minutes.html francois
17:57:10 <Mani> Mani has joined #webrtc
17:57:23 <francois> Topic: Status and plans in the DAP WG
17:57:31 <francois> Present+ Robin_Berjon
17:57:50 <francois> Stefan: wanted to know status of controlling camera and microphone.
17:58:18 <francois> robin: Hi. I'm chair of DAP. We need to figure out how we split the work on who does what.
17:58:21 <adambe> adambe has joined #webrtc
17:58:30 <francois> ... We haven't done a lot of work on Media Capture recently.
17:59:18 <francois> ... One dividing line that could be useful: DAP could be picking up media capture very quickly, some interest from DAP side.
17:59:46 <francois> ... We would do the simple thing that doesn't include streaming or any complex processing.
18:00:03 <francois> ... Then hopefully this would be pluggable in what this group needs
18:00:13 <francois> burn: what do you mean without streams?
18:01:33 <francois> robin: you could not bind a video stream to some back channel, but you could do stuff such as video mail or recording.
18:01:35 <francois> ... In the declarative style, most of it in the browser.
18:01:44 <francois> hta: main difference is who controls the UI.
18:01:51 <Zakim> -Joseph_Scheuhammer
18:01:53 <francois> Anant: If you're going to do programmatic access, important to agree on what they look like between groups. Another solution is you take care of declarative, and we handle programmatic way.
18:01:55 <youenn> youenn has joined #webrtc
18:01:57 <juberti> brb
18:02:07 <francois> ... If you do programmatic way, we may end up with two APIs doing sensibly the same thing
18:02:26 <francois> robin: heard feedback that some people wanted to do simple things immediately.
18:02:39 <francois> anant: cannot "simple" be done with pure declarative approach?
18:02:46 <francois> robin: not really.
18:03:42 <francois> anant: something we've discussed in Mozilla. Media type in the input, such as video/mp4. The browser prompts user with camera view. Nice property that is avoids to deal with security issues in a nice way.
18:04:20 <francois> robin: it would be useful if you had a demo you could show in DAP. We're meeting Thursday/Friday.
18:04:24 <lgombos> lgombos has joined #webrtc
18:04:31 <francois> Present+ Adrian_Bateman(obs)
18:05:20 <francois> Adrian: Microsoft just joined DAP. One of our interests is media capture. API based on what getUserMedia is doing. WebRTC could build on top of this API. This way, we could split the work easily.
18:05:40 <francois> Anant: does that mean that you have use cases that require programmatic APIs?
18:05:57 <francois> Adrian: yes, in general we want developers to build their own experience.
18:06:05 <francois> Cullen: how do you deal with permissions?
18:06:13 <francois> Adrian: same way as other APIs
18:06:29 <francois> Cullen: agree with short-term, long-term permissions presented here?
18:06:29 <ekr> ekr has joined #webrtc
18:06:45 <francois> Adrian: need to check, but didn't look wrong.
18:07:41 <francois> richt: in Opera, we agree that many use cases require getUserMedia but don't really need peer-to-peer connectivity. So agree to split things up.
18:08:28 <francois> Anant: can two groups work on the same spec?
18:08:54 <francois> Adrian: liaison explicit in the charter of WebRTC. Feasible for DAP to own the spec and go through the liaison.
18:09:20 <francois> richt: Peer-to-peer relies on a stream. We give you a stream and you deal with it.
18:09:44 <francois> Cullen: that's a bit more complex than that, because of the hardware support for compression, and permissions too.
18:10:03 <francois> ... It sounds DAP needs a permissions model as well and doesn't have one for the time being.
18:10:35 <francois> ... We have all the permission problems that have to be enforced at the getUserMedia level.
18:11:14 <francois> richt: the barcode scanner, face recognition use cases haven't been taken up in the group.
18:11:32 <francois> cullen: I don't think anyone will disagree with these use cases
18:11:42 <francois> hta: want to make things more complicated ;)
18:12:02 <francois> ... If you go on with the assumption that media is always sourced locally, you're in the bad corner.
18:12:40 <richt> s/require getUserMedia but don't really need peer-to-peer connectivity/require getUserMedia but we want to decouple that from peer-to-peer connectivity/
18:12:55 <francois> ... As long as it's a media stream, the current getUserMedia doesn't care where the stream is coming from. I look at it as a first and easy step.
18:13:38 <francois> ... thinking about Web Introducers.
18:14:10 <francois> robin: That's a DAP deliverable. I'd rather not drag this spec in this discussion, although I agree it's a good way to make introductions.
18:14:32 <francois> Anant: the resources you get are not more priviledged.
18:14:45 <francois> hta: I was more thinking about my computer getting access to your camera.
18:15:01 <francois> ... We might want to explore deeper levels of complexity for passing streams around at a later stage.
18:15:34 <francois> ... In terms of where things go, the WebRTC WG is chartered to get this thing done. The charter is written in such a way that if someone else does it, that's good!
18:16:19 <francois> ... What I don't want to happen is one group that comes with a vocabulary that describes front camera, back camera, etc. and another group coming with one on camera orientation, in particular.
18:17:10 <francois> dom: can getUserMedia be split from WebRTC spec in general? Independently of where the final spec resides, that's something people are interested in seeing sooner rather than later.
18:18:11 <francois> cullen: I'm just wondering how much faster things will be if we split things out. Browser vendors in WebRTC already indicated their intention to implement the spec.
18:18:33 <francois> dom: Implementations of getUserMedia in Opera.
18:18:43 <francois> hta: there's on in Chrome too but part of RTC.
18:19:05 <francois> richt: we're going to push something out soon with getUserMedia.
18:20:11 <francois> burn: actually, it's a "super-subset".
18:20:20 <francois> Anant: if it's published as a separate spec, the use cases of getUserMedia are a subset of use cases.
18:20:28 <Zakim> +Joseph_Scheuhammer
18:20:31 <Zakim> -Prospector_AB
18:20:32 <Zakim> +Prospector_AB
18:20:59 <francois> cullen: what I worry about is totally changing the directions we're going to in something we're supposed to ship in a matter of months.
18:21:04 <Zakim> -Joseph_Scheuhammer
18:21:08 <francois> [discussion on Microsoft joining WebRTC]
18:21:22 <francois> Present+ Dominique_Hazael-Massieux
18:21:40 <francois> dom: one way to have the IPR commitments that we want is to split spec out.
18:22:09 <francois> ... That means adding the SOTD, and accepting DAP's input.
18:22:27 <francois> Anant: if we start taking input from DAP, we're going to lose time.
18:22:34 <francois> dom: I don't think so, actually.
18:22:56 <francois> ... nothing more than what we'll get with last call comments.
18:23:43 <stakagi> stakagi has joined #webrtc
18:24:21 <francois> [further discussion on getUserMedia]
18:25:24 <francois> burn: this group wants to move forward very quickly. Other want it for other purpose. Is there a way to do something quickly that does not prevent other uses?
18:25:39 <francois> hta: getUserMedia returns a MediaStream, so MediaStream needs to be defined before getUserMedia
18:26:03 <Zakim> + +1.857.288.aaaa
18:26:13 <juberti> Zakim, aaaa is Justin_Uberti
18:26:13 <Zakim> +Justin_Uberti; got it
18:26:17 <francois> cullen: [back to hardward support for video compression]
18:26:52 <junya> junya has joined #webrtc
18:27:24 <francois> ... Lots of things are wrong and need to be fixed. We haven't focused on this right now. I'd like to see use cases that we're missing (yours are great, richt).
18:27:39 <francois> stefan: that's the direction I'd like to follow, yes.
18:27:57 <francois> burn: yes, would be good to have use cases to see what's missing.
18:28:39 <francois> richt: the only thing we get from getting to DAP is extra IPR coverage and comments.
18:28:49 <francois> cullen: is there a way to get comments early on?
18:29:16 <francois> adrian: there's a lot of process involved to get comments sent to a group we're not participating on.
18:29:22 <francois> [discussion on IPR commitment]
18:32:30 <francois> robin: Nothing bad in splitting up and doing a joint deliverable.
18:32:59 <francois> dom: getting comments is something the group needs.
18:33:48 <francois> s/needs./needs to do./
18:34:18 <francois> Suresh(RIM): so what happens to the draft in DAP's group?
18:34:28 <francois> robin: we'll kill it and keep the declarative one.
18:34:56 <francois> richt: it needs killing. Nothing happened on this spec for a year.
18:35:10 <francois> Stefan: so what do we need to do in the end?
18:35:37 <francois> dom: we need to ensure DAP agrees with that direction and then you need to split up the part.
18:35:51 <ceyrigno_> ceyrigno_ has joined #webrtc
18:35:54 <francois> ... The key question is where you draw the line. The administrative side is easy.
18:36:32 <francois> Anant: Fine to reference WebRTC spec for definition of MediaStream?
18:36:48 <francois> dom: yes, but introduces a dependency in terms of timeline.
18:37:00 <francois> ... Other question is editing.
18:37:20 <francois> cullen: I want someone with deep understanding of video
18:37:42 <francois> Adrian: we're happy to participate to make things easier since we're making things more complex to start with.
18:37:49 <francois> robin: ready to volunteer an editor?
18:37:56 <francois> Adrian: I think so.
18:38:07 <ekr> ekr has joined #webrtc
18:38:26 <francois> burn: if requirements are separable, that may be good to separate them.
18:39:00 <francois> cullen: I think this group should agree on the mailing-list before things get done.
18:39:17 <francois> Stefan: we have had chairs discussions earlier on.
18:39:32 <francois> richt: all of the work is staying in WebRTC in the end.
18:39:44 <francois> robin: all you get is better IPR protection and better comments.
18:40:44 <francois> cullen: important to put it on the list, first time people will hear about it.
18:41:09 <francois> stefan: anyone objecting to have a joint deliverable?
18:41:53 <francois> PROPOSED RESOLUTION: split up getUserMedia and publish as joint deliverable with DAP WG.
18:42:22 <francois> cullen: worried that joint deliverables always take longer.
18:43:07 <francois> robin: one thing that is important is to specify which mailing-list takes discussions. We really should not have joint deliverable where discussion is split in groups. Smallest issues turn into a war when that happens.
18:43:21 <richt> proposal to RESOLUTION status: one/two week period for mailing list discussion. Resolution to be made on next conf. call. (?)
18:45:18 <francois> cullen: this whole thing is an integrated system. It's going to be very difficult to discuss this without discussing other ideas.
18:45:36 <francois> dom: I think the key issue is splitting the spec, not the joint deliverable.
18:45:56 <francois> robin: if we can't split the discussion, then we probably can't split the spec.
18:46:44 <francois> burn: question is: can we write WebRTC requirements for getUserMedia precisely enough for this virtual joint working group.
18:47:11 <francois> cullen: you'll need so much low-level details in getUserMedia
18:48:08 <francois> robin: two actions: one on splitting the spec, second on refining joint proposal.
18:48:54 <francois> ACTION: anant to check how to split getUserMedia from the spec
18:48:54 <trackbot> Created ACTION-8 - Check how to split getUserMedia from the spec [on Anant Narayanan - due 2011-11-07].
18:49:14 <francois> ACTION: robin to draft a draft proposal for joint deliverable.
18:49:14 <trackbot> Sorry, couldn't find user - robin
18:49:40 <francois> burn: Adrian, do you actually need to see something pulled out first before you can help out?
18:50:03 <francois> Adrian: we can help with splitting out the spec, I think.
18:50:17 <francois> burn: it's more a pratical question, given the way editors work in WebRTC.
18:51:00 <francois> cullen: can someone send use cases on one of the mailing-lists?
18:51:27 <francois> ACTION: rich to send new use cases on getUserMedia to webRTC mailing-list
18:51:27 <trackbot> Sorry, couldn't find user - rich
18:51:38 <francois> ACTION: tibbett to send new use cases on getUserMedia to webRTC mailing-list
18:51:38 <trackbot> Created ACTION-9 - Send new use cases on getUserMedia to webRTC mailing-list [on Richard Tibbett - due 2011-11-07].
18:52:39 <francois> [discussion on DAP interaction over]
18:53:59 <ekr> ekr has joined #webrtc
18:54:09 <francois> RRSAgent, draft minutes
18:54:09 <RRSAgent> I have made the request to generate http://www.w3.org/2011/10/31-webrtc-minutes.html francois
18:54:18 <dom> dom has left #webrtc
18:54:44 <richt> richt has joined #webrtc
18:55:03 <stefanh> stefanh has joined #webrtc
18:55:28 <francois> Topic: Access control model and privacy/security aspects
18:55:44 <francois> scribe: burn
18:55:44 <burn> ScribeNick:  burn
18:56:59 <francois> [@@link to slides when available]
18:57:27 <burn> anant:  currently don't specify what happens with user permission when using getUserMedia
18:57:45 <burn> ... UAs vary, so may not be appropriate to define a standard for permissions
18:58:16 <burn> ... propose we write guidelines for browsers rather than something mandated
18:58:58 <burn> richt:  this is definitely difficult to get right.  UA should provide opt-in in UA
18:59:25 <burn> francois:  typically such SHOULD requirements aren't testable so they become guidelines in the end
18:59:52 <burn> ... there is a way to make such informative statements
19:00:43 <burn> hta:  browser differentiation is harmful to user.  we have enough browser representation here to figure out where we have agreement and should have recommendations that reduce unnecessary differentiation
19:01:36 <burn> richt:  we don't mention doorhangers because there is a lot more that can be done.
19:02:04 <burn> fluffy:  we can say "browser needs to somehow do X" without specifying precisely how.  
19:03:20 <burn> ... if completely optional no one implements.  we can learn from existing softphones, etc.  I like the "check my hair" dialog, a UA where there is a popup that tells you you're sending video and who you're sending it to.  PeerConnection could confirm that this is correct.
19:03:31 <burn> (UA = User Agent = Browser)
19:04:07 <burn> fluffy:  e.g. JS can select camera, provide name of contact to that is displayed at the same time.
19:04:35 <burn> ... can't check before connection happens, but later can cancel if PeerConnection learns name is wrong
19:04:53 <burn> anant: mandate requirements on UI but not how to do it.
19:04:57 <burn> burn:  +1
19:05:56 <burn> anant:  hta believes that opera user contacts chrome user, so differences could be confusing.  right?
19:06:31 <burn> francois:  some apps will use getUserMedia to send it, and others will use it for local purposes, so needs are different
19:06:44 <burn> anant:  maybe app has to make clear what media will be used for.
19:07:01 <burn> francois:  user might have consented to call in advance of using getusermedia
19:07:08 <burn> anant:  we can check for stored permission
19:07:34 <burn> ... do we have consensus to lay out steps but not specify how?
19:07:39 <burn> (generally yes)
19:07:57 <burn> richt:  not sure.  we don't know what we need to show yet
19:08:09 <burn> anant:  we know some things, like previewing video
19:08:25 <burn> richt:  anything that doesn't affect interop should not be required
19:08:49 <burn> fluffy:  where we need encrypted name we need to require this
19:09:05 <burn> richt:  let's not bake in too quickly because we are still experimenting
19:09:46 <burn> fluffy:  today we support encrypted media (but not yet required).  problem would be like using TLS but not showing name of site.
19:09:59 <burn> anant:  we need global identifiers
19:10:30 <burn> adambe:  with p2p may not know all names in advance.
19:10:44 <burn> anant:  UI for accepting and initiating calls may be very different
19:11:10 <burn> adambe: what about two people talking and a third joins.  media streams already availaeble.
19:11:25 <burn> fluffy:  same problem if you have single conversation moved from one entdpoint to another
19:12:02 <burn> hta: good to discuss, but don't agree with cullen's request to mandate requirements.  want to hear about stuffy other than just names
19:12:07 <burn> anant:  (returning to slides)
19:13:20 <burn> ... do we allow apps to enumerate devices?  no, would like for app to request what it needs (say, hints proposal).
19:13:42 <burn> ... if user agrees, we return success call.
19:14:21 <burn> ... user should always have complete control over what is transmitted, independent of what the app asks for
19:14:59 <gang> gang has joined #webrtc
19:15:02 <burn> adambe:  with proper hints you need to enumerate and can get same result.  prefer hints approach
19:15:10 <YW> YW has joined #webrtc
19:15:30 <francois> francois has joined #webrtc
19:15:38 <Youngsun> Youngsun has joined #webrtc
19:16:19 <burn> fluffy: every app i use for voice and video allows me to switch cameras and mics.  how does that work
19:16:45 <burn> anant:  don't want app to choose switching, but want user to be able to switch
19:16:57 <burn> ... UI has to be independent in UA independent of app
19:17:57 <burn> burn:  in html speech we have notion of default mic.  app doesn't choose, the user does via the chrome.
19:18:24 <burn> fluffy:  yes, happens all the time.  i'm using existing crummy mic or camera, go find a better one and plug it in.
19:19:01 <burn> Tim:  others want to know what's available in advance so you don't even prevent option if it doesn't exist
19:19:21 <burn> anant:  hints can solve this.  some hints are compulsory, others optional.
19:19:32 <burn> francois:  can't app just check?
19:19:44 <burn> anant:  this way doesn't reveal info about user.
19:20:19 <burn> burn:  failures give user info
19:20:41 <burn> richt:  yes, hints are good.  web app doesn't need to know which camera.
19:21:36 <richt> webapps provide a hint in the true sense of the word but the impl. can fallback to any camera if necessary (rather than fail).
19:21:59 <francois> francois: exposing capabilities is fingerprinting issue. Exposing "incapabilities" is as well.
19:22:03 <burn> anant:  the comment was that UIs are best when they know what devices are available
19:22:18 <francois> anant: right, the key is the time it takes so that the app can't tell it's a fail because of an incapability and a user action.
19:22:41 <francois> RRSAgent, draft minutes
19:22:41 <RRSAgent> I have made the request to generate http://www.w3.org/2011/10/31-webrtc-minutes.html francois
19:22:56 <burn> hta:  if you don't know what's available you can't distinguish between "you need more cameras to run this app" and "you need to allow me to use more cameras"
19:23:05 <burn> richt:  we can't allow fingerprinting
19:23:16 <burn> ... one error, regardless of how it fails
19:23:39 <junya> junya has joined #webrtc
19:23:41 <burn> fluffy:  when would you need a case where you'd rather have a failure than use a hint?
19:23:59 <burn> ... would rather feed one camera into both than a failure
19:24:10 <burn> anant:  (back to slides, showing early mockup)
19:25:11 <burn> ... doorhanger hanging off info bar indicates that it's a web app rather than the browser.  don't like this approach, but best so far.
19:25:54 <burn> ... we have "hair check", live preview of camera before communication is active.  can mute audio, click to share cameras
19:26:29 <burn> ... webcam button on address bar gives you options to change cameras (in UI, part of browser)
19:26:42 <burn> adambe:  what about webcam with microphone display in it
19:27:09 <burn> anant:  we should allow it, but may be an advanced checkbox.  want 95% of use cases to be handled
19:27:43 <burn> fluffy:  sounds need to be able to changed to where they come from and where they go.
19:28:25 <burn> ... we will see this more and more as you have more devices.  "skype headset" and "facebook headset"
19:28:51 <burn> richt:  what about tabbing implications.  when you swithch tabs need to know what happens
19:28:58 <burn> anant:  will get to that
19:29:23 <burn> ... (back to slides)  default to what app asks for but users can always override
19:29:37 <burn> ..  preferences pane to control all
19:29:44 <narm_gadiraju> please post the URI to the presentation to irc
19:29:48 <burn> ... mockup used one-time permission grant model
19:30:12 <burn> ... we allow user to say "always allow example,org to access a/v"
19:31:03 <burn> tim:  if browser on phone and in pocket and permission has been given, app could just turn it on in my pocket.  accelerometer info can tell you that the person is walking (and may have in pocket).
19:31:18 <burn> richt:  we will use some kind of visual and/or vibration to indicate
19:31:36 <burn> anant:  we need something because users won't want to clkci every time at facebook
19:31:50 <burn> richt:  we could try to learn it based on user behavior
19:32:20 <burn> fluffy:  from privacy standpoint, webex on your phone and laptop could do this today.
19:32:49 <hiroki> hiroki has joined #webrtc
19:32:59 <burn> ... it always starts with strong privacy position and eventually disappears to no privacy.  better to have something only strong enough that it is still used
19:33:16 <ceyrigno> ceyrigno has joined #webrtc
19:33:26 <burn> ... indicators are probably more important than prevention
19:33:46 <burn> ... anything stronger than this will be widely ignored.
19:33:53 <burn> richt:  that is already in spec
19:34:10 <burn> anant:  maybe sholud also have vibration or audio indication
19:34:24 <burn> stefan:  how is this compared to geolocation
19:34:29 <burn> richt:  we are 10, they are 2
19:34:55 <burn> adambe:  like "watch position" but without user knowing
19:35:12 <burn> anant:  need to let user know that previously-given permisison is now using it
19:36:16 <burn> fluffy:  users hate apps that grabbed device and turned on indicator.  needs to be when device used.
19:36:30 <burn> anant:  in today's world we won't exclusively grab device that way anymore
19:36:56 <burn> ... should web app be able to specify what type of access it needs?
19:37:07 <burn> richt:  user should always be in control
19:37:24 <burn> francois:  maybe app could say instead when it does'nt need long-term access
19:37:54 <burn> hta:  option of granting long-term access only the second time you try it has worked well
19:38:40 <burn> (back to slides)  initially tried to tie permisison grant to a time-frame and domain name.
19:38:52 <burn> s/(back/anant: (back/
19:39:10 <burn> ... deevvlopers hated this.  want permissions tied to user session not just domain
19:39:42 <burn> ... could perhaps allow app itself to revoke a permission if it detects a change in user session.
19:41:16 <burn> fluffy:  can JS app provide a user-identifying token, so can index using both user criteria and this token
19:41:32 <burn> anant: yes, as optional param in JS call.  could try it.
19:41:46 <burn> richt:  browser can handle this since it runs session.
19:41:55 <burn> anant: we don't know what's in cookie, so no.
19:42:08 <burn> ... but most websites won't use it.
19:42:30 <burn> burn:  financial sites wil like this.
19:42:46 <burn> fluffy: bad guys don't care but helps good guys ==> okay
19:43:27 <burn> richt:  if you injected script that just replays in different domain you can get permission easily
19:43:29 <burn> anant:  how
19:43:47 <burn> richt:  user-installed script
19:43:55 <burn> anant:  yeah, but then you can do anything
19:44:09 <burn> ... (back to slides, showing mockup of notification)
19:44:53 <burn> ... one option is the entire tab pulses, with camera/mic control right on tab.
19:45:14 <burn> richt:  we pin audio/video.  user has to explicitly request keeping it.
19:45:31 <burn> hta:  needs to be in spec
19:45:52 <burn> ... switch tabs all the time and want my voice to be heard
19:46:08 <burn> anant: tricky across all UIs, including video phone
19:46:59 <burn> fluffy:  something unspecified that irritates user is whether a video starts playing when you open a new tab.  we should make this the same everywhere
19:47:07 <burn> anant:  we browser vendors need to work this out.
19:47:39 <burn> ... prefer default of not blocking audio/video just because you switched tabs.  if new tab wants to start video, should ask user.
19:48:14 <burn> richt: but may be hard to tell which tab has audio/video
19:48:24 <burn> anant:  if whole tab pulses it works
19:49:11 <burn> anant:  (back to summary slide)  (missed question from anant)
19:49:30 <burn> ... maybe can't tell which app is requesting access
19:50:04 <burn> ... what is interaction for incoming call.  assume signed in to service to receive call/audio
19:50:30 <burn> fluffy:  yes, but others might want web apps that run in the background and have no bar (headless web apps)
19:50:50 <burn> s/(missed question from anant)/what happens if device already in use by other app/
19:50:51 <hiroki> hiroki has joined #webrtc
19:51:35 <burn> hta:  if headless web app reads sdp off disk and passed into PeerConnection, it should just work, with no browser connection.
19:52:12 <burn> anant:  so we should allow headless apps and let browser determine how incoming call works.
19:52:32 <burn> fluffy:  some chrome has to be involved when video is requested.
19:52:50 <burn> anant:  yes.  js can tell user about incoming call, but then need to get permission.
19:53:11 <burn> hta:  gum (getUserMedia) should have enough info to identify where call is from 
19:54:14 <burn> ... apps will want "one button accept".  can't avoid showing some chrome.  would be better for that to be the doorhanger.  neeed extra API call so web app calls receiver's browser and asks if they want to accept.  then get doorhanger.
19:54:26 <burn> oops, previous speaker was anant
19:54:50 <burn> richt: (missed detailed example)
19:55:45 <burn> fluffy:  sometimes want long-term approval to at least negotiate and reveal IP address.  also a different mode where don't reveal IP address until user has accepted.
19:56:05 <burn> ... first one allows you to deal with ICE slowness by doing ICE and acceptance in parallel.
19:56:19 <burn> francois;  users won't understand this distinction.
19:56:39 <burn> fluffy:  okay, then maybe don't need first case.
19:57:02 <burn> anant:  we don't know how to implement incoming call.
19:57:12 <burn> richt:  can do OS-level notification
19:57:25 <burn> anant:  yes, but also want to give all the user controls when accepting control.
19:57:39 <burn> s/control./call./
19:58:10 <burn> anant:  other questions (not on slides)
19:58:20 <JonathanJ> JonathanJ has joined #webrtc
19:58:47 <burn> ... what about embedded iframes?  we don't allow anything other than toplevel to do that.  an iframe would have to pop up its own toplevel window to do this.
19:58:54 <burn> richt:  what happens with geolocation?
19:59:02 <burn> anant:  we don't do the same but would like to
19:59:33 <burn> ... other use case is where ad is embedded in slashdot.  In that case slashdot is accepting responsibility and you are giving permission to slashdot.
19:59:46 <burn> richt:  iframes from different origin
19:59:58 <burn> anant:  yes.  if same origin we just let them through.
20:00:09 <burn> (general approval of this approach)
20:00:37 <burn> adambe;  what about call-in widget you can add to page.  
20:00:42 <burn> anant: can't avoid this.
20:00:53 <burn> adambe:  could sandbox the iframe.  
20:01:07 <burn> anant:  problem is that user does'nt know it's a different site.
20:01:30 <burn> ... when new top bar user can tell
20:02:14 <burn> ... also, only allow long-term approval for https
20:02:48 <burn> ... don't enforce https for all uses, but definitely if site wants long-term access
20:03:01 <burn> fluffy:  what about mixed content
20:03:47 <burn> ... will probably need more discussion.  everyone will hate requiring https, but they may realize they need it.
20:05:02 <burn> ... difficulty today requiring https is that many sites would break today.  but with new sites where everything needs to be built from scratch, like with webrtc, we could require it now.  we should consider it.
20:05:07 <burn> ... but we need more info.
20:06:28 <burn> richt:  could do tls as JS, so that might take care of it
20:06:47 <burn> hta:  that's giving JS direct access to TCP
20:07:06 <pererik> pererik has joined #webrtc
20:07:28 <burn> ... JS should not have this power!
20:07:45 <Zakim> -Prospector_AB
20:08:22 <burn> rrsagent, draft minutes
20:08:22 <RRSAgent> I have made the request to generate http://www.w3.org/2011/10/31-webrtc-minutes.html burn
20:08:31 <juberti> everything went silent...
20:12:00 <ekr> ekr has joined #webrtc
20:14:26 <hiroki> hiroki has joined #webrtc
20:15:56 <darobin> darobin has joined #webrtc
20:16:40 <igarashi> igarashi has joined #webrtc
20:18:27 <JonathanJ> JonathanJ has joined #webrtc
20:25:53 <Zakim> -Justin_Uberti
20:25:54 <Zakim> UW_(WebRTC)12:00PM has ended
20:25:55 <Zakim> Attendees were Joseph_Scheuhammer, Prospector_AB, +1.857.288.aaaa, Justin_Uberti
20:25:57 <igarashi> igarashi has joined #webrtc
20:26:57 <darobin> darobin has left #webrtc
20:30:09 <Zakim> Zakim has left #webrtc
20:31:16 <ekr> ekr has joined #webrtc
20:31:47 <juberti> juberti has left #webrtc
20:32:52 <juberti> juberti has joined #webrtc
20:39:28 <stakagi> stakagi has joined #webrtc
20:51:07 <igarashi> igarashi has joined #webrtc
20:58:37 <hayashi> hayashi has joined #webrtc
21:02:42 <jun> jun has joined #webrtc
21:03:32 <burn> burn has joined #webrtc
21:03:41 <Kangchan> Kangchan has joined #webrtc
21:03:51 <Zakim> Zakim has joined #webrtc
21:05:20 <ileana> ileana has joined #webrtc
21:06:37 <Johns> Johns has joined #webrtc
21:06:56 <igarashi> igarashi has joined #webrtc
21:06:58 <DavidKim> DavidKim has joined #WebRTC
21:07:34 <richt> richt has joined #webrtc
21:09:16 <fluffy> fluffy has joined #webrtc
21:10:04 <hta> hta has joined #webrtc
21:10:12 <YW> YW has joined #webrtc
21:10:18 <anant> anant has joined #webrtc
21:10:43 <francois> francois has joined #webrtc
21:10:54 <francois> RRSAgent, draft minutes
21:10:54 <RRSAgent> I have made the request to generate http://www.w3.org/2011/10/31-webrtc-minutes.html francois
21:10:57 <francois> Topic: Stages for moving to a Rec
21:10:57 <fluffy> Moving on to Dan talking about W3C Recommendation practice
21:11:09 <juberti> can someone kick the polycom
21:11:11 <DanD> DanD has joined #webrtc
21:11:15 <stefanh> stefanh has joined #webrtc
21:11:37 <francois> zakim, dial Projector_AB
21:11:37 <Zakim> sorry, francois, I don't know what conference this is
21:11:45 <francois> zakim, this will be WebRTC
21:11:45 <Zakim> ok, francois, I see UW_(WebRTC)12:00PM already started
21:11:50 <francois> zakim, dial Projector_AB
21:11:50 <Zakim> I am sorry, francois; I do not know a number for Projector_AB
21:11:51 <Mohammed> Mohammed has joined #webrtc
21:12:14 <hiroki> hiroki has joined #webrtc
21:12:19 <fluffy> Discution of Consunsus
21:12:31 <fluffy> Moving on To First Public Working Draft slide 
21:12:38 <francois> zakim, dial Prospector_AB
21:12:38 <Zakim> ok, francois; the call is being made
21:12:39 <Zakim> +Prospector_AB
21:12:49 <juberti> thanks
21:13:24 <ceyrigno> ceyrigno has joined #webrtc
21:13:40 <fluffy> Some groups publish every 6 months, this group more like every month, 
21:14:36 <fluffy> Scribe: fluffy
21:14:51 <francois> i/Moving on to Dan /Topic: Stages for moving to a Rec
21:16:08 <fluffy> Good to reach out to groups with opinions early. 
21:16:30 <DavidKim> David Kim from SK telecom joined this meeting in this morning.
21:17:25 <Mohammed> Mohammed has joined #webrtc
21:17:35 <Mauro> Mauro has joined #webrtc
21:17:36 <fluffy> On the "Candidate Recommentation" slide
21:19:06 <fluffy> At this stage, you defend the document needs the need - at this point, you need to have a test suite that tests the spec, not the implementations. 
21:19:25 <fluffy> Anadt: Is this code and what is it run against? 
21:19:44 <fluffy> s/Anadt/anant/
21:20:21 <fluffy> francois: There is another group trying to come up with generic test framework that can be used
21:21:29 <fluffy> francois: Should think about how to write a testable specification when you write the spec
21:21:53 <fluffy> Dan: great to have the spec working be the same as the assertion code in test 
21:25:12 <fluffy> Can two implementations share code? If have good answer, perhaps OK, but ...
21:26:50 <fluffy> Some times single implementations of optional features 
21:29:21 <fluffy> Dan: on to Proposed Recommendation slide 
21:29:47 <fluffy> francois: This is stage where W3C members have their last chance to comment 
21:30:05 <fluffy> Dan: On to Recommendation slide 
21:30:39 <fluffy> anant: How do we deal with later version of spec for features we wanted in a later version ?
21:31:26 <fluffy> francois: Need to recharter WG, go thorough same processes, 
21:32:00 <fluffy> … also a proposed edited process to include just a small thing (rare)
21:32:59 <fluffy> Dan: ON to addressing public comments 
21:35:16 <fluffy> Harald: What's process when can't agree
21:35:35 <fluffy> francois: Gets raised as formal objection that goes up to W3C directorate 
21:35:43 <Ruinan> Ruinan has joined #webrtc
21:36:54 <fluffy> Dan: On to Status of WebRTC API draft slide 
21:41:06 <fluffy> richard: should we stay at candidate for a year or so 
21:41:20 <juberti> Data channel slides: https://docs.google.com/presentation/pub?id=10OpPqGB2hhXxMFLeqok5wrwL10oDzUK4Vq7hqy_N5pc&start=false
21:41:34 <fluffy> Dan: better to have an exit criteria - such as meet this number of implementations 
21:42:07 <ekr> Justin: this slide could not laod, try again
21:43:02 <fluffy> Dan: two specs on their own time line other than whatever reference dependencies are 
21:43:56 <ekr> Looks like just a google apps for business conflict. works fine on my personal account
21:45:33 <fluffy> anant: If we are doing two specs, should we push out our dates beyond Q2 ?
21:45:48 <Linuz> Linuz has joined #webrtc
21:46:03 <fluffy> francois: at the point we know we won't make it, then will need to update 
21:46:44 <fluffy> Topic: Low Level Control 
21:46:51 <juberti> ok, let me know if anyone else hits problems
21:47:12 <fluffy> Scribe: anant
21:47:17 <anant> Moving to low-level control presentation by burn
21:48:45 <anant> Dan: original proposal for a low level API (link in slide 2) received limited discussion and little support from IETF's signaling API
21:48:53 <anant> Dan: But there is some interest in a low level API
21:49:16 <anant> Dan: Look at requirements document (IETF) by hadriel to drive discussion
21:49:52 <anant> Dan: Hints vs Capabilities will be an interesting discussion
21:50:26 <anant> Dan: Some discussion now but we should move it to list soon
21:50:56 <anant> Dan: Existing requirements are not the same level (higher level) than what we want for low level hints and capabilities
21:52:29 <anant> Dan: Browser UI requirements are things we've discussed and should move into the current document
21:52:53 <Kangchan> http://tools.ietf.org/html/draft-kaplan-rtcweb-api-reqs-00
21:53:15 <anant> Dan: Media properties are the interesting ones
21:56:19 <francois> francois has joined #webrtc
21:57:13 <Soonho> Soonho has joined #webrtc
22:00:38 <James> James has joined #webrtc
22:00:46 <anant> Dan: A2-1 a web API to learn what codecs a browser supports
22:01:00 <anant> anant: How does this relate to JS application-level decoders/encoders?
22:01:29 <anant> fluffy: that's independent of an API that exposes what codecs the browser takes
22:01:39 <Kangchan> Kangchan has joined #webrtc
22:01:56 <anant> tim: the API can only be used after the user has consented, so there's already some trust in the app
22:04:24 <ekr> ekr has joined #webrtc
22:04:33 <anant> fluffy: we should go through all of the requirements
22:06:37 <fluffy> was that adam roach speaking ?
22:06:47 <derf> fluffy: It's juberti.
22:06:52 <fluffy> ah - thanks
22:07:19 <stakagi> stakagi has joined #webrtc
22:08:12 <DavidKim> DavidKim has joined #WebRTC
22:08:38 <juberti> regarding fingerprinting, aren't we sending user-agent already
22:08:48 <Mani> Mani has joined #webrtc
22:09:08 <derf> We've (jokingly) discussed replacing the user-agent with an empty string.
22:09:15 <Kangchan> Kangchan has joined #webrtc
22:09:37 <anant> juberti: need to be able to query browser capabilities so that JS can generate SDP on its own
22:09:45 <juberti> i think there are enough implementation differences that fingerprinting can be done using existing apis.
22:09:49 <anant> (without user consent?)
22:10:02 <juberti> user consent is ok
22:10:13 <juberti> this would happen around the same time as camera access
22:10:31 <derf> But if you're going to have hardware codecs, capabilities can differ even with the same UA.
22:11:03 <juberti> the thought experiment here is whether it would be possible to fully implement signaling, except for telling the browser what the offer and answer are.
22:11:05 <gang> gang has joined #webrtc
22:11:13 <juberti> (fully implement signaling in JS)
22:11:34 <ekr> there are a lot of fingerprinting mechanisms out there. is this really making it worse?
22:12:43 <anant> tim: but how can you restrict information if you want JS to encode/decode (eg: hardware support for some codecs at certain resolutions)
22:13:29 <derf> ekr: It clearly makes it worse. The question is, is it worth the price?
22:14:00 <juberti> I don't like having to expose a billion knobs to JS, but if we can give the browser a SDP blob from JS, that might allow a flexible but simple compromise.
22:14:12 <anant> harald: if you negotiate on the principle that SDP is generated independently of setting up media streams then you don't need permission - there are use cases for that
22:14:15 <juberti> to generate said blob, we need to know what the browser supports.
22:15:09 <derf> juberti: Sounds like you're asking to give the browser an ANSWER from JS, and you want an OFFER in order to generate it.
22:15:21 <derf> Or did I miss what you were really asking?
22:15:35 <anant> dan: we jumped from A2-2 to A2-3, but they both look like they go together
22:16:02 <anant> fluffy: what is the use case for knowing codec properties? it only makes sense if you can control the properties
22:16:36 <Mani> would it be more appropriate to require that the capabilities described should be consistent with the capneg RFC5939 security properties?
22:17:39 <James> James has joined #webrtc
22:18:12 <anant> adam: is A2-2/A2-3 a codec abstraction of some kind?
22:18:26 <anant> harald: you want to select the best possible codec for a given bandwidth requirement
22:18:32 <juberti> derf: I want to generate an OFFER in JS. I send the offer to the remote side, and also tell my own browser about it. The remote side generates an ANSWER in JS from the OFFER, tells the browser about both, and sends the ANSWER back to the initiator. The initiator then plugs the received ANSWER into the browser, and media flows.
22:18:42 <anant> harald: different for video and images etc.
22:19:12 <derf> juberti: Okay. Why can't you do that with ROAP today?
22:19:45 <burn> burn has joined #webrtc
22:19:46 <Kangchan> Kangchan has joined #webrtc
22:20:36 <juberti> a) you can't generate the OFFER, since you don't know the browser caps. b) even if you could generate your own offer, there's no way to tell the local browser about it. lastly, the state machine for ROAP lives inside the browser, so the JS can only do what ROAP allows (i.e. no trickle candidates like Jingle)
22:22:10 <ekr> clarification: trickle candidates is candidates in pieces like with Jingle transport-info?
22:22:19 <juberti> ekr: exactly
22:22:22 <derf> juberti: fluffy is saying what I would have replied to you right now.
22:22:33 <francois> scribe: francois
22:22:33 <francois> richt: considering whether you can update the SDP proposal the browser sends to the JS directly through JavaScript
22:22:37 <juberti> the polycom went dead
22:22:46 <hta> Juberti, I hear you typing.
22:22:56 <francois> cullen: when we get to ROAP, we'll see that it's possible.
22:22:59 <juberti> now i hear 
22:23:14 <juberti> ok
22:23:15 <francois> anant: in order for JavaScript to add things to SDP, it needs to be able to query.
22:23:50 <francois> cullen: if the browser supports stuff that it didn't say it supports, then it's only normal that you cannot use it.
22:24:34 <francois> cullen: I think you're going to get that one way or the other, so not opposed to an API.
22:24:40 <juberti> sure, thanks for doing that
22:25:19 <francois> hta: we don't have an opaque proposal between browsers right now.
22:25:28 <francois> cullen: in the SIP proposal, you do
22:25:36 <francois> hta: cannot be used to setup the initial connection
22:26:06 <ekr> SIP isn't really opaque, it just looks opaque.
22:26:12 <francois> cullen: if we're trying to protect from fingerprinting, we need to know what kind of information we think we can reveal.
22:26:26 <francois> anant: hardware information is the critical key
22:26:47 <francois> ... Easy to identify who the user is with some nuances on hardware capabilities.
22:27:20 <francois> hta: are we getting it worse in a way that makes a difference, that's the question.
22:27:46 <francois> [exchanges about fingerprinting]
22:28:31 <francois> cullen: my guess is that even fingerprinting was revealing that I'm using a Mac Book Air, that's still a large set.
22:29:19 <ekr> francois: there's a lot more uniqueness than that. For instance, window size, fonts, plugin support, etc.
22:29:35 <francois> burn: going through the requirements provides food for issues that are relevant.
22:29:45 <gang> gang has joined #webrtc
22:30:11 <francois> i/richt: considering/Scribe: francois/
22:30:25 <ekr> Important to distnguish between new capabilities that expose more information to the server versus capabilities that expose info to the peer.
22:31:27 <francois> hta: looking at A2-4, in many scenarios, the application is the best place to know what can be cut off.
22:31:42 <francois> ... e.g. stop sending video that 's not crucial for this communication.
22:32:06 <francois> cullen: I would be very concerned if the congestion control loop was done in JavaScript.
22:32:53 <francois> hta: my thinking is that, in the case when the message is "no way to get more than 100Kb/s through", the app can react and select the streams it wants to send.
22:33:06 <francois> ... then the browser can take it from there.
22:33:47 <francois> cullen: level of control in JavaScript is: on/off, framerate, bandwidth... slippery road.
22:33:54 <francois> ... Where do we draw the line?
22:34:04 <francois> ... Implementation experience will teach us a lot here.
22:34:09 <francois> hta: I very much agree with that.
22:34:39 <francois> anant: declarative approach could work, e.g. "please turn on the stream at this bitrate"
22:35:36 <francois> burn: moving on level in audio streams requirements A2-8 and A2-9
22:36:01 <francois> cullen: security implication I think. Attacker can detect volume, and could perhaps derive words from that.
22:36:26 <francois> [moving on to A3-x requirements]
22:36:40 <ekr> cullen: depends on granularity with which it is reported
22:36:43 <francois> cullen: getting for SSRC and CNAME is good. Setting is more of an issue.
22:37:15 <francois> hta: what if you negotiate the Payload Type value and then change it afterwards?
22:37:31 <francois> ... I don't see a reason to allow an API to do something that is not useful.
22:38:16 <francois> RRSAgent, draft minutes
22:38:16 <RRSAgent> I have made the request to generate http://www.w3.org/2011/10/31-webrtc-minutes.html francois
22:38:47 <francois> burn: A3-4 is basically already possible.
22:39:01 <francois> anant: what does it mean to set the audio and video codecs of streams you receive?
22:39:14 <francois> ... At the point of rendering, it's too late.
22:40:28 <francois> hta: take all A3-4, A3-5, A3-6 together, it amounts to "the application must be able to configure a media stream across RTP sessions".
22:40:39 <francois> ... And I'd like to see a requirement like that actually.
22:40:57 <francois> s/A3-6/A3-6, A3-7, A3-8/
22:41:12 <juberti> for receive codecs, you might choose to change the PT mapping.
22:41:30 <juberti> and you'd need to tell the media layer about that.
22:42:07 <francois> [discussion on A3-10 and A3-11, same in requirements although not as low-level]
22:42:25 <hta> francois, I still don't think this is the right approach.... "I'd like to see the requirement phrased like this".
22:43:41 <ceyrigno> ceyrigno has joined #webrtc
22:44:22 <francois> anant: do we have use cases that we can map to these requirements? That would be useful.
22:44:46 <francois> burn: there were some general description that provided some context for theses. I didn't want to read it here.
22:45:05 <francois> anant: it would be easier to get it into the spec if these requirements were motivated by actual use cases.
22:45:23 <francois> ... We should get more specific about the level of extensibility we need.
22:45:33 <ekr> ekr has joined #webrtc
22:46:13 <Zakim> -Justin_Uberti
22:46:13 <francois> burn: there is a list in section 3 of this document. It explains what the problems are
22:46:48 <Zakim> +Justin_Uberti
22:47:16 <francois> anant: not convinced by argument 6) (some Web application developers may prefer to make the decision of which codecs/media-properties).
22:47:28 <francois> ... don't see why you need to involve the server at all.
22:47:49 <jun> jun has joined #webrtc
22:48:10 <francois> hta: it's clear that we don't have general agreement on how this is phrased.
22:48:39 <francois> ... let's wrap this up.
22:50:08 <juberti> juberti has joined #webrtc
22:50:55 <francois> burn: Moving on to hings API, last discussed on the mailing-list. Simple example is "audioType: 'spoken"music"
22:51:01 <francois> ... question is which level of details.
22:51:07 <francois> ... Agreement that this is needed.
22:51:17 <francois> ... Question is do we need an API for that?
22:51:30 <francois> anant: new things will keep coming. Extensibility is needed.
22:51:55 <francois> cullen: agree.
22:52:02 <howard> howard has joined #webrtc
22:52:11 <francois> ... IANA registry could be used, I think.
22:52:32 <francois> burn: problem in other groups is knowing the IETF process. Won't be a problem here.
22:53:02 <hiroki> hiroki has joined #webrtc
22:53:37 <francois> hta: we have to define some kind of namespaces for hints. Just one level, multiple levels, strings, tokenized, etc.
22:53:48 <francois> DanD: two things, structure and semantics.
22:54:39 <francois> burn: someone may want to propose finer granularity that you want to relate to other values.
22:56:01 <francois> burn: in the end, they are hints, so it doesn't matter so much. If you give something that is general, and something that is specific, you don't know what you're going to end up wiht.
22:56:07 <francois> s/wiht./with./
22:56:50 <francois> adam: side comment that the hints should be an optional argument to addStream.
22:56:53 <francois> [agreed]
22:57:45 <francois> stefan: we should reuse MediaStreamHints object for getUserMedia
22:57:57 <francois> anant: true.
22:58:22 <francois> hta: having just one registry is probably ok. The video, you could have a hint saying low resolution.
22:58:37 <francois> burn: one registry makes sense.
22:59:44 <francois> anant: different object but same values
22:59:55 <francois> burn: moving on to Statistics API.
23:00:19 <francois> ... MediaStream.getStats()
23:00:31 <francois> DanD: where do you specify the timeframe for those statistics?
23:00:47 <francois> ... maybe just "what the system knows".
23:01:13 <derf> burn: Just a nit... if your processingDelay is 20 ms, I expect your framerate is 50 fps.
23:01:14 <francois> cullen: agree. Maybe we can steal this from the XCORE group
23:01:19 <fluffy> IETF XRBLOCK WG 
23:01:28 <francois> s/XCORE/SRBLOCK/
23:01:35 <francois> s/SRBLOCK/XRBLOCK/
23:02:13 <francois> hta: the caller can always call the function twice and check difference.
23:02:47 <francois> ... just return total, and the time you think it is at the time when the function is called. Then easier to compute average.
23:03:46 <francois> DanD: important for that to be extensible.
23:03:47 <francois> cullen: there needs to be some of stats that need to be mandatory to support. Multiple layers of stats are possible.
23:04:24 <francois> ... any structure you put in there is not really useful, you have to know the property.
23:04:32 <francois> hta: structure might buys you some namespace.
23:04:50 <francois> ... Same property may be defined in different areas, so prefixing might be good.
23:05:20 <francois> burn: I'm not hearing any disagreement here.
23:05:38 <francois> hta: I note devil's in the details.
23:06:20 <francois> burn: then, moving on to Capabilities API
23:06:32 <francois> ... ROAP proposes to get an SDP blob back.
23:06:46 <francois> ... getCapabilities() would return an SDP blob.
23:07:04 <francois> ... It's using the syntax to represent capabilities
23:07:45 <francois> cullen: let's take fingerprinting off the table for a second. This seems to make sense, though it may not be the syntax you could dream about to list codecs you support.
23:07:45 <Wonsuk> Wonsuk has joined #webrtc
23:07:53 <francois> ... This seems to give you all the information.
23:08:04 <James> James has joined #webrtc
23:08:09 <francois> anant: why do you need this info in advance?
23:08:09 <Wonsuk> Present+ Wonsuk_Lee
23:08:42 <francois> ... more reliable to wait until getUserMedia. No guarantee you'll get video when the call is made.
23:08:55 <francois> DanD: I would render a different UI if I know video is not available.
23:09:00 <francois> anant: you could do that later on.
23:09:18 <francois> cullen: lots of application grey out the video when not available for instance.
23:09:27 <francois> ... use case for "video", not specific codec.
23:10:03 <francois> DanD: on a mobile device, I may present a widget on the spec if I know I have support video.
23:10:32 <francois> anant: I understand the argument. I don't like it because you need to gracefully handle the case when video is not available in any case.
23:10:43 <francois> Tim: the expectation is that it would be rare.
23:11:07 <francois> hta: you should be able to set a callback that "if capabilities change, I want to know"
23:11:29 <francois> cullen: right.
23:11:53 <francois> ... First, is video available? Then, can comeone come up with a use case for more detailed info?
23:13:27 <francois> [more discussion on fingerprinting, if you know when the camera comes in, you can correlate the user on Facebook and Google+, for instance]
23:14:40 <francois> burn: general interest in something like this, except getCapabilities early on and then callbacks.
23:14:55 <francois> anant: we can figure out later on if it's callback or event.
23:15:32 <francois> ... we're going to try what Cullen suggests: simple audio/video, then if someone comes up with a use case for more, we'll add more.
23:16:03 <francois> DanD: good, but let's not restrict. Extensibility would be good, not to change the spec afterwards.
23:16:42 <francois> burn: suggests that the browser simply lies about more specific parameters.
23:18:15 <francois> ... 3 APIs presented here. Who's gonna do this?
23:19:04 <francois> cullen: happy to work on the callback, with Anant's help.
23:19:10 <francois> burn: will work on the hints API
23:20:22 <francois> cullen: all three of them assigned to editors spec.
23:20:39 <francois> RRSAgent, draft minutes
23:20:39 <RRSAgent> I have made the request to generate http://www.w3.org/2011/10/31-webrtc-minutes.html francois
23:24:52 <ekr> ekr has joined #webrtc
23:32:06 <francois> RRSAgent, draft minutes
23:32:06 <RRSAgent> I have made the request to generate http://www.w3.org/2011/10/31-webrtc-minutes.html francois
23:32:08 <juberti> data slides again: https://docs.google.com/presentation/pub?id=10OpPqGB2hhXxMFLeqok5wrwL10oDzUK4Vq7hqy_N5pc&start=false#slide=id.p
23:32:30 <ekr> ekr has joined #webrtc
23:32:52 <francois> i/data slides again/Topic: Data streams/
23:33:18 <DavidKim> Present+ David_Yushin_Kim
23:33:35 <DavidKim> RRSAgent, draft minutes
23:33:35 <RRSAgent> I have made the request to generate http://www.w3.org/2011/10/31-webrtc-minutes.html DavidKim
23:34:45 <francois> i/richt: considering whether/Scribenick: francois/
23:34:49 <francois> RRSAgent, draft minutes
23:34:49 <RRSAgent> I have made the request to generate http://www.w3.org/2011/10/31-webrtc-minutes.html francois
23:36:08 <francois> i/cullen: when we get to ROAP/scribenick: francois/
23:36:14 <francois> scribe: DanD
23:36:18 <francois> RRSAgent, draft minutes
23:36:18 <RRSAgent> I have made the request to generate http://www.w3.org/2011/10/31-webrtc-minutes.html francois
23:37:21 <DanD> topic: DataChannel
23:38:31 <DanD> juberti: There are use cases for unreliable data
23:39:33 <DanD> juberti: Need for the datachannel for mesh apps
23:40:23 <hiroki> hiroki has joined #webrtc
23:41:19 <DanD> juberti: Encryption should be required for the data channel
23:42:07 <richt> richt has joined #webrtc
23:42:09 <DanD> juberti: Design for DataStream should be similar to MediaStream
23:42:11 <richt> richt has joined #webrtc
23:44:07 <Ruinan> Ruinan has joined #webrtc
23:45:05 <ekr> ekr has joined #webrtc
23:47:58 <ingmar> ingmar has joined #webrtc
23:48:03 <DanD> juberti: there is no need for inheritance between DataStream and MediaStream
23:50:23 <DanD> juberti: We'll use the same flow as in MediaStream to attached to the peerConnection instead of an atomic flow
23:51:05 <DanD> fluffy: I like this proposal. I think the priority needs to be addressed as people tend to set priority high.
23:51:35 <gang> gang has joined #webrtc
23:51:50 <DanD> juberti: We can keep it very high level with specific enumerations
23:52:39 <DanD> fluffy: Trying to come up with some other prioritization ideas
23:53:22 <DanD> anant: What is the use case for the readyToSend?
23:54:31 <DanD> juberti: Application should have some notion of the flow stage
23:55:13 <DanD> juberti: You need to know if you have buffer available
23:56:12 <DanD> anant: we should align this with webSockets
23:56:54 <DanD> fluffy: we need flow control for a large transfer
23:57:21 <Kangchan> Kangchan has joined #webrtc
23:57:30 <DanD> hta: the JS app has the concept of blocking
23:58:03 <DanD> anant: What if the developer wants to block?
23:58:09 <DanD> Adam: It can't
23:58:33 <DanD> anant: API looks good
23:58:49 <DanD> anant: How about security considerations?
23:59:10 <DanD> anant: how do you know who's on the other side
23:59:35 <DanD> fluffy: You would have been able to send this anyway
00:00:05 <DanD> anant: what are the different attack possibilities? Should be captured
00:01:03 <DanD> juberti: What's unique is that you can send it in peer to peer way. No server involved
00:01:37 <DanD> hta: You said data must be encrypted
00:03:42 <DanD> hta: being encrypted will take care of some concerns 
00:03:57 <stakagi> stakagi has joined #webrtc
00:04:36 <DanD> hta: it would make more sense to have a constructor of itself and then be attached to a peerConnection
00:05:13 <DanD> Milan: Question about ack
00:05:51 <DanD> juberti: The choices considered for the wire protocol make it useful
00:06:17 <DanD> Milan: Protocol has an ack and it doesn't need to be exposed
00:06:56 <DanD> Milan: an example with the ack would be useful to understand
00:07:12 <DanD> juberti: I'll take it as an action  point
00:07:33 <DanD> Stefan: we can conclude this session
00:07:57 <DanD> juberti: I'll have it updated and sent to the mailing list for review
00:08:23 <DanD> fluffy: this is just the API proposal not the actual implementation, right?
00:09:06 <DanD> fluffy: We're moving along with this until we figure out the implementation.
00:09:44 <DanD> juberti: Requirements came from the wire protocol
00:10:09 <DanD> fluffy: looks good. Can we build it?
00:10:40 <DanD> fluffy: That's what I'm concerned and maybe we should relax our requirements
00:12:10 <francois> [ref possible alignment with Websockets, perhaps change "sendMessage" to "send"]
00:13:33 <DanD> francois: there's a process called feature at risk 
00:14:30 <francois> RRSAgent, draft minutes
00:14:30 <RRSAgent> I have made the request to generate http://www.w3.org/2011/11/01-webrtc-minutes.html francois
00:16:04 <francois> Topic: MediaStream
00:17:45 <francois> -> http://www.w3.org/2011/04/webrtc/wiki/images/1/1c/MediaStream_TPAC_2011.odp MediaStream slides (odp format)
00:18:04 <francois> scribe: francois
00:18:12 <francois> [going through slides]
00:18:34 <francois> cullen: why do audio tracks precede?
00:18:54 <francois> adam: if the last track is not a video track, you can assume there's no video in there.
00:19:07 <francois> ... there used to be 2 lists.
00:19:18 <francois> anant: the order doesn't have to correspond to anything.
00:19:28 <francois> cullen: there's another ordering in SDP.
00:19:30 <francois> anant: not related.
00:19:44 <francois> cullen: wondering whether that ordering could be the same.
00:19:56 <francois> ... just strikes me as something weird.
00:20:01 <ekr> ekr has joined #webrtc
00:20:48 <francois> DanD: think we should be explicit that the order does not have to match that of SDP
00:20:53 <hiroki> hiroki has joined #webrtc
00:21:03 <francois> anant: the only people who have to worry about that is browser vendors, no need to be exposed to users.
00:21:23 <francois> stefan: I liked it better when there were two different lists.
00:21:41 <francois> adam: it was easier to query whether there is audio or video.
00:21:55 <francois> ... Moving on to definitions.
00:22:14 <kermit> kermit has joined #webrtc
00:22:21 <francois> ... MediaStream represents stream of media data. Do I need to go through it?
00:23:03 <francois> cullen: find this definition fascinating. Can you have stereo audio in two tracks? Is voice and video one track? audio and DTMF? No idea.
00:23:41 <francois> anant: a track is lowest you can go. Having 5.1 audio in one track looks weird.
00:24:12 <juberti> what about comfort noise?
00:24:18 <juberti> is that the same track as audio?
00:24:37 <francois> cullen: need some group for synchronization, but separate thing.
00:25:31 <francois> anant: getObjectURL function is on the MediaStream, right? When you assign a stream to a video element.
00:25:55 <francois> cullen: presumably, if I have a stream with 3 video streams, I want to send it to 3 different video elements.
00:26:34 <francois> anant: media fragment API could be used to select the track you're interested in.
00:26:41 <francois> s/API//
00:27:05 <Ruinan> Ruinan has joined #webrtc
00:27:10 <francois> DanD: as long as we all agree on what's inside, we're in good shape.
00:27:26 <francois> ... This is a good start for a glossary.
00:28:16 <francois> cullen: let's say that graphic card has VP8 support. You can't assume that the clone happens before the decoding happens.
00:29:26 <francois> [discussion on GStream and tracks]
00:30:12 <derf> s/GStream/gstreamer/
00:30:46 <francois> anant: I think gstreamer has two separate tracks-like for stereo audio.
00:31:04 <francois> tim: surely, a 5.1 audio is one source for gstreamer.
00:32:29 <francois> adam: the motivation to remove the parallel between MediaStreamTrack and media track is that audio was a multiple list whereas video was an exclusive track.
00:32:58 <francois> hta: basically one media streamtrack is one stream of audio.
00:33:17 <francois> cullen: stereo is two tracks, 5.1 is 6 tracks. That's very easy to deal with.
00:33:36 <francois> anant: you want to be able to disable audio tracks.
00:33:56 <francois> tim: how do I know which track is the rear right and so on?
00:34:32 <francois> DanD: technically, with 3D video, you'll want to sync those two tracks.
00:35:29 <francois> francois: 6 tracks for 5.1 audio means disabling audio is disabling 6 tracks.
00:35:38 <francois> anant: we can add a layer at MediaStream level.
00:35:40 <Kangchan> Kangchan has joined #webrtc
00:36:13 <francois> burn: the real world allows both, combined or not.
00:36:52 <francois> cullen: question is does something that is jointly coded with multiple channels, is that one track?
00:37:24 <francois> ... If that's one track with a bunch of channels, the fact that it could be represented as two tracks sounds like a complete disaster.
00:37:51 <francois> ... We need some abstraction layer to ease the life of Web developers.
00:39:30 <francois> hta: in the case of 4 microphones, you want to send 4 tracks. With 6, you want to send 6 tracks.
00:39:41 <Gang> Gang has joined #webrtc
00:39:50 <francois> anant: I think early implementations will only support one or two channels at most.
00:40:10 <francois> tim: there are plenty of places where we can get audio that is not one channel.
00:40:21 <francois> anant: right, from files, for instance.
00:42:08 <francois> anant: my preference is to stick to a MediaStreamTrack as the lowest thing.
00:42:50 <francois> adam: moving on. An instance of a MediaStreamTrack can only belong to one MediaStream.
00:43:28 <francois> anant: noting that "track" is really not the same thing as a track in music, so we need to be explicit in the doc about that, not to create additional confusion.
00:43:58 <derf> s/music/container formats, etc./
00:44:08 <francois> RRSAgent, draft minutes
00:44:08 <RRSAgent> I have made the request to generate http://www.w3.org/2011/11/01-webrtc-minutes.html francois
00:46:22 <francois> [meeting adjourned]
00:46:23 <francois> RRSAgent, draft minutes
00:46:23 <RRSAgent> I have made the request to generate http://www.w3.org/2011/11/01-webrtc-minutes.html francois
00:46:41 <Zakim> -Justin_Uberti
00:50:42 <Zakim> -Prospector_AB
00:50:43 <Zakim> UW_(WebRTC)12:00PM has ended
00:50:45 <Zakim> Attendees were Justin_Uberti, Prospector_AB
00:51:01 <hiroki> hiroki has joined #webrtc
00:56:00 <francois> Zakim, bye
00:56:00 <Zakim> Zakim has left #webrtc
01:09:30 <ekr> ekr has joined #webrtc
01:10:05 <ekr_> ekr_ has joined #webrtc
03:21:18 <lgombos> lgombos has joined #webrtc
03:26:45 <Mani> Mani has joined #webrtc
04:56:07 <ekr> ekr has joined #webrtc
05:05:19 <hta> hta has joined #webrtc
05:23:41 <JonathanJ> JonathanJ has joined #webrtc
05:29:32 <stakagi> stakagi has joined #webrtc
05:42:30 <howard> howard has joined #webrtc
05:46:34 <howard> howard has left #webrtc
05:49:42 <Gang> Gang has joined #webrtc
06:04:02 <hta> hta has joined #webrtc