IRC log of webrtc on 2015-09-09

Timestamps are in UTC.

15:50:18 [RRSAgent]
RRSAgent has joined #webrtc
15:50:18 [RRSAgent]
logging to http://www.w3.org/2015/09/09-webrtc-irc
15:50:24 [Zakim]
Zakim has joined #webrtc
15:50:34 [dom]
agenda:http://www.w3.org/2011/04/webrtc/wiki/September_9_-_10_2015
15:50:36 [dom]
Meeting: WebRTC Working Group F2F
15:50:39 [vivien]
RRSAgent, make logs public
15:50:43 [dom]
chairs: hta, stefanH, erikL
15:50:52 [vivien]
RRSAgent, draft minutes
15:50:52 [RRSAgent]
I have made the request to generate http://www.w3.org/2015/09/09-webrtc-minutes.html vivien
15:55:55 [jib]
jib has joined #webrtc
15:57:15 [mreavy]
mreavy has joined #webrtc
15:57:15 [jesup]
jesup has joined #webrtc
15:57:55 [jib]
jib has joined #webrtc
15:58:44 [mreavy|mac]
mreavy|mac has joined #webrtc
16:00:28 [jesup]
I can hear the room now
16:00:34 [sherwinsim]
Me too
16:03:51 [adamR]
adamR has joined #webrtc
16:04:01 [dom_]
dom_ has joined #webrtc
16:04:16 [mreavy|mac]
mreavy|mac has joined #webrtc
16:04:28 [hta]
hta has joined #webrtc
16:04:30 [jib]
I hear the room
16:04:34 [jesup]
yup
16:05:16 [stefanh]
stefanh has joined #webrtc
16:05:37 [daviddias]
I can hear as well, almost no signal noise at all
16:06:12 [jesup]
sounds good now (the remote person); they were weak before
16:06:24 [victor_pascual]
yup
16:06:27 [sherwinsim]
yeah they are adjusting their end
16:07:51 [jib]
we have video
16:07:53 [AndyH]
AndyH has joined #webrtc
16:07:55 [jesup]
Now can see video of the chairs
16:07:56 [sherwinsim]
yay
16:08:26 [dom_]
Topic: Welcome
16:08:32 [dom_]
hta: welcome
16:09:15 [dom_]
... this is an interim meeting of the webrtc wg with bits from media capture task force
16:11:01 [dom_]
Present: harald, stefan, erikL, vivien, dom, danBurnett, AlanJ, MathieuH, Alexandre, DanD, PeterT, @@@Citrix, Keith, Cullen, Justin, EKR, AdamR, BernardA, ShinJun
16:11:46 [daviddias]
I'm losing the signal from the room
16:11:54 [sherwinsim]
I'm still good
16:12:08 [dom_]
On the phone: Jesus, Sherwin_temasys, Maire, AdamB, AndyH, DavidDias, JanIvar
16:13:05 [dom_]
hta: we're here to make decisions; a decision at the meeting gets announced to the list with a delay before they're final
16:13:15 [victor_pascual]
Victor Pascual also on the phone -- sorry was muted
16:13:50 [DrAlex]
DrAlex has joined #webrtc
16:13:51 [ShijunS]
ShijunS has joined #webrtc
16:14:04 [dom_]
scribenick: DrAlex
16:14:05 [burn]
burn has joined #webrtc
16:14:07 [DanD]
DanD has joined #webrtc
16:14:18 [DrAlex]
going through the agenda
16:14:20 [dom_]
Topic: status of documents
16:14:51 [DrAlex]
next point is "view of status document"
16:15:58 [fluffy]
fluffy has joined #webrtc
16:16:32 [DrAlex]
getusermedia is still in LC
16:16:40 [KG]
KG has joined #webrtc
16:16:45 [DrAlex]
a few comments are still being addressed, but it s mainly stable and shipped.
16:16:52 [DrAlex]
webrtc 1.0 is still not done.
16:17:10 [DrAlex]
there will be more sessions those two days about points still in fly.
16:18:07 [DrAlex]
we have also new things
16:18:10 [DrAlex]
media recorder
16:18:13 [DrAlex]
in need of an editor
16:18:26 [DrAlex]
screen capture: we have a spec but maybe some lack of interest
16:18:48 [DrAlex]
the other specs (audio output, image capture) are in an unknown spec.
16:19:06 [dom_]
justin: audio ouput control has initial implementation in chrome
16:19:22 [DrAlex]
audio output crontol implemented in chrome
16:19:24 [DrAlex]
but nt final
16:19:28 [DrAlex]
waiting for feedback
16:19:30 [dom_]
... doc is mostly complete in terms of impl feedback
16:19:36 [DrAlex]
chrome 46
16:19:39 [DrAlex]
behind a flag
16:19:51 [DrAlex]
implementation feedback will be pushed to the spec
16:19:54 [DrAlex]
then we could move to LC
16:20:03 [DrAlex]
on screencapture
16:20:08 [DrAlex]
the spec is out there
16:20:17 [DrAlex]
bunch of pen issues that needs to be updated
16:20:27 [DrAlex]
there is no implementation in Browser yet (AFAIK)
16:20:43 [DrAlex]
so we need to probe interest from browser vendors
16:20:43 [vivien]
s/on screencapture/Keith: on screencapture/
16:20:56 [DrAlex]
it seems that what is in the browser and what is in spec is different
16:21:06 [DrAlex]
and we just need to double check
16:21:13 [DrAlex]
things like app share vs window share
16:21:20 [DrAlex]
mozilla is in favor of having it
16:21:25 [DrAlex]
it s just a matter of process
16:21:40 [mathieu]
mathieu has joined #webrtc
16:21:47 [DrAlex]
ekr we need to either
16:21:55 [DrAlex]
find more people to come in and help
16:21:59 [DrAlex]
or focus on 1.0 first
16:22:10 [DrAlex]
because of constrained ressources
16:22:49 [DrAlex]
mozilla implements screen capture but an older spec
16:23:03 [DrAlex]
what about implementation from canvas?
16:23:10 [DrAlex]
video element -> MS
16:23:21 [DrAlex]
should be implemented in 33, behind a pref
16:23:41 [DrAlex]
what about depth channel ?
16:23:58 [DrAlex]
dom: there are still a few changes to be made on the specs.
16:24:17 [DrAlex]
dom: this document is a good candidate to be transferred to the new timed media group
16:24:23 [vivien]
s/what about/Harald: what about/
16:24:28 [DrAlex]
what about media capture in workers
16:24:49 [DrAlex]
dom: corresponding work has just started, really.
16:25:24 [DrAlex]
stefan: note on the media output document, the web audio group mentionned they will have some comments to contribute
16:25:36 [DrAlex]
dom: I think the stats are missing from the list
16:25:50 [DrAlex]
harvald: i ll update the document list, but I think it s on track
16:26:03 [DrAlex]
harvald: let s go in the "non document" part
16:26:17 [DrAlex]
harvald: about timed data tracks
16:26:35 [DrAlex]
there was an objection at Last Call because we would not support subtitles e.g.
16:26:50 [DrAlex]
stefan: yes, we decided to to address that in the current spec
16:27:04 [DrAlex]
as the spec can be updated / extended anyway
16:27:15 [DrAlex]
justin: what about if we want to use DataChannel instead?
16:27:29 [DrAlex]
dan: I was in that call actually
16:27:41 [hta]
From chair: if remote people can't hear what's said, please complain here.
16:27:49 [DrAlex]
dan: that information (subtitle) is considered part of data
16:27:58 [DrAlex]
dan:as in part of the audio/video
16:28:30 [DrAlex]
dan: we were able to explain the use case that is driving our specs today, and that there was no intention to restrict the specs to that
16:28:47 [DrAlex]
dan: eventually we will explain how to extend the specs
16:29:02 [DrAlex]
justin: how does it work with <video HTML DOM element today?
16:29:13 [DrAlex]
dan: that was interesting, he said that would work out of the box today
16:29:26 [DrAlex]
dom: yes, there is a track element and a separate spec for that
16:29:57 [DrAlex]
harvald: last piece of undocumented wanted feature: use of data channel in web workers
16:30:07 [vivien]
s/harvald/harald/g
16:30:19 [DrAlex]
randell jesup: i m writing the documents. In progress. The interest is real, from gaming industry and more.
16:30:46 [DrAlex]
harvald: ok, this is what i can remember, is there anything else that i forgot that should deb in the list?
16:30:49 [DrAlex]
<silence>
16:30:56 [DrAlex]
harvald: ok, summary is now complete.
16:31:30 [DrAlex]
harvald: ok, now we need to sort the list, and decide which items we want in webrtc 1.0
16:32:11 [DrAlex]
harvald: logistics we should work on this until lunch.
16:32:44 [DrAlex]
toward the end of the day, we have reserved a slot for Media Capture API
16:33:02 [DrAlex]
tomorrow, we might want to exchange about next version
16:33:06 [DrAlex]
not really decide anything
16:33:14 [mreavy]
just to support what jesup said (re: data channels in workers): these is LOTS of interest in data channels in workers. I'm being asked to get it on the Firefox roadmap.
16:33:21 [DrAlex]
just exchange, make a plan to make a plan for TPAC
16:33:40 [DrAlex]
give the chairs some feedback to work with
16:33:55 [DrAlex]
we might also have some other TPAC related items to discuss.
16:34:01 [DrAlex]
that s for tomorrow.
16:34:18 [DrAlex]
Does anyone want to propose a change to the agenda?
16:34:39 [DrAlex]
justin: ne thing we talked about i don t see here: generic error feedback?
16:34:49 [DrAlex]
harvald and peter: tomorrow morning has a slot for that.
16:35:22 [DrAlex]
alright, let s start then
16:35:35 [dom_]
topic: RTPSender and RTPReceiver
16:35:36 [DrAlex]
peter, you want to speak about RTPSender/Receiver?
16:35:47 [adambe]
adambe has joined #webrtc
16:36:53 [Erik]
Erik has joined #webrtc
16:37:21 [Bernard]
Bernard has joined #webrtc
16:38:36 [DrAlex]
ok, there are a lot of objects
16:38:39 [DrAlex]
so i m going to start
16:38:43 [DrAlex]
by those already in chrome
16:38:49 [DrAlex]
then some that have consensus but are not there
16:38:55 [DrAlex]
and finish by the hard ones
16:39:02 [vivien]
@@link-to-peter-slides
16:39:03 [DrAlex]
DtlsTransport is DONE
16:39:39 [DrAlex]
RTPSender/Receivers parameters are also DONE
16:40:44 [DrAlex]
pending ones now
16:40:54 [DrAlex]
RTPSender/Receivers capabilities
16:42:17 [DrAlex]
cullen: that might be too little.
16:42:32 [DrAlex]
peter / justin: you can always add things in the dictionnary
16:42:58 [DrAlex]
cullen: I want to do this but, I am not convinced that this is needed for any of the use case we have today
16:43:09 [DrAlex]
cullen: should it make it into 1.0
16:43:37 [DrAlex]
peter and others: this is needed for codec selection, which many user do by modifying the SDp today
16:44:25 [jesup]
can't hear that last comment about selection
16:44:30 [DrAlex]
alex: yes, needed
16:44:55 [DrAlex]
to jesup from alex: yes, i said the codec selection is a real use case today and require that kind of change.
16:45:09 [DrAlex]
pending: SctpTransport (PR270)
16:46:37 [hta]
https://www.w3.org/2011/04/webrtc/wiki/images/1/14/WebRTC_1.0_objects_at_2015_f2f_%282%29.pdf
16:47:16 [DrAlex]
do we merge PR 270 ?
16:47:24 [DrAlex]
, no opposition, considered OK
16:47:41 [DrAlex]
need discussion: IceTransport more (readonly) infos
16:47:46 [DrAlex]
- role
16:47:50 [DrAlex]
- component
16:47:54 [DrAlex]
- state
16:48:00 [DrAlex]
- ...
16:48:21 [DrAlex]
all of this would be per Ice candidate and not an aggregate at the peer connection level
16:48:47 [DrAlex]
ekr: i m concerned
16:49:01 [DrAlex]
ekr: that there are a lot of new stuff coming in
16:49:10 [DrAlex]
ekr: how to draw the line, conceptually?
16:49:21 [dom_]
Present+ Varun
16:49:34 [DrAlex]
harald: stats have to be able to do counting on identifiable objects
16:50:07 [DrAlex]
ekr: what is the line between what goes in stats and what goes in there?
16:50:27 [DrAlex]
ekr: or one should reuse the other and not be a complete parallel / duplicate info
16:50:43 [jeff]
jeff has joined #webrtc
16:51:14 [DrAlex]
harald: when we started with statistics, this things did not exist
16:51:30 [DrAlex]
harald: and stats might have been trying to stretch out to do things for which this new API is better.
16:52:37 [DrAlex]
cullen: this API might be more suitable for one time pull, while stats might be used for recurrent pools.
16:53:12 [DrAlex]
ekr: we see so many people today with flaky connections that want to access this level of information when things don t work
16:53:58 [DrAlex]
bernard: yes, it s duplicated in the implementation, but in any case, it s needed by the apps. And by the way, we need more stats in getstats(), like *real* statistics, that are not there today.
16:54:38 [DrAlex]
justin: we could decide to have counters and stats (dynamic objects) in getstats() and access static values from this API
16:54:57 [DrAlex]
bernard: an example of one thing we might need: ice consent stats. it s dynamic
16:55:11 [DrAlex]
justin: RTT? would that be stats or here
16:55:28 [DrAlex]
bernard: stats.
16:55:41 [dom_]
Present+ TedHardie
16:57:10 [DrAlex]
callstats.io guy: many examples, and discussion with justin to separate between different kinds of values
16:58:13 [DrAlex]
dynamic objects (byte ssent, RTT, ice consent, ...) should be in getstats(), other which are more discrete could be coupled with an event and/or be used through the capacity/parameters
16:58:23 [DrAlex]
cullen: we need more to debug ICE, if only.
16:58:53 [DrAlex]
s/callstats.io guy/varun/g
16:59:14 [DrAlex]
need more discussion: RtpSender more info (PR273)
17:00:16 [dom_]
Present+ martinT
17:00:22 [adambe]
adambe has joined #webrtc
17:00:35 [DrAlex]
cullen: could we have one FEC for several SSRC ?
17:01:00 [DrAlex]
justin: i don't think we will have such a use case.
17:02:20 [DrAlex]
harald: comment: the last 3 lines (rtx/fec/rtcp) are not yet decided features for 1.0. We might want to hold on to it before we put it in, at least until we decide to put it in the main specs?
17:02:49 [DrAlex]
justin: I would disagree. We might not have control over it, but we still want to surface the info, if it happens. Today one has to parse the sdp.
17:03:23 [DrAlex]
justin: wether we will use FEC or not we will do it will be discussed later, but it s happening, and we should surface the info.
17:03:27 [tedh]
tedh has joined #webrtc
17:03:42 [DrAlex]
typoe correction: that was about RTCP and not RTP
17:03:57 [vivien]
https://github.com/w3c/webrtc-pc/pull/273
17:04:37 [DrAlex]
apart from typos and style, is everyone ok with that?
17:05:38 [DrAlex]
ok, next slide
17:05:41 [DrAlex]
"codec slection"
17:05:46 [DrAlex]
selection
17:09:46 [DrAlex]
this mechanism is supposed to be used AFTER an offer / answer, when all the usable codecs for the call are known.
17:12:23 [DrAlex]
concerns about the cases where this could blow in the face of the user
17:12:37 [DrAlex]
like, if the JS can pin down on given codec
17:12:41 [DrAlex]
for a given call
17:12:55 [DrAlex]
then for the next call, or during a renegotiation
17:13:09 [DrAlex]
it could be stuck with a codec the remote peer does not support anymore
17:13:24 [DrAlex]
shall we send an error/event?
17:13:47 [DrAlex]
shall we fall back to the normal mechanism (and ignore the JS setting)
17:13:49 [DrAlex]
?
17:14:33 [DrAlex]
peter: requiring the JS to reset everytime there is a renegotiationneeded event
17:14:42 [DrAlex]
would really be too heavy on JS
17:15:09 [DrAlex]
harald: the amount of discussion we re having right now seems to indicate that more thinking is needed.
17:16:43 [DrAlex]
peter: questions in my mind: when does the JS app needs to interact with this API? Does it have to remember the values? Is it a hard constraint, or a preference? ay you prefer OPUS, but opus is not proposed.
17:17:43 [DrAlex]
cullen: we had agreement some time ago: have a priority associated with each codec.
17:17:59 [DrAlex]
peter: we have consensus that we wants to have codec selection. The how is still unclear.
17:18:23 [DrAlex]
harald: I think we agree that we are speaking about two different things :)
17:18:34 [DrAlex]
1. how to influence the codec selection
17:18:46 [DrAlex]
2. which codec do we use right now, after O/A
17:19:07 [DrAlex]
peter: one missing semantic is "how do you restore the browsers proposed semantics"
17:19:33 [DrAlex]
ekr: use case: you negotiate opus, then opus is gone after a renegotitation. what happen?
17:20:12 [DrAlex]
justin: you could call again and say "browser you choose", or you could decide to manually choose again (binded to an error event)
17:22:02 [jesup]
talking is off-mic (justin...)
17:22:14 [DrAlex]
cullen: did you considered an API where instead of setting a coder, you would be settings parameters of the payload type (as you could have same payload for different params)
17:22:27 [DrAlex]
cullen: could you use something different than payload type for selector
17:23:53 [DrAlex]
discussion around the corresponding use case.
17:25:05 [mreavy_]
mreavy_ has joined #webrtc
17:25:15 [DrAlex]
clarifying questions: if you have two lines with, basically, the same mime type, would you able to differentiate using setParam. so you wouldn t have to add param in the selector.
17:25:28 [DrAlex]
cullen: possibly ............
17:26:00 [tedh]
Cullen: Another way to ask the question is whether there is anything missing from the .setParameters(params) that would occur in the m-line.
17:27:09 [DrAlex]
cullen: we need to hold on to it until we can support H.264 and vp8 (and possibly vp9)
17:27:23 [DrAlex]
peter/ekr: what is missing today ?
17:27:34 [DrAlex]
cullen: profile id, resolution
17:28:06 [DrAlex]
peter/ekr: based on their location in the SDP, you could have them using the current API
17:29:28 [DrAlex]
cullen: I want to avoid sdp munging. I want to have all in he API for anything we do today.
17:31:27 [DrAlex]
bernard: can we go back to harald question: are we trying to achieve codec preference setting, or codec selection ?
17:32:01 [DrAlex]
ekr: codec selection.
17:33:52 [DrAlex]
harald: post negotiation selection
17:34:36 [DrAlex]
cullen: we heard from users that they want both. they also want pre-negotiation selection (a.k.a. codec preference).
17:35:32 [DrAlex]
Haradl: i think this approach is good for post-negotiation selection, and we need something different for pre-selection selection.
17:37:25 [DrAlex]
alex: in the post selection case, you have all info needed to make a final decision
17:38:00 [DrAlex]
mathieu: well, i m a grown up, if i want to select before i know what the remote peer capacity is, so be it, and if it does work, my choice.
17:38:13 [DrAlex]
cullen: use case.
17:39:05 [DrAlex]
randell: i agree with cullen, i want to had a use case, when a 3rd user join a call that has already a codec nailed down. Moreover, there is more demand for pre-negotiation selection.
17:39:28 [DrAlex]
peter: even if we go for pre-negotiation selection separately, shall we merge this ?
17:40:24 [DrAlex]
dom: what happen in case of renegotiation? I would prefer that every time parameters are erased, as it is closer to what happen today, where the user would re-munge the SDp everytime
17:41:07 [DrAlex]
peter: can someone put a note on the PR with the two notes? And if i address it, can i go ahead with the merge?
17:41:13 [DrAlex]
cullen: who reviewed it?
17:42:28 [DrAlex]
martin: I did
17:45:02 [DrAlex]
peter: i m happy to make the codec list re-orderable
17:45:17 [DrAlex]
so people can shuffle the codec list
17:45:53 [DrAlex]
martin: that would work the for pre-selection as well.
17:46:22 [DrAlex]
martin: i m writing up something righ tnow, but .....
17:46:30 [DrAlex]
stefan: martin do you want to volunteer?
17:47:00 [DrAlex]
harald: shall we schedule some time tomorrow to look at what you will have surely written by then
17:47:01 [DrAlex]
?
17:47:17 [DrAlex]
martin: well, ... hum, .... there is a meeting happening ......
17:47:49 [DrAlex]
matrin: I would need the post-negotiation part to be in before i can work on it
17:48:15 [DrAlex]
harald: ok, peter and martin to work an that, and if we have something by tomorrow morning, we can add a line in the agenda during the agenda bashing.
17:48:19 [DrAlex]
<break 10mn>
17:55:06 [jeff_]
jeff_ has joined #webrtc
18:04:11 [tedh]
tedh has joined #webrtc
18:04:28 [tedh]
</break 10mn>
18:08:15 [DrAlex]
needs discussion: RtpSender more parameters (for simulcast and svc)
18:08:29 [DrAlex]
peter: there will be a full discussion tomorrow on simulcast, so we could save that for then.
18:09:49 [DrAlex]
justin: in this micro-change, you propose a mechanism to automate the scaling down of resolutions (spatial and temporal)
18:10:11 [DrAlex]
justin: and combined with what you will proposed later, one might then handle simulcast?
18:10:13 [DrAlex]
peter: yes
18:10:28 [DrAlex]
ekr: question: how do those priority interact? they don t seem orthogonal.
18:11:35 [DrAlex]
cullen: just a detail maybe
18:12:21 [DrAlex]
cullen: i would rather have the scales to be an array. For example if you have thumbnail, it might be very small, and not a power of two
18:12:26 [DrAlex]
peter: it can be any integer
18:12:31 [DrAlex]
cullen: oh, ok, fair enough
18:13:00 [DrAlex]
cullen: shall it be a flag to decide if it should prefer temporal or spatial scaling?
18:13:18 [DrAlex]
peter: what should the default be?
18:13:43 [DrAlex]
cullen: well, for talking head, spatial, but for screensharing, the opposite ....
18:13:51 [DrAlex]
justin: this is fine tuning, we can deal with it later.
18:13:53 [DrAlex]
cullen. ok
18:14:30 [DrAlex]
randell: i can see three cases: spatial, temporal, browser decides.
18:15:33 [DrAlex]
ekr/randell: we should use a multiplicative factor instead.
18:16:05 [jesup]
Otherwise, change name to "resolutionDivideBy" etc
18:16:30 [DrAlex]
varun: and bias is what i want?
18:16:40 [DrAlex]
justin: yes, it s what you want to prioritize.
18:18:28 [DrAlex]
bernars: the reason why we choose an integer scale, it s because i want to use one pixel out of n. It gives less artefact this way.
18:18:55 [DrAlex]
can we still do 0.5 (e.g.)
18:19:57 [DrAlex]
randell: in the PR, i left it at "DivideBy", mentionned it should be more than 1, and specified we should round down.
18:20:34 [DrAlex]
justin: should we really refrain from upscaling (i.e. having a value less than 1, for temporal resolution)
18:21:03 [DrAlex]
justin: use case: people might want 720p even though the content itself is not 720p.
18:21:15 [DrAlex]
randell: if there is a written use case for that, I can live with that.
18:23:18 [DrAlex]
justin: say we set a parameter that tells the brother to scale down when bandwidth goes down. How do I know what is the resolution eventually used?
18:24:05 [DrAlex]
peter: that s a good point, in the simulcast case, what happen is not specified.
18:24:44 [DrAlex]
justin: exactly, in case of simulcast / svc, one might want to drop the higher resolution, instead of having each stream adapt.
18:25:18 [DrAlex]
randeill: we could have the spatial resolution scale adapt immediately, while the frame rate would used later
18:25:52 [DrAlex]
justin: that s sensible, but in the use case of simulcast / svc there are other problems. We might want to postpone this discussion until tomorrow during the corresponding session.
18:28:03 [DrAlex]
martin: cloen => constraint
18:28:05 [DrAlex]
clone
18:28:46 [DrAlex]
justin: what martin said: make sure that the input stream has the right resolution.
18:29:12 [DrAlex]
martin: moreover, these parameters do not make sense in the case of simulcast, and otherwise, it s good as it is.
18:29:23 [DrAlex]
cullen: yeah <bla bl abla> it s fine.
18:29:40 [DrAlex]
varun: and IETF is expecting some info, so that could be it.
18:29:57 [DrAlex]
needs discussion: PC.connectionState (PR 291)
18:30:19 [DrAlex]
use case: discrepancies between DTLS and ICE states
18:31:25 [DrAlex]
justin: we should be gentle with existing applications.
18:32:04 [DrAlex]
justin: iceconnectionstate (in chrome) is already that.
18:32:20 [DrAlex]
peter: well, there are some differences: checking / connecting
18:32:37 [DrAlex]
justin: well, that's where i m getting concerned.
18:33:35 [DrAlex]
martin: i think we should keep ice connection state, and make this a new API.
18:34:09 [DrAlex]
varun: what problem are we solving?
18:34:27 [DrAlex]
peter: today, if DTLS failed, ICE state is still connected, and the application doe snot know.
18:35:20 [ShijunS]
ShijunS has joined #webrtc
18:35:27 [DrAlex]
peter: so the new enum is closer to what the application expect, if anything (wether ice or dtls) failed, then the status is failed.
18:36:50 [DrAlex]
justin: what i would like is for us to come up with a drop in equivalent (not to break existing code) but which would aggregate dtls and ice states together. Now, in case of failure, you can then use DtlsTransport and other transport objects should be used to know if ALL failed, or a few failed.
18:37:42 [DrAlex]
justin: I want not only the migration path to be documented, but the path to be minimal.
18:37:50 [DrAlex]
shall we put it in 1.0?
18:38:38 [DrAlex]
justin: wel, every time you make a mistake, you face the same problem. In 1.0 connection state should keep the same states, but return the combined states. We could reuse the algorithm that peter proposed. that is what the application care about today.
18:38:47 [DrAlex]
justin: we should revised in 1.1
18:39:27 [DrAlex]
ekr: yes, we should keep the current semantic (like checking), and make it cover DTLS and ICE.
18:39:33 [DrAlex]
martin: why?
18:40:27 [DrAlex]
justin: the modification is so minor, while the impact on existing software is bigger. I don't care.
18:40:38 [DrAlex]
dan: if we fix a mistake, let s fix it.
18:41:27 [DrAlex]
varun: what happen if happen being connected, you lose connectivity, what happen ?
18:41:56 [dom_]
we're using different terms than for the data channel readState too
18:45:46 [DrAlex]
cullen: we need to keep API simple and intuitive. We need to write this thing for people who are using it.
18:48:12 [DrAlex]
harald: interesting point on completed
18:48:30 [DrAlex]
harald: I wrote the test, and completed is never reached
18:48:53 [DrAlex]
justin: yeah, well, not big surprise here, that s why i advocated we should just remove it.
18:53:32 [DrAlex]
dom: when there is a matching state, we should reuse the existing ones
18:55:54 [DrAlex]
next slide
18:56:06 [DrAlex]
needs discussion: PC.onwarning/onfatalerror
18:56:35 [DrAlex]
the original motivation was to handle the DTLS/ICE problem we just spoke about, so i m not motivated about this one again
18:56:53 [DrAlex]
justin: are we going to revisit this this afternoon ?
18:57:01 [DrAlex]
justin, let s keep it for later.
18:57:17 [DrAlex]
peter: PeerConnection warmup
18:59:44 [DrAlex]
cullen: ok, can we revisit the last IETF discussion about the active flag?
19:00:17 [DrAlex]
depending on wether you have a track or not, it will be different.
19:00:47 [DrAlex]
you could have a null track, set things up first, even before (while waiting for) getusermedia.
19:01:19 [DrAlex]
what about consent?
19:01:39 [DrAlex]
justin: there is a presentation on that this afternoon.
19:02:09 [DrAlex]
martin: we have to deal with that anyone as audio doe snot always come from GUM.
19:03:18 [DrAlex]
peter: there are more slides coming.
19:03:40 [DrAlex]
harald: so are we merging this or not?
19:04:00 [DrAlex]
martin: there are other pull requests there that we would need to address first
19:04:18 [DrAlex]
peter: there are some questions about which IDs to use, it s all in PR
19:04:30 [DrAlex]
martin: i m concerned that if we do not answer those questions we cannot conlude
19:04:33 [DrAlex]
conclude
19:07:22 [DrAlex]
martin: in any case, we need to note that if you use replace track with incompatible encoding, it will not work.
19:08:38 [Zakim]
Zakim has left #webrtc
19:08:41 [DrAlex]
question: firefox has a way to provide a "fake track". would we still need this with the warmup setting?
19:09:05 [DrAlex]
peter: I think you would NOT need it anymore. warmup would replace it indeed for a "no stream" / black stream.
19:12:20 [jeff]
jeff has joined #webrtc
19:12:27 [tedh]
tedh has joined #webrtc
19:12:39 [DrAlex]
harald: I think we have a rough consensus
19:13:53 [DrAlex]
"create a nothing track" is being put on the todo list, to be revisited later.
19:15:04 [DrAlex]
erik: who wants this, and what would we need to change.
19:15:49 [DrAlex]
dom: Can you have a full fledge PR ready, with the use case?
19:16:32 [DrAlex]
martin: it s ok, except suddenly one property is nullable, and the corresponding logic (how to handle the case where stream is null) needs to be documented.
19:18:42 [DrAlex]
justin: I'm just concerned about wasting bandwidth
19:20:56 [DrAlex]
harald: final decision here
19:21:02 [tedh]
Send a timed-text track with the phrase "This text purposefully left blank"?
19:21:14 [DrAlex]
harald: yes we want to support PC warmup here, seems to be the general consensus
19:21:46 [DrAlex]
harald: the question about how to set a null track should be left for later
19:22:09 [DrAlex]
peter: if we return to it, can someone stand up to write a full proposal, so we return to it in a better condition
19:23:55 [dom_]
RRsagent, this meeting spans midngiht
19:23:55 [RRSAgent]
I'm logging. I don't understand 'this meeting spans midngiht', dom_. Try /msg RRSAgent help
19:24:04 [dom_]
RRsagent, this meeting spans midnight
20:11:08 [tedh]
tedh has joined #webrtc
20:14:01 [RRSAgent]
I have made the request to generate http://www.w3.org/2015/09/09-webrtc-minutes.html vivien
20:16:15 [adamR]
adamR has joined #webrtc
20:18:16 [AndyH]
AndyH has joined #webrtc
20:23:10 [burn]
burn has joined #webrtc
20:24:49 [vivien]
scribe: vivien
20:24:58 [vivien]
peter: reviewing PR279
20:25:05 [vivien]
peter: PR is to add a method to add createRtpReceiver
20:25:18 [vivien]
... it also brings other issues documented in the slide deck
20:26:16 [DrAlex]
DrAlex has joined #webrtc
20:26:20 [vivien]
peter: a proposal is to to indicate if you want to send or receive or both
20:27:27 [vivien]
peter: in case of a warmup when you call addMedia you can specify send/receive
20:28:24 [vivien]
justin: createOffer is from old age this seems a much nicer way to me
20:28:59 [vivien]
justin: this a nice way to connect with an m-line
20:29:39 [vivien]
cullen: it looks great compared to what we need to do today
20:31:00 [vivien]
harald: the abstraction of SDP is bidirectional
20:31:30 [vivien]
martin: I am not seeing any value to this except hidding @1
20:32:45 [vivien]
peter: here by calling stop it makes it clear you are closing the line
20:33:28 [vivien]
justin: there was no way on the sender side to know the other side had stopped his track
20:34:26 [vivien]
justin: pb was what happended during the next offer as the sender did not know it was shutdown by the receiver
20:35:19 [vivien]
martin: all of that can be done with sender and receivers
20:35:48 [vivien]
justin: since SDP has no notion of only send we should not add that in our model
20:37:19 [vivien]
justmartin: you know from the signaling channel that the port has been set to 0
20:37:31 [vivien]
s/justmartin/martin/
20:38:20 [vivien]
harald: if I had this abstraction I can explain some of our magic things with this abstraction. addTrack becomes easy to explain
20:39:03 [vivien]
martin: I am concerned about the value we are getting in exchange to this. what feature are we going to add to that that we don't already have?
20:40:04 [vivien]
hrald: if we have the overline object then I can stop having stuff I do on sender that affect recevivers (and vice versa) and have object that don't affect each other seems a good feature
20:40:14 [vivien]
s/hrald/harald/
20:40:31 [vivien]
martin: we can already do that, this is adding nothing new to the API
20:41:31 [vivien]
adam: this seems like an improvement but not a necessary one
20:42:13 [vivien]
harald: I like it because it stops us as adding more craft I see this as a simplification for stuff we are currently adding
20:42:35 [vivien]
dom: are you talking about createRTPSender?
20:42:39 [vivien]
harald: yes
20:43:59 [vivien]
ekr: so what happens if you create rtcpreceiver @3
20:44:18 [dom]
dom has joined #webrtc
20:44:34 [vivien]
justin: it only adds an m-line or reuse one
20:45:28 [vivien]
martin: previously we had no way to set port to 0, we could send it to receive only and the other side switching in sending only. in SDP the inactive state is different that having port to 0
20:45:37 [vivien]
s/martin/justin/
20:46:48 [vivien]
martin: you can stop a track on the receive side and @4
20:47:45 [vivien]
jan-ivar: removetrack removes the sender yes
20:48:06 [jeff]
jeff has joined #webrtc
20:48:38 [vivien]
martin: not sure if it was implemented in firefox. it is not in Chrome
20:49:04 [vivien]
(harald reading the removeTrack definition in the spec)
20:49:32 [vivien]
peter: the JSEP has a big TODO on this
20:50:00 [vivien]
martin: I thought we ad agreement on track stop
20:50:16 [vivien]
justin: we did but as indicated in the bug tracker there are some issues
20:50:35 [vivien]
justin: so here we are trying to have a clearer modeling
20:51:37 [vivien]
justin: there really should be an object a pair that represents send/receive
20:52:20 [vivien]
erikL: are more people interested? it seems to be something to agree between google and mozilla here
20:53:26 [vivien]
justin: it will be less a to what I mean api. it can be made more explicit.
20:53:44 [vivien]
cullen: this would make our life easier
20:54:20 [vivien]
justin: in JSEP we always had the issue of having bi and unidirectlinal mline
20:55:06 [vivien]
erikL: do you think it should be in 1.0
20:55:16 [vivien]
justin: I think it is worth doing ?
20:55:42 [vivien]
ekr: 3 options:
20:55:47 [vivien]
... 1) leave things as is
20:56:04 [vivien]
... 2) @4
20:56:15 [vivien]
... 3) @5
20:56:58 [dom]
s/@4/go with creatertpsender and receiver/
20:57:11 [vivien]
justin: it currently requires application to have deep knowledge of SDP
20:57:16 [dom]
s/@5/use this addMedia proposal/
20:58:19 [vivien]
erikL: bernard what about edge ?
20:58:35 [vivien]
bernard: no SDP in Edge so don't concern us
21:01:02 [vivien]
Dan: it is interesting because it might make some of the things we discussed easier todo. so if it simplifies things then it is worth doing
21:01:19 [vivien]
adam: I see this cleaner. my concern is that we are going to find bad corners
21:01:38 [vivien]
martin: I want to decouple senders and receivers even further
21:02:00 [vivien]
martin: we made a lot of effort to make this abstraction strong
21:02:25 [vivien]
... to make sure those things are as separate as possible
21:03:32 [vivien]
justin: before I was fine hidding things but I know think it is better to give people what they want
21:04:16 [vivien]
martin: I don't agree with the principle but if accepted in the spec I'll deal with it and implement it
21:05:43 [vivien]
dan: would it be useful to discuss the other related things to see how they are affected by this proposal and come back to this
21:06:04 [vivien]
jan-ivar: it seems like a choice between a leaky abstraction and a low abstraction
21:07:13 [vivien]
ekr: maybe what we need is a work example from peter
21:07:36 [vivien]
peter: I have more use cases examples not shown in the slides I can write down
21:08:08 [vivien]
ekr: would motivate us if we have more cases to make the comparison
21:08:35 [vivien]
several people: good idea
21:08:59 [vivien]
harald: so we'll return to this on Thursday
21:10:54 [dom]
peter: so there are 4 approaches: api as is today, addMedia, createRTPSender/Receiver, EmptyMediastreamTrack
21:12:04 [vivien]
topic: Replace track by jan-Ivar
21:12:07 [dom]
Topic: replaceTrack
21:12:49 [vivien]
jan_ivar: this is about replaceTrack we we discussed earlier
21:13:00 [dom]
-> https://www.w3.org/2011/04/webrtc/wiki/images/d/de/ReplaceTrack_copy.pdf slides for replaceTrack
21:13:47 [vivien]
jan-ivar: we agree to have repalceTrack
21:14:16 [vivien]
jan-ivar: no renegotiation needed, it changes things on the wire
21:14:45 [vivien]
jan_ivar: an edge case when you have differnt audio and video channels
21:14:57 [vivien]
... shoudl we fire a renegotiation needed event
21:15:47 [vivien]
jan-ivar: pro would be ythat it will be less complex, con is that it can fails when it had the info to succeed
21:16:51 [vivien]
jan_ivar: pro potential to just work, con: more complex and need to figure out negotiation failure
21:17:34 [vivien]
s/should we/should we return a NegotiationNeededError or/
21:18:02 [vivien]
s/pro/negotiationneeded event pro/
21:20:00 [vivien]
justin: when renegotiation is needed the promise can never resolve
21:20:49 [vivien]
jan-ivar: with the event if would not resolve until the negotiation succeed
21:21:09 [vivien]
adam: @6
21:22:36 [vivien]
adma:you only do repalcetrack instead of remove/addtrack if you want to avoid renegotiation
21:23:38 [vivien]
stefan: you could repalce an audio track by a video track
21:23:47 [vivien]
martin: I think we should fail on that one
21:24:50 [vivien]
harald: an odd reason to like this, I can easily explain what addTrack does so adds abstraction
21:25:56 [vivien]
peter: we dont't have proposal for anything like that
21:25:57 [tedh]
tedh has joined #webrtc
21:26:07 [vivien]
justin: what is the PR ?
21:26:32 [jesup]
talk to the room mike please...
21:26:45 [vivien]
stefan: 237
21:27:04 [adamR]
jesup: the chairs have instructed us not to use the microphone, as it was hindering conversation.
21:27:28 [sherwinsim]
something happened in the last 10 minutes where we can no longer hear people very well
21:27:33 [jesup]
right, they asked people to speak up so it's picked up by the room mic
21:27:46 [vivien]
dom: the fact that the error gives you more power on how to handle renegotiation this to be a good reason
21:28:31 [adamR]
Erik: I think setting the mic down in front of the speakerphone thingy may have blocked off the microphone for our remote participants. You may want to remove or move it.
21:28:47 [Erik]
ok, thx will do
21:28:49 [vivien]
ekr: we are trading off people getting slightly behaviour vs people don't know what they are doing
21:29:17 [vivien]
dom: try without renegotation and it it fails then renegotiate
21:29:38 [varun]
varun has joined #webrtc
21:30:16 [vivien]
harald: which state the application sees when the negotiationneeded fires
21:31:01 [vivien]
harlad: it sounds to me we have rough consensus that we fail
21:31:29 [vivien]
Topic: CSRC Consensus Discussion
21:31:56 [vivien]
-> https://www.w3.org/2011/04/webrtc/wiki/images/d/df/CSRCs_and_AudioLevels_in_WebRTC_1.0.pdf slides
21:32:29 [vivien]
bernard on #276, do we agree on harald's proposal
21:32:46 [vivien]
s/bernard/bernard:/
21:33:46 [vivien]
martin: maybe we should not send this it it is not encrypted
21:33:52 [vivien]
s/it it/if it/
21:35:18 [vivien]
bernard: ok we have a resolution on this
21:36:39 [vivien]
bernard: #4 usage scenario conversation with an MCU which is mixing instead of simply forwarding
21:37:05 [vivien]
barnard: this proposal was discussed in the ORTC CG
21:37:24 [vivien]
bernard: concerns about load for people polling all the time
21:38:48 [vivien]
bernard: polling at 50ms is good
21:39:37 [vivien]
bernard: when does it caches out, could keep the last 5 minutes
21:40:50 [vivien]
cullen: something useful in webex to know who is talking, crtitical for conference systems
21:41:04 [vivien]
martin: I am concerned about the timestamp
21:41:16 [vivien]
bernard: we did not wanted to have it on every packets
21:41:49 [vivien]
adam: what I hear is has low cost, easy to implement and needed for teleconference folks
21:42:47 [vivien]
(harald proposing a quick vote)
21:42:59 [vivien]
harald: so most of us are in favor
21:43:11 [vivien]
stefan: so who creates a pull request
21:43:21 [vivien]
bernard: issue #6
21:43:50 [vivien]
bernard: audio level info
21:45:15 [vivien]
bernard: it is a slight refinement of what we just talked about with CSRCs
21:45:28 [vivien]
bernard: it is mixer to clients
21:47:15 [vivien]
justin: people we are polling stats and getting a multistream containing also energy info, so if they have an easy way to get only audio level it simplifies things
21:49:12 [vivien]
justin: could also be used to decide which video to present
21:49:39 [vivien]
bernard: for slecting dominant speaker you might also want to analyze the audio
21:49:50 [vivien]
s/slecting/selecting/
21:50:34 [vivien]
cullen: this prioposed UI use case looks quite nice
21:51:04 [vivien]
cullen: I'll do a PR for #4, and another that tackles #6
21:52:00 [vivien]
bernard: this API is not for selecting dominant speaking
21:55:27 [jib]
Did I hear half an hour break?
21:55:34 [sherwinsim]
i believe so
21:55:42 [adambe]
20 min I think? quarter past?
21:55:49 [jib]
ok
21:55:56 [sherwinsim]
waiting for @vivien to confirm
21:56:09 [sherwinsim]
LOL but people are leaving so thats enough for me
21:56:29 [adambe]
quarter past it is!
21:57:30 [DrAlex]
DrAlex has joined #webrtc
22:00:05 [AndyH]
AndyH has joined #webrtc
22:16:41 [tedh]
tedh has joined #webrtc
22:18:01 [vivien]
Topic: IP Address exposure control
22:18:26 [dom]
-> https://www.w3.org/2011/04/webrtc/wiki/images/d/da/WebRTC_IP_Address_Privacy.pdf slides on ip address privacy
22:19:51 [vivien]
Ekr: ICE gathers all the host IP address
22:20:37 [vivien]
Ekr: so the webserver runs yoru public address but all your aother addresses even if you are behind a VPN
22:20:51 [vivien]
s/yoru/your/
22:21:06 [vivien]
Ekr: bring privacy issues
22:21:32 [vivien]
... first is fingerprinting
22:22:10 [vivien]
... enables you to distinguish multiple people that are behind the same NAT
22:22:45 [vivien]
cullen: the ports would have tell you that
22:23:34 [vivien]
ekr: it is not useful to track you across multiple networks
22:23:56 [vivien]
ekr: second issue identify IP addresses hidden by VPNs
22:24:29 [vivien]
ekr: only happens with "split" VPN but vastly used
22:24:38 [vivien]
... some solutions to counter this
22:25:09 [vivien]
ekr: same issue when people are behind proxies
22:26:45 [vivien]
ekr: also security impact as you discover addresses on local network
22:27:03 [vivien]
... also possible using XHR
22:27:21 [vivien]
ekr: with us and google went overs several options
22:28:23 [vivien]
ekr: indicator when webrtc is in use, ask consent for any webrtc access, more restricted ICE gathering, extension to disable/restrict WebRTC
22:28:50 [vivien]
ekr: developing on restricted ICE gathering
22:29:16 [vivien]
... only show publicly visible addresses. Chrome and Firefox are deploying this.
22:29:23 [jesup]
https://wiki.mozilla.org/Media/WebRTC/Privacy may be useful (about what we've done in Firefox)
22:29:31 [jesup]
so far
22:30:27 [vivien]
cullen: could you explain consequences of those changes ?
22:30:58 [vivien]
ekr: if you are a relay it would not work
22:31:53 [vivien]
ekr: a proposal discussed with justin, if camera and micro are granted then you do notmal ICE gathering, otherwise the restricted one
22:32:05 [vivien]
... could have an option to control this
22:32:16 [jesup]
My personal NAT (standard FiOS router) doesn't hairpin, BTW
22:32:38 [vivien]
Justin: we are gathering metrics in canary
22:34:33 [vivien]
adamaR: people might request camera prompt just to get access to full ICE gathering
22:35:05 [vivien]
ekr: BTW it is a functionality flash and java already have
22:35:45 [vivien]
Matthieu: what happen when request camera/micro access and start a conenction, is there an upgrade path then ?
22:36:12 [vivien]
adamR: if you are using warmup we are only going warmup the public addresses
22:36:45 [vivien]
ekr: if you have TRUN it will start with low quality, and if you don't the call would fail
22:37:20 [vivien]
Matthieu: but will the browser upgrade teh conenction after ?
22:37:30 [vivien]
ekr: yes that is something we should do
22:38:23 [vivien]
TedH: the current prompt is not clear to users that by granting access to their camera they will also reveal private network information
22:39:11 [vivien]
Matthieu: would the proposed indicator be on all the time ?
22:39:30 [vivien]
ekr: probably on for some time during gathering and keep it on for some time
22:41:53 [vivien]
tedH: a middle path here we don't suppress the local address if it is a primary address but you suppress it if it is a secondary address
22:43:25 [vivien]
ekr: we could certainly do that
22:44:14 [vivien]
cullen: for internal comapny use, people will not be happy that traffic will first go through an outside TURN server
22:46:12 [vivien]
ekr: I like ted suggestion, but there should be some condition to get me out of the default box behavior
22:46:34 [vivien]
ted: perhaps in the same dialog "is that ok if I view your private IP address"
22:46:51 [vivien]
s/ted/ekr/
22:46:52 [jib]
jib has joined #webrtc
22:47:23 [vivien]
ekr: we should be able to detect the simple case
22:48:07 [vivien]
ekr: having two user prompts would not be good
22:48:49 [daviddias]
daviddias has joined #webrtc
22:48:55 [vivien]
tedH: I think you can say camera microphone and network location
22:49:09 [vivien]
martin: this also gives geolocation
22:50:45 [vivien]
tedH: with public ipv6 addresses and split VPN, people will be surprised
22:51:15 [vivien]
cullen: for those using a split VPN we are offering them a solution by using a browser extension (or a browser preference)
22:52:17 [vivien]
tedH: I disagreee with cullen that if you are running with VPN you have to install something else
22:53:14 [vivien]
cullen: the split vpn don't bring you privacy and the VPN vendor tell you that explicitly
22:54:49 [vivien]
tedH: if you are doing a data channel you will need to give a user prompt
22:55:54 [vivien]
@7: the 1918 candidates if you strip them, can find that information already (XHR, ...) by that you can determine the entire map
22:56:56 [vivien]
ekr: what we do is to take the 0.0.0.0 address to connect to google dns and then find the public address
22:57:06 [vivien]
s/we do/we do in firefox/
22:59:55 [vivien]
ekr: I fill we could make the change proposed by TedH and ship in beta to test it
23:01:25 [vivien]
justin: everything that involves reading the routing table I am usually concerned about
23:02:07 [vivien]
justin: what if the route to 8.8.8.8 is different than the route to the TURN server
23:03:13 [vivien]
ekr: in case if chrome if you are multihome you have multiple routes and chromes we show all, whereas firefox will show only one
23:03:34 [vivien]
s/@7/jesup/
23:03:47 [vivien]
jesup: @8
23:04:55 [vivien]
justin: people are using webrtc detection to detect abuse for people behind proxies
23:05:34 [vivien]
matthieu: what about when you use socks
23:06:12 [vivien]
justin: when you use a web proxy it is not clear to us if you also want your webrtc traffic to go through your proxy
23:07:15 [vivien]
ekr: if you are exposing 1819 addresses it will almost always work
23:08:15 [tedh]
tedh has joined #webrtc
23:08:22 [vivien]
tedH: if you combine what I suggested and what adam suggested I think it will answer most issues
23:10:50 [vivien]
adama's proposal was to resolve the STUN server ip address instead of a random address (here google ip address)
23:10:57 [vivien]
s/adama/adam/
23:13:40 [vivien]
ekr: you bind a 0.0.0.0 and all your 1918 addresses
23:14:53 [vivien]
justin: the thing we did not talk about is the grant permission for enumerating network
23:15:09 [vivien]
justin: there is work in W3C for a Permissions API
23:15:46 [vivien]
martin: there is asking the browser about the state of a given permission, then requesting that a permission move from one state to another
23:16:03 [vivien]
jsutin: should this be part of our matrix decision here
23:17:03 [vivien]
Proposed solutions written be Ekr on the whiteboard:
23:17:06 [vivien]
1. Don't fix proxies
23:17:20 [vivien]
2. Don't need to hive 1918 addresses
23:17:46 [vivien]
3. "Ask for netwrok" gum argument is bad
23:17:57 [vivien]
s/Proposed solutions/Summary/
23:18:09 [vivien]
s/netwrok/network/
23:20:51 [vivien]
4. Need a way to get out of the box
23:22:20 [vivien]
0. Affordances for extensions are good
23:24:15 [vivien]
Topic: Screen share
23:24:32 [vivien]
-> https://www.w3.org/2011/04/webrtc/wiki/images/b/b7/ScreenShare_Sept15v2_draft.pdf slides
23:25:09 [vivien]
martin: extension to gUM to share screen content
23:25:46 [vivien]
martin: considerations: security, UI concerns, user awareness, API extensions
23:26:38 [vivien]
martin: issue #28 no persistent permission for screen sharing
23:27:19 [vivien]
... we might want to say never share it, or default always prompt user
23:28:10 [vivien]
... no persistent allow state
23:28:44 [vivien]
martin: if blocked then the site will immediately refuse the request
23:29:23 [vivien]
justin: do you call gUM prompt or do you use the permission API
23:29:49 [vivien]
martin: we would use something similar to gUM, as users will need to select what part of screen will be shared
23:30:45 [vivien]
martin: sharing yoru terminal is benign, whereas sharing your browser is risky
23:30:48 [vivien]
s/yoru/your/
23:31:01 [RRSAgent]
I have made the request to generate http://www.w3.org/2015/09/09-webrtc-minutes.html vivien
23:31:13 [yusuke]
yusuke has joined #webrtc
23:31:49 [vivien]
keith: a comment use case is to share a document within a browser so you share a tab
23:32:26 [aaa]
aaa has joined #webrtc
23:32:38 [yusuke]
yusuke has joined #webrtc
23:32:58 [vivien]
Shijun: also problem of navigation
23:33:31 [vivien]
martin: no differnt from a security perspective, as soon as you are sharing your screen you open the pandora box
23:33:59 [vivien]
martin: there will be an indicatior to indicate that a particular tab is being shared
23:35:04 [vivien]
Shijun: navigating between tabs might actually means switching between processes
23:35:29 [vivien]
martin: yes could be a problem for you that is something to deal in each implementation
23:36:51 [vivien]
dom: you are saying this will remain unspecified in the spec
23:37:22 [vivien]
martin: each browser would have to decide what is under which class
23:38:01 [vivien]
barnard: certain apps might also require elevated permissions
23:38:21 [vivien]
ekr: the user is smart to know what he is sharing
23:39:03 [vivien]
martin: to answer bernard within the browser there is a lot of control options
23:41:00 [vivien]
dom: elevated permissions do we intent to have something interoperable
23:41:27 [vivien]
dom: I don't want firefox to choose what websites are allowed to use screensharing
23:41:46 [vivien]
martin: we actually discussed that in our legal team
23:42:45 [vivien]
dom: my point is that as a web app developper I don't want to implement 10 extensions to deal with the persmissions of each browser
23:42:53 [vivien]
is that something we want to tackle ?
23:43:55 [vivien]
s/is/... is/
23:44:44 [vivien]
alexandre: in november from the app dev perspective it would be nice to have a common way
23:45:29 [vivien]
s/it would/we said it would/
23:46:54 [vivien]
ekr: chrome only allows you to do it through an extension, and firefox you need to be on a whitelist
23:49:05 [vivien]
martin: if you want to know the current status you will have to request the permissions API
23:49:48 [vivien]
dom: your initial plan was that there would be no need for individual addons
23:50:21 [vivien]
martin: still the plan I don't want to have to initial an different add-on for each individual site
23:51:37 [vivien]
martin: showing other smaller issues
23:52:36 [vivien]
Shijun: if multiple windows do you have multiple video tracks?
23:53:42 [dom]
dom has joined #webrtc
23:54:15 [vivien]
martin: it is one of the question, currently only in one track
23:54:31 [vivien]
cullen: on do you choose the application of the window
23:54:59 [vivien]
martin: you have to choose wether you want to share applications, of specific windows, so you don't get a combined list
23:56:46 [vivien]
martin: we need the windows sharing to be the easiest thing, but handle other modes users might need
00:01:05 [vivien]
RRSAgent, draft minutes
00:01:05 [RRSAgent]
I have made the request to generate http://www.w3.org/2015/09/09-webrtc-minutes.html vivien
00:03:28 [tedh]
tedh has left #webrtc
00:21:58 [jxck]
jxck has joined #webrtc
00:40:10 [adamR]
adamR has joined #webrtc
01:19:50 [hige]
hige has joined #webrtc
01:20:02 [hige]
hige has left #webrtc
01:29:32 [mreavy|mac]
mreavy|mac has joined #webrtc