WebRTC TPAC 2015 F2F Day 1 -- 29 Oct 2015

Agenda review for Thursday

<dom> Agenda: https://www.w3.org/2011/04/webrtc/wiki/October_29_-_30_2015

Stefan: Going through agenda

Stefan: is everybody ok swapping simulcast and webrtc privacy afternoon sessions?

harald: adding agenda bashing tomorrow morning for friday

stefan: moving on to added functionality

<juberti> so: agenda is: transceiver and other 1.0 stuff this morning; simulcast in afternoon; IP privacy tomorrow morning?

Added functionality in WebRTC-1.0 after interim meeting

Stefan's slides on Status on what was agreed to add/merge in Redmond

Stefan going through list of what was agreed since Seattle

martin: didn't have time to finish PR for pre-negotiation

stefan: almost all done for items since seattle. separate discussion for simulcast
... peter can go for slides on transciever

RTP Tranceivers

PeterT's slides on Transceiver

peter: Things that we added: 1:1 mapping between mline and transceiver
... method for creating transceiver

martin: why do we have get transceiver as getter
... should mid be on transceiver ?

peter: for linking back to sender

martin: there is no attribute ?

peter: no

<fluffy> So martin said we need to mark the sender and receiver objects as “saome object” in webild

<fluffy> seemed to agrement on that

<juberti> going afk for a bit; back in ~1hr

fluffy: is removing offerToReceive not a problem for breaking what's out there already ?

martin: remove from spec but keep in implem and deprecate

adam: we're prefixed anyway so not a problem:

martin: FF 44 has webrtc unprefixed
... will have both prefix and unprefix because of broken polyfills

peter: leave to browser to handle as implem decision but remove from spec

fluffy: document in backwards compatibility section ?

martin: ok either way

harald: consensus is removing

peter: removeTrack deactivates instead of removing sender
... simplified version of examples

fluffy: media before signalling: if I ever got the video before answer is applied, it would render to video tag in this case ?

harald: if things are wired that packets manage to come in, then yes

<jesup> it's very hard to hear many of the people due to the mic-ing.... some aren't hearable due to distance, mic, or voice frequency (hta ;-)

<hta> I'm sorry - my voice is gone, so I'm more handicapped than usual by the fact that the mike stopped moving.

peter: if iframe comes in before fingerprint, we can rprocess it but not render it

dom: that example in not in any PR

peter: will fix that
... next, remaining questions
... when does addtrack reuse sender
... option a: reuse sender if inactive

fluffy: can we drop whole problem of replace track onto JSEP ?

peter: JSEP doesn't fully solve it yet ?
... option C, recommended, reuse sender if never been active

fluffy: that's what jsep does
... worried this is defined in 2 places

peter: already refers to jsep

fluffy: this sounds like agreement on solution, we need to figure out how to put it correcty in spec

dan: shouldn't use word "resuse", since it's really use if never been used

harald: concensus on C. need to figure out which document writes it

adam: theres a discrepancy with jsep.

martin: jsep says you can revive if both sides know it's gone, port 0
... we're missing that here
... not using what justin carefully crafted

peter: justin said use case was too complicated and so didn't have to handle it

harald: receiver is gonna see the wrong thing on other end. so only solution is to signal.

martin: I think what happen is that new transciever sender and receiver might reuse mid

fluffy: at any given point one to one relationship between mline and transceiver
... but if mline is gone and transceiver gone, then new one might end up on same mline

martin: there is a concern. all good on sender side, but receiver might not know. solution is to change mid

fluffy: need justin and ekr and whiteboard this

martin: can try to solve it tomorrow. ekr will be here.

fluffy: record strawman so justin can catch up

<adamR> The general shape of the solution is: (1) We will recycle m= sections, as described in draft-ietf-rtc-jsep; (2) We will use *new* transceivers whenever an m= line is recycled; and (3) we *probably*, subject to further analysis, need to change MID on a recyled m= section

peter: question 2
... how to activate transceiver without calling addTrack
... option a: setActive

harald: should we make all senders active by default ?

peter: would need to change addTrack logic to behave like replaceTrack ?

harald: it's in case of never been used, so shouldn't need to change anything

peter: idea is sender are automatically activate, and redefine addTrack as if active sender that never had track, use replaceTrack logic ?
... this might work

fluffy: deafult in SDP is send receive. still need a way to "deactivate"

peter: option b: put activate sender on transceiver
... sound like one off

fluffy: setDirection on transceiver might make more sense. and reflects what's going on in SDP. wouldn't feel weird
... active is not a good name

peter: so everybody happy with transceiver ."setHorrible" ?

harald: setRemoteDescrition might change thos bits
... transceiver need to go muck with sender and receiver

peter: is all this worth it compared to say, if you do warm up, you'll have to do re-offer

fluffy: you might just be able to do offer, provisional answer, answer

peter: if that's true we dont need setHorrible ?
... scenario already fine in non-warm up

fluffy: are we trying to solve a non-problem
... this example is not enough to see where the issue is
... nice option with this is we dont need pranswer
... but it's still 2 signalling messages

peter: 2 q: is ugly bit worth it? what is exactyly the ugly bit

martin & fluffy: yes needed, peter to decide what api looks like

<vivien> (that was option B)

peter: question 3, harder question, rollback
... option a, never remove transceiver

fluffy: if it's there, is it functional, how do you know ?

martin: how do you diff between good & bad

peter: not good option
... option b: always remove

martin: crux of problem: are you rolling back remote offer, or everything done since left stable ?
... what if stable, call addTrack, then setRemote. track might be added to existing transceiver . what do you do on roolback ?

