See also: IRC log
<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
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
hta: reviewing the collected items for discussion
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")
<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.
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.