See also: IRC log
<dom> scribenick: jib
<dom> scribe: jib
<dom> Harald's slides
<gmandyam> Giri Mandyam joining as an observer from Qualcomm Innovation Center
hta presenting
<dom> Stats development space
mt: Tim Terriberry pointed to a spec in the audio community quite some time ago that has a well defined volume definition
cullen: that is in the audio draft
... we dont want the audio volume, we want a change in the audio volume
<Ted_> from Tim: My recommendation would be to follow EBU R128: <http://tech.ebu.ch/loudness>. See specifically EBU Tech Doc 3344.
… you're just saying it is going up or down in a deterministic way across browsers. Its a hard problem
<Mary> Correct link is: http://tech.ebu.ch/loudness
hta: next: inter-object pointers
mt: now that we have lots of objects in justin's proposal, why not use those instead of the internal stats objects by-id?
… getStats for my dohickey
justin: how do internal objects get referenced?
hta: then you loose ability to make snapshots
… I'm thinking about the case where you get stats from three different objects, and you make a computation between two sets a couple of seconds apart
… and that's why we have timestamps on stats objects
… going to the live object instead ot a stats object would be a complete change to the api.
Slide: Thorny stuff (2)
hta: a lot of what we're trying to monitor is not standardized
<Ted_> jesup: are getting good video?
<jesup> yes
Slide: More work
<Ted_> Okay. Harald is using the local stand mic at the podium
justin: go back for a second: how is the video discriminator going to work?
<Ted_> Should he switch to a lapel mic?
hta: (some answer scribe missed)
... I want to take wiki page and publish it as a separate document
cullen: a lot of this needs to be in the base spec
dom: I suggest we don't use the reference scheme to achieve this
cullen: I suggest leave base stats in webrtc spec and further stats in new doc
hta: I don't like that
… I'd like to have one place for everything
rather have a baseline 1 and immediately work on a baseline 2
… would that work fo you?
cullen: yes if people must implement what is in the base spec
hta: next: do we have to represent 'component'?
mt: can I of push for stats for rtp transport would include rtcp stats? (best guess)
hta: problem with that , ip addresses
... if ip is different for rtp rtcp then you need another place
mt: we decided we dont want the separate object, we wont make those ips available in stats, too bad
hta: in non-mux case we'll have a stats object, and btw here's a link to a separate object
uwe: not happy with not exposing it
… fine with separate transport object. but we should be able to access the information
justin: I think we'll be sad if we take a shortcut
... why dont we have a separate stats object and point to it?
mt: it will be exposed to the dom
hta: rrough consensus that stats should speak the truth: = two stats for two transports. will make a suggestion on the list
stefan: sounds good
Next: Identity
Slide: requestIdentity
<dom> Martin's slides
mt: proposal remove this RTCConfiguration parameter
... solved
agreement to remove
Slide: Isolation Scope
mt: I suggest that any isolated track will cause peerconnection to negotiate isolation with all
... if you have an isolated and a nonisolated track you want the remote to respect isolation for all tracks. - simplifies
???: how do I know ??
mt: this is simplifying model
Slide: Problem
... Option 1
mt: what do we do when it comes to negotiating sessions where eaither side have different expectations on isolation?
Slide: Advantages of Option 1
dan: is this right group?
mt: this is "what do we want?"
Slide: Option 2
ekr: if either side wants isolation you get isolatio?
mt: yes
… simplifies it
cullen: both doors have to be locked
hta: this means browser A that browser B is sending isolated tracks, but browser B can still run a JS plugin that does bad stuff
mt: cake is something, icing is knowing ?? We need something to say this media comes from x.com and no-one else.
dan: question: if in browser A I give permission to fluffy, what does it mean to isolate the media coming to me?
mt: isolation is lowering of access
…you can render this that's it
… when you pull it off the network wih a PC that is tagged as isolated, then you can render it and that's it
mt: isolated both ways
…identity is asymmetric
???(ms): I'm receiving something browser A, I need to know it is coming from A, right? How do I do that?
mt: at the receiving side you know the source is the network, and the TLS connection was with isolation on or off. If on, youre on your way
dom: an isolated peerconnection creates a separate origin basically
m: web page doesn't have any say once its mtade this web page and supports this feature
dan: authentication is something you go through when you log in, but there are a variety of ways to get isolation
mt: authentication is only required to get isolation through, or it goes nowhere
Slide: Isolation Timing
jonneth: if adding isolated tracks to PC , what happens if you have the model where you add a data channel, then I want to add isolatiod tracks. bundle. can I do that?
mt: then you cant
... solution: put a peerIdentity constriction on the peerConnection
jonneth: what does it apply to? just media?
what about stats?
ekr: maybe not give stats for isolated streams
stefan: what about a track in use becomes isolated?
mt: getUserMedia is not the only way to get a track. CaptureUntilEnded
... say you're sourcing a video-tag from a website and you're using dash or some sort of streaming protocol, then recreate
… then the model forces cross-origin which means we have to respect that tracks may change their properties over time.
scribe: same for audio
… when we force cross-origin we have to stop sending
dan: how to configure?
mt: when you provide peerIdentity:foo, it says don't allow session to complete without valid id assertion=foo
ekr: I suggest this first case, needs onnegotiationneeded
mt: adding a track should always cause onnegotiationneeded
ekr: I think always, but if not it should
mt: only concern if you're switching in and out with the aim of not renegotiation, we need to catch that for this isolation case
cullen: with onnegotationneeded, will it have to close and reopen the DTLS connection?
mt: yes
cullen: DTLS connection closes?
ekr: no, just like ICE restart
cullen: will we need the ELPN (sp?) value?
… lets not
mt: agree
…that's what I have
stefan: question related to schedule. we said last call for late september
mt: should be done well before then
jonneth: when it fails, is it silence forever or till onnegitiationneeded fires? black forever without me knowing about it would make me sad
mt: unavoidable
… till you get the callback
mt: but if track changes isolation state then it's harder but that is an edge case
... we suggested we didn't need to know this earlier
dan: echoing jonneth. what if a naive developer finds themselves with things not working. Just trying to show them basic stuff. Nice to avoid things just failing. Necessary to solve this in real apps. The more failure modes we require renegotiation for then that's not great, how do we avoid that?
dom: suddenly it's black, then how does the model help understand this.
mt: error reporting
ekr: you can't get into this situation accidentally
... it's a feature, if you use this feature you should handle it
dan: you were saying there were cases where you could get redirect, where you didn't cause it
ekr: (some example)
dom: about cameras: I dont want to send video Im watching. Say you're using an interactive canvas
mt: canvas wont render isolation
ekr: otherwise you could use canvas to bypass origin protection
... going back to martins presentation yesterday: if you attempt to add a cross origin video to a PC that should generate some kind of error or warning or exception
dan: what about something that becomes cross-origin for an action you didn't take as a developer
ekr: that can't happen
mt: its always your fault
jonneth: question on that: if the other guy decides to go isolated, is that my fault?
mt: yes, you are the one writing the code in the browser
... explore adding information on MediaStream? Sounds like some are arguing for that
… DOM object MediaStream would get a new attribute "you can't touch me"
dom: an 'Isolated' property
mt: and an event
... most of these things are directly initiated by the JS
... and isolated:true/false propose an onisolation event is enough
… in mediacapture spec
mt: if you did a capture on a DRM mediastream, you would get a mediastream but all you could do was render to the screen
<Cow_woC> JonathanLennox: :)
dan: can you reconcile: gum obtained track can be isolated.
mt: tracks can change their isolated state at any time
dom: would be nice if you could know that it couldn't change
… if you know it comes from gUM you know it cant change and don't have to monitor the onisolatedchange
mt: if it comes from PC then it can change
… don't think we should assume the invariant that if it comes from gum then it can't change, but...
<scribe> ACTION: mt Add some property on MediaStreamTrack for Isolated:true/false, and onisolatedchange event [recorded in http://www.w3.org/2014/05/21-webrtc-irc]
<trackbot> Created ACTION-113 - Add some property on mediastreamtrack for isolated:true/false, and onisolatedchange event [on Martin Thomson - due 2014-05-28].
???: question: what about a mesh network? One wants isolation another don't?
cullen: don't think it'll be much of an issue since there are different PCs
… lets same I'm in conference, if I send my media to you and then you send it on then there may be a problem, but not otherwise
mt: a transient property
cullen: if I had cloned the tracks then ...
mt: when you clone an unisolated track and then these clones, some can be isolated and others may not
ted: basic point is correct. Someone asking for isolated. this is a consequence of our model
mt: if you want isolation in a relay environment, the first guy is not going to be able to send it on
dom: in a mesh, if only one of the user is adding something to a nonauthorized source, does this change things for everyone?
…does the application need a way to control this odd usecase?
ted: can't send the kitten on
… you have to put it in a separate PC to not taint everything else
dom: my fear is that you're not trying to protect whats in the camera, it just happened that one of the users tried to do something, I as a developer how do I avoid sending black?
mt: how about a property on a stream "I'm now sending black"?
???(ms): you mentioned changing track from isolated to nonisolated?
mt: app wont be able to change that, that's a case the browser controls
... crazy internal stuff
… user says "I'm protecting this stream" can't change that
dan: you can't avoid being tainted. you don't know whether anything you get from a PC can get tainted down the road
... that may cause everything else that you send to get tainted, and you must use a separate PC
… people who talk about ways to relay media may be tripped up by this
stefan: we have a lot to do
time for coffee
<stefanh> scribenick: stefanh
Alex going through slides
First: Data channel label uniqeuness
prop: update the spec to say do not have to be unique
... need to sort field to large/long - 6553x bytes
justin: rtp data channel long gone
... don't think that have a 6553x length is a problem in real world use
Randell: they should look up the limit
justin: we should cut at 65k and call it a day
Alex: how to know max size on sending
Justin: use the new w3c streams api is what I have heard people say
Alex: question is if we should add something to the API
justin: we should use streams api for the time being
alex: needs to use different stun/turn servers for ff and chrome
justin+ekr: should be fixed now, may be broken
<kiran> Hi my connection got disconnected while discussing label uniqueness.. can some one please let me know what was discussed on this.
ekr to verify it is fixed
alex: next topic trickle ice
... ice candidates not fired
ekr and adamr discussing
cullen: we cleared this up during this meeting - but need to make sure it gets documented
alex: next topic: mediaStream.stop() method
... users wanting a global stop method for a stream
justin: a stream is just a bunch of tracks - has no state
randell: people asking for this feature
<JonathanLennox> kiran - archive of the irc channel is at http://www.w3.org/2014/05/21-webrtc-irc
danb: we could add something back in for convenience
... some more discussion
hta: data channels should not be treated as tracks
cullen: we should add a method to get all tracks to stream
... as well as get all tracks of a certain type
alex showing slide on implementation status
ekr disagreeing
randell: I have video forwarding work in ff at one stage
... full browser ec now active
thanks alex
next summary and conclusion
for media cap: we're getting close (to lc)
scribe: solution emerging for constraints
for weeebrtc: a couple of big items: doohickeys and isolation in all its forms
scribe: most seem resonably settled, but we will discover bugs down the road
... we're fairly happy, the meeting has been useful
we at w3c are worried about the progress at ietf side so we will chase people
back to media capture: we have the understandings from this meeting and the bug resolutions to integrate, but I see a lc glimmering in the distance (June?)
what could we have done better?
giri: bunch of bugs filed after hta did his presentation
whats the plan when it comes to dealing this (given next f2f is tpac)?
hta: main tool: mail, but we will call for teleconferences
... will try to solve the nit-type bugs asap
mt: would be good if someone could go through the bugs and see what bugs that have no proposed solution or plan to solve
hta: the list is under development, but we need to assign them to people
justin: how much work remains?
hta: for media cap we're close in terms of weeks
... for webrtc we don't know yet - we're not at that stage yet
... hope to be there before summer's ietf meeting?
cullen: should we focus on gUM and on webrtc?
justin: if we could finsih one would be better than two unfinished ones
bernard: agree
justin: what needs to happen on in/out discussion
hta: what i've been hearing: simulcast is out, doohickeys in, what is in the spec is in
bernard: should finish what we have - can do more than we think
... with what we have
danb: constraints need more spec, need to spec what ideal really means
... to avoid misunderstandings
... need an assignee
justin: a lot of things that are not in the spec
... we should agree on them being out (rehydration, screen sharing, simulcast, rollback....)
... would like to understand what is out of 1.0
... to get total view of things
hta: we have work to do, see you next time
(may have a gettoghether before tpac)
over and out