fluffy: you go back to stable

martin: this doesn't work, describing issue if some tracks were added, others not
... should roll back offer, not add tracks
... let tracks sit there

fluffy: ok, that's about negotiated offer

peter: option b no good
... option c, ... out not possible
... option D,

martin raising an issue

peter: option D is meh
... option E

fluffy: this is weird but might be less weird, more fitting mline

martin: this might be combined with others

peter: E is potential, option F
... has potential too

martin: option F is very close to current FF implementation of rollback, so it's kinda right, but need better model

peter: option G

martin: sounds like option D with extra thing
... so better than D

fluffy: it's consistent with everything else we've done

peter: option H

harald: there's one case where you need to rollback remote offer: glare

peter: but you roll back local offer, not remote

martin: existing session, receive remote offer, apply it, some tracks appear, don't like all the new stuff, and want to rollback to stop receiving all that

peter: all sounds like weird edge cases

fluffy: need to do something to get back to stable state though

martin & adam: H looks better and better

harald: on rollback, transceiver that haven't been used, go in mid bucket

peter: G might not actually solve problem
... down to E, F, H

martin: G by itself is not enough but might give you a good base

peter wants to revive part of B

peter: go with G, call addtrack, add to pending, rollback, pending ones stay around ?

harald: need way to find pending and kill them

<juberti> back

<mt> addTrack creates a pending transceiver

<mt> setRemote(offer) creates a pending transceiver

summary, martin & peter to work on G + F

<mt> addTrack adds a sender to the transceiver; setRemote(offer) adds a receiver to the transceiver

<mt> on rollback, transceivers are removed from the pending unless they have an active sender

<juberti> H is needed as long as we want to be able to reject offers.

