IRC log of webrtc on 2012-02-01

Timestamps are in UTC.

20:36:24 [RRSAgent]
RRSAgent has joined #webrtc
20:36:24 [RRSAgent]
logging to http://www.w3.org/2012/02/01-webrtc-irc
20:36:25 [trackbot]
RRSAgent, make logs world
20:36:27 [Zakim]
Zakim has joined #webrtc
20:36:29 [trackbot]
Zakim, this will be
20:36:29 [Zakim]
I don't understand 'this will be', trackbot
20:36:32 [trackbot]
Meeting: Web Real-Time Communications Working Group Teleconference
20:36:34 [trackbot]
Date: 01 February 2012
20:38:00 [dom]
Meeting: Web Real-Time Communications Working Group F2F in Mountain View, CA, USA
20:50:51 [dom]
Agenda: http://www.w3.org/2011/04/webrtc/wiki/February_1_2012
20:50:56 [dom]
Chairs: Stefan, Harald
21:00:30 [stefanh]
stefanh has joined #webrtc
21:05:57 [richt_]
richt_ has joined #webrtc
21:06:42 [derf]
derf has joined #webrtc
21:11:08 [burn]
burn has joined #webrtc
21:11:20 [nstratford]
nstratford has joined #webrtc
21:11:29 [anant]
dom: how do I set the scribe?
21:11:36 [dom]
ScribeNick: anant
21:11:42 [dom]
s/dom:/dom,/
21:11:42 [anant]
thanks
21:11:53 [fluffy]
fluffy has joined #webrtc
21:12:42 [anant]
First topic: publish new WD
21:12:50 [JonathanLennox]
JonathanLennox has joined #webrtc
21:13:12 [anant]
stefanh: the first draft is continuously updates, are there any objections to publishing the current version of the ED as a WD?
21:13:23 [dom]
s/First //
21:13:24 [anant]
no objections noted
21:13:53 [anant]
harald: we should push a new version of the WD when we have JSEP documented in the editor's draft
21:14:01 [Ted_Hardie]
Ted_Hardie has joined #webrtc
21:14:20 [anant]
topic: Incoming Notifications by Dan Druta
21:14:36 [Ted_Hardie]
Just as a reminder for those used to WEBRTC methods, all the decisions from the RTCWEB meeting will need to be confirmed on the list.
21:14:49 [adambe]
adambe has joined #webrtc
21:15:18 [anant]
DanD: there was an informal discussion around notifications at w3c, following which I sent out a paper to the mailing list detailing the problem
21:15:33 [anant]
s/w3c/TPAC
21:16:39 [anant]
DanD: the main idea with this is to allow unsolicited notifications for incoming connection requests in WebRTC clients
21:17:03 [anant]
DanD: To make notifications available without user visible UI, and in a variety of different clients(and browsers)
21:18:14 [anant]
DanD: Presenting 2 use cases. 1) Bob uses Ringo's webrtc service on a mobile phone, calls alice and leaves a voice mail; Alice calls Bob later (and Bob, on a different webrtc-enabled client is able to receive it via a notification)
21:18:25 [anant]
2nd use on slide, missed the transcription
21:19:24 [anant]
DanD: Factors to consider while designing a notification system: multiple connection on battery constrained devices, web development effort to use them should be minimal, webapps working group has an API for server-sent events which could be extended
21:20:18 [anant]
DanD: discussing client scenarios. simplest one in which the user is available, online with the app in front (easy). second one is which the user is online and available but the app is in the background
21:21:00 [jesup|laptop]
jesup|laptop has joined #webrtc
21:21:04 [mreavy]
mreavy has joined #webrtc
21:21:21 [anant]
DanD: third one is when the user is available, but the app is closed. by available, it means the user has expressed an intent to receive incoming notificaions
21:23:09 [anant_]
anant_ has joined #webrtc
21:23:16 [jesup_]
jesup_ has joined #webrtc
21:23:19 [richt]
richt has joined #webrtc
21:23:23 [mreavy_]
mreavy_ has joined #webrtc
21:23:44 [anant_]
2nd option is to use an existing solution, not particularly preferable by members in the past
21:24:01 [derf]
derf has joined #webrtc
21:24:25 [anant]
3rd option is to define a notifications spec and define a basic structure for notifications
21:25:04 [anant]
DanD: proposal is to register a URI scheme or data format (MIME) and associate the browser as the handler
21:25:41 [anant]
DanD: Create an API to parse this notification structure and for applications to attach themselves to certain notification events
21:26:03 [anant]
DanD: proposal was also sent to the webapps WG, members are requested to read it
21:27:11 [anant]
DanD: Could we implement the API as headless browser? No, because you would need to create a new browser for every notification service and it doesn't tie it well to the PeerConnection API
21:27:59 [anant]
DanD: Can we use sendMessage so that it isn't tied to the browser
21:28:05 [anant]
opening up for questions
21:28:36 [anant]
juberti: we have an asynchronous channel via websockets, signaling is an application provide issue. what are we trying to solve here?
21:29:00 [anant]
s/provide/provider
21:29:13 [anant]
DanD: Websocket solutions assume that the browser is running, not applicable to devices where the app is not running
21:29:39 [anant]
juberti: there are already solutions to run web pages in the background, why not use that?
21:30:06 [anant]
DanD: but those assume that the app is running on the client, which may not be true, especially on mobile?
21:30:15 [anant]
juberti: it's what desktop clients do
21:30:27 [anant]
DanD: Each individual connection on mobile costs battery
21:31:08 [anant]
stefanh: you suggested that the incoming notification should be connected to the PeerConnection, should it not tie in to other parts of the API?
21:32:56 [nstratford]
nstratford has joined #webrtc
21:32:57 [anant]
Cullen: I think the most important part about this is aggregating connections, we can copy the iOS model by making one connection to each aggregation source which pushes down blobs from the app (signed) and use webintents model to then dispatch them to apps. this allows flexibility in allowing apps to register themselves for particular intents
21:33:12 [anant]
Adam: is this a webrtc problem or is this is a problem in general?
21:33:22 [anant]
Adam: Chat applications could use something like this to
21:33:25 [anant]
s/to/too
21:34:03 [anant]
Adam: this feels a bit like the JavaME push registry
21:34:29 [anant]
DanD: if we look at the two use cases there is definitely a gap regarding notification
21:35:03 [burn]
burn has joined #webrtc
21:35:14 [anant]
DanD: the keyword in the proposal is connection-less push, there are ways today to achieve this in efficient manners
21:36:22 [anant]
DanD: there still has to be a way for user A to notify user B that they are available
21:36:39 [anant]
DanD: the problem space is larger, webrtc is a subset that can benefit and is the primary beneficiary of notifications
21:37:14 [anant]
juberti: I agree with Adam that there are many other applications that can use this and agree with Cullen that we can use many of the existing solutions for this
21:38:12 [anant]
juberti: I don't understand why we are in the business of defining a notification service, when there are already ways for apps to do this using existing technology
21:39:08 [anant]
juberti: contents of the notification should be a blob, structure need not be defined
21:39:18 [anant]
DanD: defining the specific structure doesn't mean it has to be a laborious one
21:39:28 [anant]
DanD: it's the gluing piece that's most important
21:40:20 [anant]
???: I agree this is a generic problem of how to allow webapps to use a generic notification service, what is the level of standardization that we can achieve? most existing system are proprietary anyway
21:41:09 [anant]
DanD: I agree that this is a broader scope problem, but it also can be focused on particular requirements
21:41:27 [anant]
DanD: That's one of the reasons I was looking into what the specific structure we need
21:42:20 [anant]
DanD: is there a benefit of sending the offer blob, something to consider
21:42:49 [anant]
???: existing systems let you push blobs around, we don't need to specify what exactly the structure is, it could be application specific
21:43:40 [anant]
DanD: what are the elements that are neccesary, and having a consistent behavior for what happens when someone is calling me would be nice to standardize
21:44:43 [anant]
Ashish: can we handle the use-case where I want to get a notification from mom, doesn't matter what provider, some way of establishing an identity; only ring if she calls
21:45:09 [anant]
stefanh: this group's core competence is not that; DanD: to my understanding, no
21:46:07 [anant]
Adam: if you are running the webapp on your phone there has to be some level of trust
21:47:07 [anant]
ekr: It is reasonable to have a system dispatch events to an app, and you have app-level permissions
21:47:22 [anant]
juberti: do we know what the status is on bryan sullivan's proposal on sms events?
21:47:37 [anant]
DanD: it was submitted at the last TPAC, do not know what the status is
21:47:47 [anant]
juberti: it seems like that's the kind of place to work out this problem
21:48:37 [rillian]
rillian has joined #webrtc
21:48:48 [rillian]
hey, look at all the people
21:48:50 [anant]
DanD: I was trying to recommend in the paper is to use webrtc use cases to accelerate that work, and if there are any specific elements of that spec to be captured (if need be)
21:49:10 [anant]
DanD: let's piggy back on that proposal, do we need to do anything specific? and support that work in webapps WG
21:49:34 [anant]
harald: conclusion from the chairs: there is generic work that needs to be done which is done elsewhere in the w3c, and we need to link there when it is done
21:50:14 [anant]
cullen: that work is about sms, harald: no sms is just one channel
21:50:25 [anant]
cullen: is the aggregation part being done elsewhere in the w3c?
21:50:38 [anant]
harald: we will continue to monitor and figure stuff out
21:51:21 [anant]
topic: JSEP
21:51:44 [anant]
harald: we had a pretty clear decision at the IETF that the next version of the API draft be based on JSEP
21:52:14 [anant]
ted: decisions at the IETF required confirmation on the mailing list
21:53:01 [anant]
harald: we also need confirmation at w3c whether we accept IETF's recommendation or not
21:53:34 [anant]
cullen: if we are moving away from 3264, myself and matthew kaufman have an alternative proposal that we would like to bring up
21:53:55 [anant]
adam: do we have a recommendation for API? or is it a protocol?
21:54:33 [anant]
harald: speaking as myself, we should sit down tomorrow and modify the spec, and experiment to see if it works
21:54:55 [anant]
adam: is it necessary to put it in the spec to see if it works out?
21:55:30 [anant]
juberti: things don't get implemented in chrome unless they are in a written spec that we can point at. we would like to see if jsep works, working build of chrome by Paris
21:56:16 [anant]
harald: roap could be implemented without changes to webkit API, jsep is not like that
21:57:14 [Mauro]
Mauro has joined #webrtc
21:57:15 [anant]
derf: one of the things that the current API lacks (that roap brought clarity to) is the state machine from 3264, helps browser implementers figure out. JSEP as currently specced lacks a lot of those things, and I would like to see that fleshing out done before it is added to the draft
21:57:28 [anant]
juberti: I would also like that fleshing out!
21:57:47 [anant]
juberti: that will occur between now & paris but it doesn't need to block inclusion in spec
21:58:08 [anant]
juberti: given the benefit of getting implementation experience, still worth doing
21:58:56 [anant]
cullen: did not suggest that jsep not be iterated on and experimented in code, but we also have alternative proposals which need to be considered
21:59:55 [anant]
stefanh: for larger changes to spec we need a consensus, I would like to see jsep fleshed out before inclusion
22:00:44 [burn]
anant: does spec need to be in w3c for it to be in chrome?
22:01:08 [stefanh]
anant: is there a req that the spec in w3c space or not (for the webkit people)
22:01:28 [stefanh]
justin: don't know really
22:02:07 [anant]
juberti: what do we gain by that instead of just reving the ED?
22:02:50 [anant]
dom: I don't have a strong opinion on this, but there is a fair amount of work to put it in the editor's draft
22:04:11 [anant]
juberti: we've already thrown away a lot of implementation in chrome already, additional proposal become available; but we should try what we have now and was recommended yesterday and move forward
22:04:26 [anant]
dom: you're right but we don't have consensus on what the API looks like
22:05:17 [anant]
dom: editor's draft must also look like what the group has consented to
22:05:42 [anant]
cullen: I do not get why having this text in the ED is important, other than just having a document for implementors to look at
22:06:18 [anant]
cullen: it's very difficult to evaluate if the spec is incomplete, what happens when setLocalDescription is called?
22:06:47 [anant]
harald: how much time do you need for the alternative proposals?
22:07:17 [anant]
cullen: lesser time than what it took for JSEP to form since the last interim (-3 weeks for Christmas!)
22:07:45 [anant]
cullen: we shouldn't rule out a whole class of proposals based on that
22:08:15 [anant]
cullen: it will be healthy to explore the range of possibilities
22:09:06 [anant]
harald: im looking for a drop-date by which if we have no alternative proposals that we go forward with implementing JSEP
22:10:02 [anant]
harald; we don't want to be in a situation like in december where we couldn't do anything while waiting for a proposal
22:11:19 [anant]
tim: my fear (for putting the API in the spec) is that it's easy to put the API calls themselves but specifying the behavior is hard and will end up being whatever chrome implements
22:14:17 [burn]
anant: need to have implementation first to demonstrate that it works. We need multiple implementations before we put into the draft.
22:14:34 [burn]
anant: when we put it in a document it does not have to be the ED
22:15:45 [anant]
juberti: the original version of the spec was something that didn't work, and that's why we had to make ROAP
22:17:25 [anant]
cullen: matter of taste, how big things are before moving to the draft. there are exceptions to the spec but the history of the spec is that it was from the WhatWG
22:18:15 [anant]
ted: one of the things i've heard in terms of this spec is that we want to get implementation experience, it would be nice to show what particular use cases an implementation tackles
22:19:24 [anant]
???: comment on JSEP/ROAP - IETF/W3C. I think they are an evolution for SDP and I think the IETF should define how the data flows but the W3C is defining the API there is overlap which is causing this debate
22:19:41 [anant]
harald: a lot of the back and forth is exactly that process, I don't see any clear answer
22:20:52 [anant]
???2: we have made decision yesterday to move away from 3264, but isn't JSEP just an extension to offer/answer? independent of whether it's O/A there's a question of whether it's actually SDP that we used to define the paramters
22:21:19 [Ted_Hardie]
Speaker is Christer
22:21:55 [burn]
s/???2:/Christer:/
22:22:36 [burn]
s/???:/Mathieu:/
22:24:25 [anant]
harald: trying to get to some degree of conclusion. clearly we have some amount of work to do on the current jsep spec, we have to find a timeline for other proposals and criteria by which we judge whether they are better/worse than JSEP
22:24:38 [anant]
harald: take it to the list! we'll get implementations and try it out somehow
22:26:37 [anant]
looking at code samples for jsep
22:31:35 [dom]
-> http://lists.w3.org/Archives/Public/public-webrtc/2012Jan/0093.html Code samples for JSEP/ROAP
22:36:48 [Zakim]
Zakim has left #webrtc
22:38:25 [jesup]
If later on we a chance to discuss congestion interaction apis, this is the document to use: http://lists.w3.org/Archives/Public/public-webrtc/2012Feb/0000.html
22:48:45 [stefanh]
discussion on getUserMedia vs. HW reservation of camera
22:49:39 [stefanh]
what happens if several tabs have right to use camera, and suddenly many wants to use it
22:52:10 [dom]
-> http://dev.w3.org/2009/dap/api-perms/ Permissions for Device API Access Editors draft
22:52:45 [dom]
sorry, I meant:
22:52:54 [dom]
-> http://dev.w3.org/2009/dap/perms/FeaturePermissions.html Feature Permissions "This document defines APIs for web pages to request permission to use privileged user agent features. "
23:11:27 [Mauro]
Mauro has joined #webrtc
23:14:48 [dom]
RRSAgent, draft minutes
23:14:48 [RRSAgent]
I have made the request to generate http://www.w3.org/2012/02/01-webrtc-minutes.html dom
23:25:42 [adambe]
scribing
23:25:57 [adambe]
eric: to late for me to change my mind about scribing
23:26:02 [dom]
ScribeNick: adambe
23:26:29 [adambe]
eric: hope you remember what happend before lunch
23:27:04 [stefanh]
stefanh has joined #webrtc
23:27:35 [adambe]
eric: There may be times where a page want permanent, long term or short term access to input devices.
23:27:51 [adambe]
eric: We need an API to solve this.
23:29:26 [adambe]
eric: We need to be able to start setting up the call without revealing your IP address
23:29:52 [adambe]
eric: The server has your IP address
23:31:23 [adambe]
eric: I want to gather without staring ICE
23:31:50 [adambe]
oscar: The web server doesn't know your private address
23:33:56 [adambe]
eric: No ietf hum about identity
23:34:23 [Mauro]
Mauro has joined #webrtc
23:34:46 [adambe]
eric: Want to make a plea for a structured PeerConnection configuration parameter
23:35:03 [adambe]
eric: That's all
23:36:07 [dom]
-> http://www.w3.org/2011/04/webrtc/wiki/File:Rtcweb-security-w3c.pdf Eric's slides on WebRTC Security
23:36:31 [dom]
-> http://www.w3.org/2011/04/webrtc/wiki/File:MediaStream_Security_1.pdf Randell Jesup's slides on MediaStream Security
23:36:50 [adambe]
jesup: We talked in the ietf about the bits on the wire
23:37:10 [adambe]
jesup: Who can access MediaStreams
23:37:20 [adambe]
jesup: We don't trust JS
23:38:12 [dom]
-> http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0464.html A very recent thread on trusted "installable" apps on public-webeapps
23:38:19 [adambe]
jesup: It doesn't help to secure the transport if the app can access your media and send it off to another location
23:39:37 [adambe]
jesup: MediaStream processing proposal will be affected by the ability to access local streams
23:39:52 [adambe]
jesup: Using Poker Stars as an example
23:40:27 [adambe]
jesup: Two players may want to have a private conversation
23:42:07 [adambe]
jesup: Media security adds value even if source of app is untrusten (e.g. distributen via USB stick)
23:43:01 [dom]
-> http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0466.html Jonas Sicking on installable Web apps and trust
23:43:01 [adambe]
jesup: Untrusten apps will be blocked from processing data from local media streams
23:43:41 [adambe]
jesup: Cross-origin can be used to limit the problem
23:44:18 [adambe]
jesup: Sandbox access to media streams
23:45:07 [adambe]
jesup: What level of MediaStream security is needed?
23:45:18 [adambe]
jesup: How to handle trusten vs. untrusted apps?
23:45:36 [adambe]
jesup: How does this key into the encryption model?
23:46:05 [adambe]
jesup: How much security are we loosing by letting the application access the keys
23:46:43 [adambe]
jesup: How does MediaStream security affect local processing
23:46:44 [dom]
[I think with SDES, we probably have lost security against attacker, but I would still protect the MediaStream to avoid blunder from careless developers]
23:46:50 [stefanh]
stefanh has joined #webrtc
23:49:44 [adambe]
cullen: I would prefer if an app had to request access to process local media
23:51:54 [adambe]
cullen: A common application is desktop/application sharing
23:52:54 [adambe]
cullen: Such an application could be restricted from accessing the data in a stream
23:53:06 [adambe]
harald: rhm.mmm..
23:53:32 [adambe]
harald: We can't ask the users permission every time (it stinks)
23:55:10 [adambe]
harald: My impression is that it's not impossible to come up with an API that lets an app say that I'm not going to read the data from local streams
23:56:11 [adambe]
harald: There are limits on how energy we should spend on locks for paper doors.
23:59:25 [adambe]
oscar: What would be possible with a secure iframe in a unsecure page?
23:59:43 [adambe]
oscar: (the iframe handling MediaStreams)