Web Real-Time Communications Working Group F2F

21 May 2014


See also: IRC log


HTA, StefanH, Adambe, AdamR, JIB, EKR, Martin, pthatcher, Juberti, shijun, bernard, Fluffy, burn, JimB, AlexGouaillard, Dom, TedHardie, AndrewH, Uwe, DanDruta, RichardBarnes, Suhas, DiniMartini, Jesup (remote), Lagerway (remote), Kiran (remote)
MaryBarnes, Giri, RomanShpount, SeanTurner, Jonathan Lennox (remote), Tzabari Gili (remote)
HTA, stefanh


<dom> scribenick: jib

<dom> scribe: jib

Stats definitions

<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

.thanks harald

Next: Identity

Identity and security implications

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' slides

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

<jesup> https://plus.google.com/hangouts/_/google.com/41025012?hceid=aGFyZGllQGdvb2dsZS5jb20.ijvifsrjf0c7vqgbo2v9spilpo

<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

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

Summary of Action Items

[NEW] 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]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2014-05-27 12:43:38 $