<mt> (this has the consequence of activateSender() being persisted

<mt> juberti: is that back to front? H is to now permit rejecting of offers

<mt> sorry, H is to not permit rejecting offers

<juberti> H is to not permit rollback; I was making the point that that implies no rejection, which seems drastic.

everybody is coming back to the room, about to resume

Codec selection

stefan: next up, codec selection

MartinT's slides on Codec selection before offer/answer

martin: application might want to exert control over what browser negotiates
... I sent email to mmusic, will simulcast allow you negotiate things in one direction but not other

adam: were reluctant to spec that out so far.

martin: simulcast is asymetric

<juberti> let's just keep it simple and be asymmetric

<juberti> er, symmetric

adam: don't want to make mandatory for webrtc

martin: let get to the question first

on slide 4

fluffy: weird that you get list from one object and set on another

martin: that's why there's other slide

aaa: appliation is basically ordering list, what if codec is not ...

marting: something about hardware codec

fluffy: I have proposal to be in line with SDP
... person that generates answer need to accept preference order of offer
... order set here controls what is in offer

martin: question is on answer, what do you follow, spd, local setting, browser implem

fluffy: need to be deterministic

martin: should affect sdp
... we working on this so we don;t have to munch sdp

adam: sdp is pretty thorough. order is meaningful. but both sides don't have to have same order

martin: reduce number of codec easy. ordering. set order of things in sdp, and when you receive sdp, you're supposed to follow sdp rules
... next, alternative (slide 5)

peter: 2 things set availble and set order

martin: this is closer to getCapabilities and Prederence on sender and receiver but issue
... first option seem better way to do it

fluffy: with adaptations from adam

martin: PR might already have been merged?

peter: already have non active flag when no track on transceiver

martin: conclusion option 1, with adam interpretation of SDP.
... affect both offer and answer

fluffy: have to define on re-offer what you do with order. should maintain.

all agreed

<burn> martin has asked me to type into IRC that it is important to capture key discussion points in the minutes in addition to the final decisions

<fluffy> When we do a reoffer, we maintain the previoulsy negotated ordering

stefan: end of morning sessions, can we sneak in soenthing before lunch break

<mt> conclusion is that the codec ordering determines what is put in SDP

<juberti> Did we discuss what happens if telephone-event, CN, red, FEC, rtx appear in codec preferences?

<mt> SDP determines what - absent overriding preferences - a sender uses

<mt> juberti - I mentioned those as being overriding preferences

<juberti> ?

<mt> as in if they are ordered above more useful things, then they won't get chosen just because they come first

<mt> I guess we could decide that these generate errors, or ordering of them are ignored

<adamR> juberti: This is normal SDP processing — if a codec can’t encode the input media, you skip it and move on to the next thing.

<mt> I don't think that's particularly important to address now, we can nut that out in the PR discussion

<juberti> well, I was wondering if we would always stuff these at the end regardless of setCodecPreferences. Agree this is small beer

<mt> I'm happy to just echo whatever crap the application feeds us, but equally happy to require they be pushed to the back

<juberti> for setCodecPreferences, we just need to ensure that ordering is maintained across reoffers, regardless of browser preferences. That prevents oscillation.

Stats

doing stats (originally Friday afternoon)

Varun and Harald's slides on Stats

varun: 2 updates since TPAC 2014

varun: open issue #5
... question is to knwo where to define RTCStats, in webrtc-pc or webrtc-stats

fluffy: stats document could be considered as first official extension
... base doc has base object definition

harald: might need to repeat definition of object
... for convenience

varun: stats document would stay open longer

fluffy: can't implement living standards. need to have one doc with mti, and then open another one
... some stats normative in webrtc spec, then add more in extensions doc for stats.

harald: action item for dom to share link to document on naming
... for hyphen

varun: issue #7
... PR not merged

<dom> "Enumeration values: Lowercase, dash-delimited " in http://w3ctag.github.io/design-principles/#casing-rules

varun: if non controversial, go ahead and merge
... issue #11

<juberti> RTCIceCandidateAttributeInfoStats... sounds like Java

varun: should we add "info" to all too ?

martin: can't we just have "Stats"

mathieucitrix: don't we have some of the "static" stuff on other objects?

peter: we have both now

justin: odd we have 2 dict that have same info

martin: should all be interfaces

justin: peter can't we go use the ice objects directly and do away with stats

<fluffy> http://www.w3.org/TR/2014/WD-webrtc-stats-20141021/#icecandidate-dict*

bbb: can't we share same object

harald: no

martin: or have Stats interface implement RTCCandidate
... not possible with dict but might be possible with interface here ?

justin: need to at least make them look the same

martin: if they're copy of each other, ok

peter: stats has one more field with associated turn / stun url

justin: stats object is also missing a field

martin: have stats have everything, or both have everything

peter: or embed?

harald: filed issue #31

martin: peter has suggestion: put address in stats, and embed RTCCandidate

harald: something about serializer

justin: remove RTCIceCandidateAttributes, and embed RTCIceCandidate in the PairStats

harald: lots of duplication

bbb: we want to avoid duplicating all that info

<hta> Jan-Ivar=Jan-Ivar

<jesup> Good by me

fluffy: lets get rid of Attributes and Info, everybody agree, done

<juberti> RTCIceCandidateStats and RTCIceCandidate. Sold.

varun: issue #13

fluffy: should reference IETF spec

harald: draft expired 2012

fluffy: tell to resubmit, w3c shouldn't define this stuff

<juberti> Did we discuss #12?

varun: conclusion: tell magnus to put definition in active draft

<juberti> RTCIceCandidateStats.addressSourceUrl is different than RTCIceCandidateEvent.url

harald: action for adam to ping magnus

varun: issue #16

martin: opposed, raise risk of app parsing and changing behavior based on content like user agent.

harald: should have standard way to parse info. but only if can make it useful for stats

martin: massive fingerprinting surface

mathieucitrix: can we get info of whether hardware of software decoder is used in stats

adam: does not belong in stats

fluffy: ok with one bit of info, but not in stats

varun: issue #

all: undefined

justin: did we discuss #12

varun: has already been fixed

justin: it's inconstitent

harald: noted that in issue #21

<juberti> (#issue 21)

fluffy: we need some stats being defined as MTI in webrtc-pc

varun: add new metrics. packetsDiscarded/Repaired

fluffy: useful, should be defined, maybe not MTI

justin: what does repair mean

varun: retransmit or fec
... process for adding new metrics ?

fluffy: should we bundle that with extensibility discusssion of media capture later this afternoon ?
... process in IETF is you can define whatever, and anyone can chose to implement or not
... so here, define, and then main doc can bring in what is deemed good

dan: difference with extensibility discussion later, is this is only data structure

fluffy: living document not ok

harald: want to avoid DOM experience with levels

fluffy: usually only adding, so new ones can go in new document

discussion to continue over lunch for those interested

WebRTC privacy - IP address leakage

<vivien> WebRTC IP Address Privacy slides from Justin

justin: slide 2

juberti: slide 3 (concerns)

juberti: slide 4 (consideration)

ekr: DHCP reliably gives you the same IP address.

juberti: there are other things that can be done here, like UA fingerprinting

ekr: agree

juberti: slide 5 (goals)

juberti: slide 6 (restricted gathering)

<ekr> Citation for TCP timestamp fingerprinting

<ekr> https://www.caida.org/publications/papers/2005/fingerprinting/KohnoBroidoClaffy05-devicefingerprinting.pdf

adamR: per address family.

martin: 1 address per family on that interface

juberti: you pick your default interface, and then gather one v4 and v6 address.

<ekr> See also: Virtual Pwned Networks

<ekr> https://www.usenix.org/system/files/conference/foci12/foci12-final8.pdf

juberti: if you connect to multiple well known addresses, this may pick different interfaces
... slide 7 (host candidates)?

<npdoty> without any user involvement?

juberti: allow host to host connections. because in some cases they expect it to work.
... slide 8 (restricted gathering)

fluffy: VPN in enterprise case?

juberti: if you bind to 0.0.0.0 address, it maps to tun0 interface instead of en0 or en1.

<npdoty> did that broken ICE host-to-host example include camera/microphone user-granted permission? or was it just displaying a video, no user involvement, in the browser and so needed to support it by default?

<dom> juberti was referring to data channel usage (so no camera permission grant involved)

fluffy: in the enterprise case it wont be a private address but an enterprise IP address.

juberti: will the VPN provide the IP address in the same space as the enterprise address?

ekr: looking at the routing tables in the VPN paper.

fluffy: what if a company had 8.8.* address, the VPN from that company might allocate in the same space.

<npdoty> it seems like there are cases where an enterprise administrator wants local rtc to work (because they installed some video appliance) and cases where an enterprise administrator doesn't need that and would prefer a little more topology/privacy protection for their users

juberti: 8.8.1.2 maybe assigned by DHCP and 8.8.2.1 maybe assigned by the VPN

fluffy: the address in the case of home is your home IP address and the VPN would be the enterprise address and not neccessarily RFC1918 address

adamR: both are possible: i.e., 1918 address and also enterprise addresses.
... does it matter?

juberti: it shouldnt matter.
... do not bother about enterprise VPN case but the privacy preserving case where the endpoint always gets a non-routable address.
... slide 9 (Consent)

ekr: if you are behind the same NAT in the VPN, then you wont be able to talk to them.

juberti: yes, not without a TURN server

fluffy: but wont this affect the enterprise case as well?

juberti: it might hairpin if they have a routable address

adamR: what are we gaining or losing by cutting out all the local ip addresses.

ekr: need cross pairing or need to be more aggressive.

adamR: if this happens frequently enough. the app developers will ask for the mic just so that they get more permissive

juberti: for those cases, we are down to the 10% of the 10% of ... so we need to measure this.

adamR: you cannot assume that there is a need for TURN and this may cause a lot hairpining in cases where it should have gone through some IP address but the default was incorrect.

fluffy: there are use-cases, like gaming where having TURN might be too high a bar to entry

ekr: what would be the concern of not sharing all the 1918 addresses?

juberti: this is more complex to explain

ekr: we have 3 options: 1) do nothing 2) do what justin suggested, and measure, 3) be more aggressive, measure, and turn off.

