Web Real-Time Communications Working Group Teleconference

30 Oct 2012

See also: IRC log


andy_hutton, adambe, hta, stefanh, derf, burn, dan_druta, richt, anant, dom, juberti, jim, matthew, ekr, fluffy, Magnus, Vidhya
Harald, Stefan
DanD, Juberti


<trackbot> Date: 30 October 2012


<dom> ScribeNick: DanD

ekr presenting http://www.w3.org/2011/04/webrtc/wiki/images/f/f2/Idp-issues.pdf

ekr: Three proposals on the list
... Proposal 1 - Identity provided by gUM (Thomson)
... Proposal 2: Prompt user after call (Ohlsson)
... Proposal 3 - Site permissions with identity display (EKR)
... Proposals 1 and 2 require the user to explicitly assent to identity

fluffy: How does the person answering the call who's calling before answering the call?

ekr: Long term consent

Mathew: I like to setup the video selection and enable the camera and the identity makes it complicated
... easy to be done with proposal 1
... We need to make sure the browser does not get into the address book without user's consent

hta: I'm not happy with proposal 2
... when the green light go on
... I have an origin that is not bound to an identity but later get's bound

ekr: Proposal 4 is a hybrid of 1 and 3

dom: I don't think we should use a null value for a parameter with a different meaning as a parameter not being set

ekr: I'm happy to use a different parameter name for option3

justin: There's a difference between site having access to the camera and site recording

dom: We're focusing too much on the green light where mobile devices don't have a green light; I want to make sure we don't build security on top of hardware indicators that are not always available

martin: the idea is to have an indicator in the chrome

justin: there's confusion about what the green light means

fluffy: we are adding to the confusion

ekr: the green light (the indicator) is supposed to be on once the camera is accessed

hta: there is a issue when applications via USB can access the green light

martin: if it's on can drain battery without sending any data

fluffy: expectation is that when camera goes on light goes on

ekr: going over the proposed rule

dom: I'm a little bit confused. if the indicator is in the chrome I won't see it if I switch to a different app (on a mobile phone); how does that affect the reliability of granting access to a camera to a peer

ekr: we should

Mathew: will we be able to check for long term permissions?
... action on ekr to write something up on tainted streams

hta: suggest camera access as a topic for the other issues later today

API for removing streams

hta: presenting what "remove" means

fluffy: we should not look at index

hta: either we don't remove the streams and you have a fixed index

adam: if we reference it by object even if it's removed from the array I can still find it by object reference

dom: this is what DOM is doing

hta: in this proposal I have two methods to access: one by returning all and iterate another one by name

fluffy: why are we handing developers indexes when they can get them by name

dom: using index is not a bad thing as long as you don't assume that what it refers to is immutable

adam: I don't think you want to have the sequence because developer can store the sequence and can change later
... the msid draft has already a proposal how to name things

hta: we need to decide if we want to get rid of the indexes and go with the labels

Mathew: legacy devices might not label

Adam: we should go with ID's for both streams and tracks

hta: we need somebody to write a proposal

<martin> there seemed to be general agreement with Adam's suggestion, namely assigning ids to every stream and track and having label used only for human-readable text