<npdoty> can users configure if they're expecting to reach something on the local network?

fluffy: getting default addresses in some OSes is not clear

martint: we use a well known ipaddress, for example 8.8.8.8

fluffy: there is no need for it to be routable, you are just querying your routing table.

martint: but can also use the STUN/TURN server, as they already know the client's ipaddress, which should be the same

mathieu: what is the difference between address families?

ekr: we bind to different v4/v6 address, and we just use the default addresses returned by that.

martint: so the reason I mentioned, where you have two interfaces and this might not be ideal?

ekr: that should not be a problem, because it may be revealed nonetheless
... we would like to get general consensus on which set of addresses we do need. i.e., the default addresses that we specify here should work

fluffy: in enterprise VPN might not be the default route because it might just needed the address for content inside the enterprise

adamR: if the assertion is that this is too hard to specify, I volunteer to explain this

petert: this is not just specifying but explaining that to the community

adamR: we are revealing one, more addresses should have the same properties

juberti: but this is not true

mathieu: the VPN tend to rotate the IP addresses, so these are not statically bound to an endpoint

martint: we adopt the strategy outlined here, then we measure. We should also do the 1918 addresses, then we measure. we measure the difference, and verify the fingerprinting. and then decide

fluffy: the statistical significance because the affected population is so small, it might be lost in the noise

<npdoty> does this depend a lot on the configuration of the VPN and the applications in use by a particular enterprise?

adamR: I agree that we wont know who got lost.

<npdoty> why doesn't the enterprise administrator decides what matters to them?

juberti: why dont we go out and measure. we should make sure that we observe or not observe the hypothesis
... if someone wants to make a counter proposal, I can have a look at it.

npdoty: my enterprise uses many datachannels, I tell my browsers to get all IP addresses and if not then i tell them to restrict it

ekr: we already have a filter which does pair v4 with v4 and v6 with v6. we can do pairing of private with private

shijun: we notice that most people will click the permission in the case and remember it.

juberti: the application in this case can do ICE restart. We already agreed to also do TURN first. We could do ice restart after the permission is granted

martint: this is exactly trade off we are making here.

shijun: we can from an implementation, we can gather all the candidates, and not fire the event if there is restrictions, and when permissions are granted then you can have all of the candidates.

jesup: what is the impact on warmup

juberti: we start with TURN, this might make things faster in some scenarios.

jesup: wasnt the idea of warmup that you can send data via low latency and not have to change from TURN to something better.

juberti: actually opposite is true, because in the warmup case you want to start with quick choices, then make the transition. In the case of TURN privacy case, it would be TURN nonetheless. callee privacy use-case

fluffy: you brought up ICE restart, what would be the concern

juberti: there is no concern because there is a make before break, so no problem here

baboba: TURN sets up quicker on average, our measurements show that.

jesup: my concern is what should the consent question read?

juberti: we have not found something yet.

martint: we do not have enough space to explain this. perhaps a learn more.

juberti: slide 10 (force proxy)

<npdoty> "More info" or "Learn more" could try to explain that this is revealing information about your local network, for example, if you use a VPN or certain kinds of proxies

juberti: slide 11 (proposals)
... if you have consent, you expose everything.
... if you do not have consent, make sure it works, and no VPN addresses are exposed, and not anything else. Just a single host candidate for each family
... there are additional modes, for example via extensions or user/browser prefs. In this case you do not expose host candidates
... the last case, we clamp to TCP

dom: this is not best practice but specify this as thing for everyone to do.

juberti: what ever makes sense. specify or best practice

adamR: we should still do the measurement
... i.e., differential gathering. use all 1918 addresses. Ted's variant of (2)

juberti: we can measure between 1) current default and 2) new restrictions. We do not know how much energy to implement Ted's variant of (2)

adamR: my intuition is that there would be non-trivial difference between the 3 approaches.

juberti: we need to do measurements, and then discuss before we close this matter

burn: when you mean consent, you mean gUM consent
... for example I goto netflix and they ask me for permission and I give it
... then I come to Japan, and it wont ask for permission

<npdoty> depending on whether the browser persists permission for access to your camera and microphone

martint: this is an issue with persistent permission

burn: gUM permissions is for accessing the media capture but now these consents are for transport. Want to make sure this is the case

dom: in seattle, we talked about network consent. I dont know if we are extending the consent

fluffy: the exact thing that drove this is the advertising pixel. But this is a problem with third party thing

<npdoty> that script on the NYTimes was presumably not Google or Facebook, so it's certainly still relevant

juberti: we just wanted to make sure the the NYTimes thing does not happen again

<npdoty> when I raised this comment, I was told that embedded iframes of "calltechsupport.com" would expect permission to extend

ekr: what are the properties we want here? should this be top level or not?

martint: this is not the right context to reopen an old issue. this was discussed before. this is not a bad idea.

ekr: this was proposed 4 years ago and there was push back on it

fluffy: there was a demo in france, that showed the use case for allowing this.

jan-ivar: you can bring up the permission dialog again for each I-frame.

<npdoty> from Privacy Interest Group comment earlier: "Top-level origin/embedded origin pairs, for example, might be a useful model, as in some implementations of Geolocation."

<npdoty> yes, double-keying permission

ekr: are you suggesting that they ask the permission for each I-frame

jan-ivar: well that is up to the implementation. Do not need to do that. perhaps one for facebook.com and one for the I-frames using facebook. We could have different permissions for those two cases

martint: call permissions API each time

<ekr> http://seclab.stanford.edu/websec/framebusting/framebust.pdf

martint: justin wanted the top-level to have access to the permissions.

ekr: non-safe behaviour if a random I-frame on a website accesses the camera, it would be bad to say it was the website was trying to get access

juberti: well if you are at foo.com, it would be odd to get a permission that bar.com is asking for permission

<dom> [I think the end result with that these sites will require to do camera-based avatars or something]

<npdoty> if it were a separate permission, could we explain to users what they were going to reveal?

jesup: this is going to cause data channel developers some concern, because they might want to have more IP addresses, and they will ask for media permissions. Then the users are going to be confused why the data channel apps are asking for audio/video

<dom> npdoty, when I chatted with ted hardie back in Seattle, he thought that was achievable (e.g. "do you want to share your network location with foo.com?")

juberti: we want to dissuade developers of datachannel apps to ask for media consent. There is one network interface in the restricted gathering, so that should be sufficient.

stefanh: how do we conclude this discussion?

martint: the concerns with all the local addresses needs to be done
... we should take justin's proposal and also the permission prompt for now and see what we can do with this.

juberti: we will learn from experience. and we hope to answer these questions in a relatively small amount of time

dom: how do we incorporate this in the spec.

juberti: we wrote up an I-D, is available. it can be copied into jsep or here in this draft.

<juberti> (copied into the w3c spec, jsep, or security doc)

<npdoty> dom, not that it's impossible, but that everyone is likely to be confused by it, and answer in a way that isn't necessarily tied to what they want or what is good for them

fluffy: as rtcweb chair, does it make sense that we split this into the security considersations draft, jsep and reference these in the w3c spec.

fluffy: socialize this next week at the IETF with the relavant parties

Simulcast control

Simulcast control slides aka Plan X from PeterT

simulcast fever starts now.

peter: plan X example

peter: here is how you set up a transceiver, with the mapping between the RID (see MMUSIC multicast SDP) and the corresponding resolution scales ...
... once this is done, ou create your offer, the entire JSEP dance, and if you look at your parameters after, you should see the result

shing: what happen if it gets rejected ?

peter: then you don t see it

fluffy: question to remember later

peter: if all goes well in the IETF, this is what the SDP looks like

mathieu: so the scales are not in the sip?

peter: correct, there is nothing like that in the sdp

martin: question for later

peter: there is a risk that IETF will not deliver in time, in that case, we need a contingency plan.

peter: reading the sentence about problems that can arise when you send multiple stream the remote party is not ready for.
... the idea is to SIGNAL the information (without SDP because IETF would not have deliver in time)

fluffy: intend might be misinterpreted by IETF

adam: no, we want to have a safety net if we have nothing.

adma: moreover: since you would have everything define on wire, and only the signaling is the problem, you can always polyfill

fluffy: don t you have a problem at the RTP header level

adam: no, we can have that nailed down. this is a pure signaling problem

fluffy, ok then

peter: next slide
... either way, there will be *an* api to send multiple things using the RID header extension
... there will NOT be an API for PT based simulcast
... there will NOT be any API mapping for max-width, and some other attribute
... browser may support more advanced form of simulcast, but only the RID part, with header extension will be mandatory

fluffy: i have a use case, very simple, where people use different devices, like mobile, with different form factors, and limiting ourselves to scales of 2 is problematic to say the least.

ekr: fair

peter: two things: size and aspect ratio
... you can always change the size by applying constraints on a track
... aspect ratio is more ......

fluffy: i couldn t care less how I do it, but I need to be able to specify three specific resolutions for example in JS
... through contsraints, I can only pass hints. It's surprisingly difficult to get exacting three resolutions.

adam: the JS knows the size of the track, not on the wire after it s encrypted.

all: GetSettings will show you the ACTUAL resolution (not the constraint)

mathieu: why simulcast and not streams in parallel

fluffy: we need timing information to be consistent

peter: can we go back to the example slide?

fluffy: there for example, I don't want integer numbers for the scales, and i want to be able to scale them separately, so I can change the aspect ratio.

peter: that is orthogonal to what we are doing here for simulcast, because it applies to non-simulcast cases.

adam: I would add the blacks bars at rendering time, instead of adding them before encoding, and sending them on the wire, and paying the bandwidth price.

ekr: he wants to crop on send :D

<jesup> Sending black bars is a waste of bits.... as we all know.

<juberti> Do we need this for 1.0?

fluffy: use case: full res iphone screen phone factor, low res square, we expect the square to be a crop.

ekr: I do not think we have decided on that. I assume that we never lose data, which means, we don t crop, we add black bars.

fluffy: fair enough, my use case still stands.

dan: it s a good valid use case.

ekr: if we crop, which part do we keep ?

fluffy: center

peter: left

ekr: that s a new parameter we would need to add. Cropping is not simple, and merely giving the size of the remaining window would;t be enough.
... you re not going to make a big difference by shaving bits off the thumbnail.
... we might want to do this on the big guy [high res track], that would make sense, but certainly not the low res.