<dom> ACTION: Adam to update APIs to use mutable arrays of streams in peerconnection with ids [recorded in http://www.w3.org/2012/10/30-webrtc-minutes.html#action01]

<trackbot> Created ACTION-59 - Update APIs to use mutable arrays of streams in peerconnection with ids [on Adam Bergkvist - due 2012-11-06].


hta: presenting API requirements

hta: proposal to have two new functions on RTCPeerConnection

justin: I like the idea of having the callback with tone and duration

Martin: the proposal was to have a track (something that looks like a track)

hta: what's the factory for that track?

Martin: you construct it

hta: now you need to the go from the track to the peerConnection

Martin: you get the track from getUserMedia, you decorate it for DTMF and attach to the peerConnection
... on the receiving end it's simple

hta: If I would be to implement where do I reliably place this?

Fluffy: How do you know to negociate for DTMF?
... another one is long tones use cases

justin: you can emulate this with the proposal

fluffy: I"m fine with getting rid of the long tones

Stefanh: I like the proposal. I'd like more control on the outgoing part

burn: I think you can have the DTMF track be created by the peerConnection

justin: I support hta's proposal

hta: I'll modify the proposal to incorporate burn's suggestion

Other business

hta: reviewing the collected items for discussion

What Triggers Candidate Fetching

Mathew: Use case is when a web page displays "call agent" . I don't want all the visitors of the page to use my turn servers

ekr: This should not be a problem

hta: I don't understand why the use case is not satisfied

Martin: you want to load the page and show as quickly as possible

justin: we have two mechanisms to control the candidates gathering
... you can do that now

Martin: this brings us to changing constraints on the fly

fluffy: we want to preallocate now were' talking about how to do it in the API design

justin: you would know what you need if you call setLocal

fluffy: you can optimistically assume two

Mathew: you got two use cases: the conference model where you call in to a conference or the public page. We need to support both efficiently

fluffy: can we try to make a proposal
... it's less elegant but should work

justin: we can do this using setLocal

fluffy: I have a different proposal. Have a constraint that defines the preallocated streams

ekr: it's fine for me

hta: is this sort of creating a pool?

fluffy: yes

<martin> proposal is to add a new constraint preallocateCandidates, which takes an integer value that defaults to zero. setting this to any other value through the constructor or updateIce triggers the filling of a candidate set pool of that size. final actions are taken on setLocalDescription

hta: decision to go with the proposal to create a pool

<martin> cullen will take an action to follow up on the last issue (see my last item starting with "proposal")

When is SDP sendable?

<juberti> Next topic: when is SDP sendable

<juberti> When do we know if we have all streams?

<martin> my proposal for this was that the success callback would fire, at which time the array^Wcollection would include all the streams

cullen: this doesn't let you know whether a stream was added or removed.

matthew: that doesn't work in all cases anyway; imagine calling setRemoteDescription twice, the second time before all callbacks have been received.

cullen: on all functions that have callbacks, you can't call the function again before the callbacks have dispatched.

juberti: this would be setLocal, setRemote, createOffer, createAnswer.

ekr: what about getUserMedia?

… should be possible to ask for multiple cameras.

juberti: I have a proposal to handle the getUserMedia case.

adambe: what about onaddtrack events?

adambe: do we need onaddtrack when a stream is added?

cullen: I read the spec, I think it says any time the remote side adds a track, you need a callback.

adambe: there's also an onunmute event on tracks too.

adambe: how about only onaddtrack only when a stream is updated, as opposed to added/removed?

juberti: I like that proposal.

cullen: I don't.

martin: Let's address the stream callbacks first.

hta: Let's do that.

martin: setLocal, setRemote, createOffer, createAnswer should all be non-reentrant.

<fluffy> proposal is that that the createOffer / createAnser, setLocal, setRemote, you can not call the same function again if the callback from a previous invocation has not returned

martin: during time between setRemote and callback, exceptions should occur on any of these 4 APIs.

martin: when you call setRemote, stuff will happen, but the browser will return to stable state multiple times.

<fluffy> On set remote, you install all the stuff, then does does callback for onaddstream for each stream, then does callback with null to on add stream, then it call the success callback for set remote

dom: do any other APIs do this?

anant: in XHR, some things are disallowed while it is running.

martin: during state transitions, no other transitions are allowed.

anant: you can't call open on the same XHR twice.

stefan: might this introduce a timing problem? some browsers are slower than others?

dom: I don't think so

cullen: I would guess that this is an atomic change, and it takes some time - I would look at some API that has similar needs

dom: maybe IndexedDB

jimbarnett: call should block instead of throwing exception

adambe: if you get onrenegotiationneeded, that could cause a problem

cullen: onrenegotiationneeded fires after the success/error callback, if needed.

martin: queuing of calls could work OK.

cullen: one lock across all 4 APIs.

<timpanton> The way most UI APIs deal with this is to say that those functions can only be called on the 'main' thread

hta: proposal is: when calling one of these APIs - check args, throw exception if needed, check lock, do work or queue task if needed.

<timpanton> if the callback is also invoked on the same thread, this makes the thing queue naturally.

hta: nobody argued for throwing an exception instead of queueing.

hta: anant to write up the details here.

<dom> ACTION: Anant to write up queuing mechanism for set{Remote,Local}Description, create{Offer,Answer} [recorded in http://www.w3.org/2012/10/30-webrtc-minutes.html#action02]

<trackbot> Created ACTION-60 - Write up queuing mechanism for set{Remote,Local}Description, create{Offer,Answer} [on Anant Narayanan - due 2012-11-06].

<martin> callbacks have to be called on the same thread, there is only one thread

juberti: when does onaddstream fire?

<timpanton> So how could you get re-entrancy ?

hta: onaddstream fires after installation is complete, but before the success callback has been dispatched.

<martin> re-entrancy applies only in the sense that the actions associated with the methods take time and so could (conceivably, without these measures) operate in parallel

burn: no add stream for failures, naturally

<martin> the actions occur on browser-internal threads or "in the network"

<timpanton> ok. got it.

juberti: when is pc.remoteStreams updated?

adambe: before the first onaddstream callback is fired, remoteStreams will be fully up to date with the changes.

derf:<same thing>

cullen: stream names are confusing.

derf: event callbacks need to change to be less confusing.

<dom> ACTION: Timothy to write up proposal for new stream event names. [recorded in http://www.w3.org/2012/10/30-webrtc-minutes.html#action05]

matthew: if SessionDescription is 3264 SDP, that SDP must always be 3264-compliant.

cullen: if you can't do local candidates, we should return an error when trying to write SDP.

matthew: will trickle update 3264?

cullen: I think we'll need to.

matthew: if we're doing trickle, we're going to need to update something.

matthew: how do we generate workable SDP when trickling?

matthew: Chrome currently generates broken SDP?

matthew: How do I get valid SDP in the non-trickle case?

cullen: wait for ICE complete callback, then SDP will be fully filled-in.

matthew: but what about the initial setLocal? That SDP isn't fully valid.

juberti: That is just a subset of the trickle case.

matthew: But the SDP still isn't valid.

juberti: We are going to solve this with the trickle ICE I-D.

… and then the rest of the stuff should fall into place. You can call setLocal with an initial "no candidates" SDP, and then gathering commences.

hta: we'll refer this to the IETF rtcweb WG to figure this out, and then we can resume this discussion.

Security for QoS labels

matthew: Want to see API where packet priorities can be set.

hta: culler's proposal does this - gives 3 levels of priorities.

cullen: API that provides 3, 4, etc levels

matthew: I don't know which one is more important.

matthew: data could be above or below media (gaming, higher, file transfer, lower)

dand: where would this priority be set from an API perspective

stefan: on a track or datachannel.

<dom> there was a (currently abandonned) proposal for setPriority on XHR that also had 4 levels FWIW http://ajaxian.com/archives/xmlhttprequest-priority-proposal

matthew: someone needs to write up a proposal for where these things go.

hta: set at initialization, or during the call?

matthew: I think it could be initialization.

dand: once we get this request, we need a confirmation from the browser that it tried to accomplish this.

martin: why?

dand: this request can be fulfilled by going to a policy server.

matthew: I don't care about marking, I just care about the congestion control prioritization

matthew: not all packets will be labeled the same way

matthew: either for different streams, or different packets in the same stram

hta: need to set priority levels, and have it per track, and have 3 or 4 levels.

hta: this will set congestion control/queuing in the browser, and setting of QoS is something for further study

matthew: cullen has already written a draft

goran: cullen's draft refers to other drafts

cullen: we will remove that reference.

cullen: we don't want JS to set the diffserv code points, but we do want it to be able to discover them.

hta: want mapping from track to 6-tuple?

Action. stefanh to propose priority API.

<juberti> ACTION: stefanh to propose priority API. [recorded in http://www.w3.org/2012/10/30-webrtc-minutes.html#action07]

<trackbot> Created ACTION-62

Adjourning for lunch.

Summary of Action Items

[NEW] ACTION: Adam to update APIs to use mutable arrays of streams in peerconnection with ids [recorded in http://www.w3.org/2012/10/30-webrtc-minutes.html#action01]
[NEW] ACTION: Anant to write up queuing mechanism for set{Remote,Local}Description, create{Offer,Answer} [recorded in http://www.w3.org/2012/10/30-webrtc-minutes.html#action02]
[NEW] ACTION: stefanh to propose priority API. [recorded in http://www.w3.org/2012/10/30-webrtc-minutes.html#action07]
[NEW] ACTION: Timothy to write up proposal for new stream event names. [recorded in http://www.w3.org/2012/10/30-webrtc-minutes.html#action05]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.137 (CVS log)
$Date: 2012/11/15 14:23:26 $