fluffy: lots of people want to do simulcast by setting bitrates

peter: not shown in examples, but existing parameters can all be set here, including bandwidth

fluffy: ok, then what would be missing to achieve my use case?

peter: like what/

fluffy: what was in the RID draft
... is there anything else that anybody would have asked for. Are you confident that you are ready?

peter: some are missing here, because we set them on the track. Those are not encoding parameters, and we do not want to duplicate parameters all over the place.

fluffy: what about max pixels per second for example. That would be set per simulcast stream. How would I do that?

peter: if there is no encoding parameters, this is not the place to set them. set them on tracks
... in this case, you really can t set them.
... i propose we go with what we have, and for any new parameters we discuss about them.

shijun: also, make the scale parameter a double.

fluffy: it s a good point if I known the frame, otherwise, it does not help.

peter: i believe that back at the face 2 face, we agreed that the resolution thing was the fundamental thing for 1.0

fluffy: i do not remember that. We are where we are, now i m asking: why can t we put the bitrate here?

stefan: I came out of the f2f meeting saying: let s be practical, stop adding things, and deliver now

fluffy: this is a very concrete proposal that was around for a lot of time.
... now, I would challenge you if you were, as a chair , saying that it was the consensus of the room after seattle, that it was not the case.

peter: let s get consensus on this right now, and then we propose new things.

ekr: it seems like a fine general structure, and i m ok as long as we are not closing the discussion about what gets in for 1.0

peter: I would like to avoid dragging the discussion so long that we don't deliver.

ekr: let's validate the structure first, the content after

shijun: what s your proposal for new content )bitrate)?

stefan: at the last meeting we did say that we were drawing the line.

dom: this is indeed my remembering, we could also point to several email setting this expectation for the seattle meeting.
... i also do remember that the only question was about simulcast, and one of the condition was that it could happen in time for TPAC because we wanted to close
... i feel like I'm hearing a consensus about the structure.

fluffy: there are really two ways. I m fine with the current approach, as long as it gives us capacity to add more attribute. If that s it, then that s no tit for me.

dom: based on my raw feeling of the room, there seems to be a rough consensus about it because it s reasonable enough
... to be fair your cropping use case might not fit.

and .... peter is back

peter: minor questions slide
... 1. should the JS be able to set RID?
... 2. Should we just use RtpSender.setParameters() instead of sendEncodings()
... 3. Can a browser receive simulcast?

<npdoty> First, Do No Harm to the Internet

fluffy: just let the browser handle it, unless anybody feels strongly about it.

adam: ok guys, break is over: is anybody against browser picking it?

fluffy: bernard are you o with that? what s the status in ORTC

bernard: well, i would prefer it the JS to set it, but then, i wouldn't want to give people the tentation to write shakespeare in this field.

adam: where is the access for this?

peter: sender.setParameter(), which does not exist before you actually have a first set.

[adam: i would prefer to avoid an extra Round trip for the negotiation.

peter: ok JS picks, no more than 16 characters

martin: not unicode please

peter: A~&, 0~9, both cases

all: good

question 2

peter: 2. Should we just use RtpSender.setParameters() instead of sendEncodings()

peter: ok so let s keep what we have.
... 3. Can a browser receive simulcast?

adam: out of scope for 1.0 ?

adam: in the SFU case, the browser always gets only one stream anyway

all: even if you send several streams from media server to browser, you can consider them as separate stream.

dan: coffee disapears in 10mn

adam: it s bad coffee anyway

ekr: that answers our question

stefan: ok coffee
... when we re back, it will be user media work

stefan; [not webrtc anymore]

gUM: Results of Constraints registry vote, and implications thereof

Dom's PR #258 "Reorganize definition of constrainable properties without a registry"

dom: PR related to removal of IANA registry
... I also moved the related section of description of constraints (it was before in a sudo APPENDIX)
... mostly editorial changes

cullen: it does not quite answer the question, how does extensibility works now ?

dom: right, but not part of this PR, dan will talk about that

martin: is this plan to merge this and talk about the issues Dan will raise ?

dom: yes

martin: goal is to address the last call comment question

gUM issue 244 Extensibility

Issue #244

burn: Anssi gave 2 links as extensibility examples

burn: example of sensors API
... how you should name sub classes and so on
... we could go to this level if we want, but this seems more detailed than what we need
... currently the PR is only 3 paragraphs we could extent

Service Workers extensibility section

burn: it says this are the precise extensibility points, we need to do some of that but should be more general

martin: good to explain the structure as otherwise you will make it wrong

burn: here it is a "may"

cullen: what does the name specification mean here ?

burn: it is a good question
... (reading the proposed text in #244)

ekr: this is to distinguish new version of the spec from extension specifications ?

burn: right
... if you want to put new requirements on the core spec you will have to contact the maintainer of the core spec
... this is very generic stuff, to explain how we care about extension specs

dom: @@dom also the notion of isolated streams, so need to look if we are breaking our own rules here

martin: regarding values for attributes that probably falls to the last category

dom: default behavior for a browser that don't imple
... ment the extension is @@dom2

burn: if you add new value, the 4th bullet applies, so your document has to document expected interoperation of implementation that don't support it

martin: I suggest we remove attributes value as impossible to check

jan-ivar: this is the reason why we are using @@jiv and not DOMString

martin: issue with facing mode
... kind of OK for constraints that have a default
... eg. extending the range of an integer value would be problematic

jan-ivar: are we saying we can change anything that was written in the WebIDL ?

cullen: in W3C I think it means a W3C specification

burn: example of the depth spec, which came up from introduction of a new type besides audio and video including new attributes

cullen: I think we want to discuss mainly adding new constraints

burn: this text is because wanting to do an extension

jan-ivar: then you don't need attribute values

burn: you need it for the "kind" attribute

jan-ivar: is that a DOMString ?

burn: yes
... is your point that attributes whose values need to be extended would be on us ?

martin: my expectations was that it would be limited to constraints

dom: cases where enum was not appropriate and were we used DOMString

stefan: Nigel was not only into constraints

burn: current text was my initial thinking

martin: we can call kind explicitely

dom: the requirements imposed by WebIDL and the pros

burn: (reading definition of kind)

dom: we are saying if you are a video mediastreamtrack your kind should be video, not exaplaining what it should be for a new type of mediastream track

burn: this what I did not want to describe as we cannot predict

dom: we have a concrete to learn from, goal is to provide guidance

burn: at a minimal you need to add a new value for kind

martin: define what type it consumes and returns

dom: depth is a good example to learn from

martin: may we say 2 subs-sections if you want to define a new constraints, and if you want to define a new type of track

burn: nigel by reading the spec thought it was not possible to extend the spec
... agree with martin
... indicate the webIDL change needed

jan-ivar: I am worried we can extend any WebIDL is too broad

martin: suggestion was follow the rules WebIDL is establishing nothing more

jan-ivar: I thought we can formulate this differently

burn: imprtant to say what you are not allowed to do

martin: I think it is the most important part

cullen: it is fine but people will ignore it

dom: it is a matter of awareness and guiding

burn: then it can be done as additional guidance

dom: if you make that a requirement then you will have to indicate you have 2 implications of this requirements during CR

martin: we have unittests that cover some of this

dom: we could say "Don't be dumb, don't do harm to the Web" without saying a MUST

burn: 3rd and 4th bullets are requirements on the extension specifications

dom: you are making writers of extension spec implementors of this section

cullen: I think we are missing critical point: adding new constraints
... how to get a code point

martin: would you prefer to define what specification means here ?

<npdoty> W3C has a specific definition of "Recommendation", but I don't think it does for "specification"

dom: any other JS API have been extended either in W3C CGs or oustide of W3C
... again I think what we want is tfor additionnal constraints to be implemented, and you don't want constraints to reuse names

cullen: how do we stop name collision

dom: traditional way, eg when you had it on mozilla trunk you will get a compilation error

ekr: is a name reservation by the browsers enough ?
... if something is put on a personnal website that does not count right ?

dom: in CSS they say when something as not reach CR don't put it in the world, you use prefix when it is experimental

cullen: some devices have specific constraints that will not be reused elsewhere

<npdoty> for link relation values, we just point to a wiki

<npdoty> http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions

cullen: example of telepresence constraints

dom: you have to be careful on the name you pick so something specific to telepresence
... if cisco wants to have cooperation with other products it will have to discuss with those vendors first to have success

ekr: I thought we wanted a way to register a code point

dom: if you want interop the cost is higher
... for things you want high interoperability we can learn from what CSS has done

cullen: when we ship thing it is because it works

dom: but the question is it is inter-operable

adamR: How could we deal with two uses of unprefixed names that end up meaning different things? As an example, if one vendor decided to call something “audioOffset” that talks about the position of a microphone on a soundstage, and someone else calls something else “audioOffset” to mean a timestamp offset into an audio stream, the resulting conflict is irreconcilable.

jan-ivar: how is it different from writing a spec where I extend a partial dictionnary

ekr: because here we discuss a simple case

dom: jan-ivar says why is it a constraints on not for CSS ?

giri: I agree with jan-ivar
... for mediastram depth extension they take it to the W3C process to ensure interoperability

cullen: let's say we want to add white balance, classic on telepresence
... sure we can work with polycom, pb is that it is not an open source development
... w3c could say we assign you ZZZ
... how do you know that when you ship your product you are not going to get screwed ?

jan-ivar: isn't the screen sharing implementations of chrome and firefox implementing different specs

giri: @@giri

burn: you have said we don't need a registry can you explain more

martin: it is an authority issue, who as controle here W3C or ... ?
... for white balance we did not say no but not now

cullen: that was 4 years ago

ekr: the guarantee you want is to have a code point reservation
... what is the bar to reach that ?

martin: we talked about github repo, cg, bringing stuff to this group, ...

dom: my thinking was that people using a prefix for things that don't hit the wide web

dom: -cisco-foo

martin: 'x-'

ekr: @@ekr2

npdoty: HTML had this pb for link relations, they were first using IANA and found the process to heavy, so they went to a simple wiki

dom: link rel don't have interoperable issues so a different problem

ekr: @@@ekr3

martin: the pb is the discoverabilty of others people names
... can be as simple as a web search

cullen: I was not successful doing that in the past

vivien: here we are talking about referencing a wiki page, this is similar to a registry and we voted not
... so anyone is free to create that wiki page

stefan: it will simply not be referenced from the spec

<npdoty> HTML5 describes how to add a link type here: http://www.w3.org/TR/html5/links.html#other-link-types

cullen: does the W3C would commit to not using names from that list ?

jan-ivar: that sounds like a registry

ekr: CR does, what else does ?

cullen: I am going to implement this extension and want to make sure to reserve it to not have a conflict

<npdoty> wikis are a good way to prevent accidental overlap. almost nothing can prevent intentional conflicts

ekr: @@@ekr4

<vivien> ekr, can you write down what you are saying, you are talking way fatser than by yping or even my brain

martin: I think cullen pb is ensure that the community knows aboiut cullen we don't want to block all use cases

cullen: @@cullen3

nick: as a process manner it is difficult for the W3C to constraints other developments

martin: we could say if people are aware of usage of some names then they should not reuse names

<fluffy> Key thig is this community (the WG) agrees that if someone comes and gets a code point for a constraint in a given way, then this standards orgnaiaiton is not going to stomp on it

ekr: reserving a code point require a W3C REC high cost, or a W3C CG

cullen: you need to inform people

ekr: can people notify public-webrtc list ?

cullen: sure

martin: sounds good

nick: you can't have commitment from the entire consortium unless you go in front the AC

martin: we would write it in the right way

stefan: sounds we have rough consensus, now how do we move forward

martin: I suggest dan write a first version adding guidance on notifying the WG for new extensions

stefan: ok we have a plan

gUM status of Last Call Comments

stefan: we had 19 comments after the deadline, now done to 1
... last one from justin, which should be resolved when we merge dom's PR

martin: ok done !

burn: we can wait till we merge the PR than answer and close this

stefan: after that we had comments coming after that

mathieucitrix: isn't there some ongoing privacy issues ?

burn: yes with nick
... should we create issue based on nick's email ?

stefan: I have not read the full thread but we discussed part of this today with the iframe issue

nick: I don't see some of the reported issues

<ekr> https://github.com/w3c/mediacapture-main/issues/244#issuecomment-152111790

stefan: we ask people to send them as github issues

burn: yes usually we let the discussion happen then the chairs ask the reporter to fill an issue

stefan: will you file an issue(s) ?

nick: there are sperate issues in that thread, do you want me to fill multiple ones ?

stefan: yes

martin: this ensure we don't miss anything

<npdoty> ekr is always awake enough to discuss security, it sounds like

<scribe> ACTION: npdoty to fill in github the various privacy issues he reported [recorded in http://www.w3.org/2015/10/28-webrtc-minutes.html#action01]

<trackbot> Error finding 'npdoty'. You can review and register nicknames at <http://www.w3.org/2011/04/webrtc/track/users>.

nick: most important 1) iframe 2) programmatic way for sites to revoke permission or for site to indicate a permission should not be persistent
... ekr I understand you discussed that previously my alternative where: say this is one time only, and possibility to revoke a persistent permission

shinjun: regarding the iframe, if the domain is the same as the parent page, this is something to think about

nick: sounds like the chrome implementation is fine

martin: this is what I proposed
... (looking at options outlined in issue #267)

ekr: 4. is not a pain to implement for us

cullen: one use case is call centers

ekr: yes you might only use the service once or twice a year

mathieucitrix: yes the user would expect this

cullen: I think 4. is the most realistic

martin: I'm with you fluffy

ekr: the browser would decide

mathieucitrix: no because my application would work differently on different browsers
... for me option 6. is a no go
... I would prefer not 6. for the reason expalined by fluffy and mathieucitrix

ekr: I don't see a lot of value for sites to be able to revoke permissions

nick: the use case is if you are worried for the privacy of your users
... if it is uncommon but helps a lot of users (eg used by gravatar) it is great

dom: it is fair to say if chrome did not have the defaults to persist permission on https, we would not have that conversation

<ekr> "The API MUST provide a mechanism for the requesting

<ekr> JS to indicate which of these forms of permissions it is

<ekr> requesting. This allows the browser client to know what sort of

<ekr> user interface experience to provide to the user, including what

<ekr> permissions to request from the user and hence what to enforce

<ekr> later. For instance, browsers might display a non-invasive door

<ekr> hanger ("some features of this site may not work..." when asking

<ekr> for long-term permissions) but a more invasive UI ("here is your

<ekr> own video") for single-call permissions. The API MAY grant weaker

<ekr> permissions than the JS asked for if the user chooses to authorize

<ekr> only those permissions, but if it intends to grant stronger ones

<ekr> it SHOULD display the appropriate UI for those permissions and

<ekr> "

ekr: I pasted what is the requirement in the specification

varun: if you relaod the page will it ask again ?

ekr: firefox does, chrome doesn't

<npdoty> my only new information is the suggestions of alternative API designs: oneTimeOnly=true, or a revoke() method

dom: I think the firefox model is better here, it is better for privacy

martin: google folks are well aware it is a point of differenciation between browsers

mathieucitrix: we are not removing this from browsers just letting application developpers chose

martin: if the option changes it would be confusing to the user
... browser developers are very sensitive in trying to protect their users

<ekr> Thread starts here: https://lists.w3.org/Archives/Public/public-media-capture/2015Mar/0001.html

nick: when I raised the issue it was more that some site developers might feel in an uncomfortable situation if the permission is being persisted
... sites might know things that you don't
... I am providing suggestion to the group

(firefox team looking over at clear site data spec)

cullen: maybe revoke is one form for this
... if their is a revoke in the permissions API we can rely on that too but too me it feels like a bad idea

dom: so if gUM permissions belongs to the Permissions API this solve the discussion
... they do have a revoke API

ekr: if revoke is a good idea...

dom: the logout use case sounds good
... how do we proceed are we exploring the Permissions API approach ?

martin: I don't think we reached consensus on @@mt1
... for revoke we can follow webapps work so if they think it is a good idea

dom: nick you that satisfy your comment ?

nick: @@npdoty
... it will be hard to get the group satisfied if your answer is maybe it would be handled by the webapps group

stefan: sounds like a good answer if we leave that to the experts

WebRTC TPAC 2015 F2F Day 1

Thursday 29 Oct 2015

Attendees

Contents