WebRTC Working Group TPAC F2F

12 Nov 2013


See also: IRC log


In Shenzhen: Adambe, StefanH, Dan_Burnett, Alexandre_G, Stephane, Jerome, Sylvia, DanD, AndyF
In Seattle: HTA, Cullen, EKR, Jesup, Derf, Justin, AdamR, MartinT, RBarnes
On the phone: Jim_Barnett, JIB
stefanh, hta
juberti, fluffy, dom, hta


<stefanh> Agenda draft http://www.w3.org/2011/04/webrtc/wiki/November_11_-_November_12_2013#Tuesday

<hta> scribenick:juberti

<burn> http://lists.w3.org/Archives/Public/public-webrtc/2013Nov/0005.html

<jesup> My email message about the DataChannel stuff: http://www.w3.org/mid/5281767C.7010101@jesup.org

<dom> "createDataChannel(), section 5.1.2"

burn: invalidStateError for closed(), as for other methods
... what should limits on max retransmits be?

ekr: doesn't SCTP have some built-in smaller limit

martin: any positive number is fine

ekr: limit numbers can only shrink implementation limits, not increase. impl not required to do anything more.

<ekr> ACTION: adambe to modify the maxRetransmitTime and maxRetransmits text to say that the max values do not require the implementation to go over its internal builtins [recorded in http://www.w3.org/2013/11/12-webrtc-minutes.html#action01]

<trackbot> Created ACTION-98 - Modify the maxretransmittime and maxretransmits text to say that the max values do not require the implementation to go over its internal builtins [on Adam Bergkvist - due 2013-11-19].

juberti: what should app do if it wants the defaults?

jesup: set the channel as reliable?
... app developer does nothing

the default is reliable.

martin: can't set max retransmits and max retransmit time.

results in a syntaxerror, is this correct?

burn: yes

juberti: if you want unreliable, set maxretransmits to zero

jesup: yes. and if you want something else, you can set that directly.

ekr: how do you tell if the sctp channel drops out?
... how do you know sctp stack gave up on sending?

martin: let me check.

<ekr> action martin to determine whether there is some value of maxRetransmits that is effectively "reliable"

<trackbot> Created ACTION-99 - Determine whether there is some value of maxretransmits that is effectively "reliable" [on Martin Thomson - due 2013-11-19].

martin: <looking at SCTP spec to understand what SCTP does here>

derf: there are some max retransmit limits in SCTP

moving on

burn: if protocol attribute isn't right, throw syntaxerror and bail out. Is this detailed enough?

adambe: this is trying to be like websockets

jesup: we just updated the ietf specs to include the IANA registry for these things

burn: what should happen if you set the wrong protocol?

jesup: nothing is being done with this value except being passed through to the other side

juberti: so what validation will the webrtc impl do?

jesup: none, really, aside from checking DOMString

hta: is this utf-8, or utf-16?

jesup: there are no requirements.

<martin_> RFC 4960 defines limits to the number of retransmissions. This would correspond to the limits that the implementation provides on retransmission. This would produce a practical upper limit in the number of retransmissions. Two values are recommended: 5 for the path, 10 for the association. Since we have only a single path, the former (5) would apply by default. http://tools.ietf.org/html/rfc4960#section-15

cullen: is this utf-8, or a bag of bits?

jesup: foobar is an acceptable


<martin_> I am going to recommend that this be left to implementations. If they want to be super-reliable, then they can set higher values for Path.Max.Retrans, but there is no obligation to support a specific minimum.

cullen: since there is no practical checking, we should just remove this text.

burn: if id is already taken, throw exception and bail out
... this only happens for a non-negotiated channel, or reusing an id from an already negotiated channel

jesup: agree

martin: invalid-state error?

<dom> http://www.w3.org/TR/dom/#error-names-0

hta: invalid-state already exists; channel is in invalid state
... resource-in-use seems pretty good

jesup: agree

<martin_> BTW, SyntaxError is totally inappropriate for what was described. It talks specifically about strings.

juberti: this means we need to revisit maxretransmittime, maxretransmits

martin: could be not-supported errors
... leaving this open to editorial discussion

<martin_> It's the chicken's way out

burn: tentatively not-supported
... moving on, section 5.2
... what should happen if we get a channel open request from the other side and a failure occurs?

jesup: i don't see any need for that

<martin_> BTW, the quoted text doesn't read very well here.

<dom> "NetworkError" seems to be the right one for this case

jesup: dtls could go down, sctp could go down,
... but app couldn't do much about this

juberti: would this trigger on ICE failure?
... no, because ICE could be restarted by app

martin: that makes sense; DTLS or SCTP error would propagate upwards and result in this

<dom> re binaryType, the Web Sockets spec has switched to an enum for it, which we should probably do as well; in case, invalid values will raise TypeError

jesup: agreement on "NetworkError" for this case

burn: 5.2.1 - binaryType

jesup: should be like websockets

dom: websockets now uses enum; we should do the same and get error handling for free from WebIDL

<dom> Web Sockets Editors draft uses enum

not sure i got that right

burn: websockets uses enums, checking will automatically be done for us. agreed.
... protocol attrib. 5.2.1.

jesup: as previously discussed.
... i.e. no checking needed.

burn: send, section 5.2.2.
... send might not work if channel was created by remote peer in negotiated form.

jesup: to receive data on a negotiated channel, both sides need to install a negotiated channel

martin: not sure about that
... we'll figure it out

burn: if channel is still 'connecting', throw invalid state and fail

jesup: do you need to wait for onopen?
... that's what websockets does

juberti: wouldn't we want to do the same

burn: keep the way it is then?

room: yes

burn: attempts to send when buffer is full should lead to close with error

jesup: that's copied from websockets

<martin_> It's NetworkError

martin: text needs to be revised

<martin_> The conclusion was to remove the e.g

burn: can someone please summarize what

<martin_> If the data can't be sent, NetworkError and close the channel.

burn: when does error occur?

<martin_> errors need to be reported asynchronously from send()

<martin_> NetworkError event that is

martin: from onerror on datachannel

<dom> use "fire an error event", as is done in websockets

pthatcher: is there a state transition on the data channel?

juberti: do we get an onerror and a statechange callback

martin: let's have a look

<martin_> ACTION: adambe to clarify whether RTCdatachannel close and error events are mutually exclusive or whether error + close is possible [recorded in http://www.w3.org/2013/11/12-webrtc-minutes.html#action02]

<trackbot> Created ACTION-100 - Clarify whether rtcdatachannel close and error events are mutually exclusive or whether error + close is possible [on Adam Bergkvist - due 2013-11-19].

juberti: error type is NetworkError in onerror

room: agreed

burn: createDTMFSender, 6.1.1
... if track argument isn't in RTCPeerConnection's localstreams, throw invalidMediaStreamTrackError

<martin_> hta: that should be an invalidargumenterror exception, if there is such a thing

<dom> "InvalidAccessError"

<dom> "The object does not support the operation or argument. "

<martin_> adambe: "InvalidAccessError"

cullen: what about "invalidparametererror"?

martin: there is none

hta: let's add one

burn: let's propose this to the DOM folks. adambe to handle this.
... insert DTMF, section 6.2.2
... error for things outside of configured ranges

cullen: may I suggest, invalidparametererror

<martin_> http://lists.w3.org/Archives/Public/public-webrtc/2013Nov/0005.html

juberti: what should happen if the other side doesn't support dtmf?

actually, that is indicated in the .canInsertDTMF property

<dom> Vibration API truncates too long patterns

burn: throw notsupported

cullen: that seems weird - should it be invalid parameter?

burn: glad we are reviewing all of these. this is really iuseful

juberti: but our thinking seems to be evolving, so we may need to revisit our earlier choices

<dom> (I'm still not sure what the benefit is to throw instead of just clamping the values)

burn: yeah, agreed

<jib> For illegal values, can't we use SyntaxError here? It is a string after all

burn: back to these choices

jib, i think some of these values aren't strings.

<jib> insertDTMF() takes a string, no?

hta: no-dtmf-support is corner case, shouldn't result in an error

jib - duration isn't a string

burn: values outside allowed ranges leads to not-supported exception

dom: what do we get by throwing an exception?

<dom> NotSupportedError is "The operation is not supported. "

<scribe> ACTION: burn to talk to dom about whether we should clamp or throw exception for invalid params to insertDTMF. [recorded in http://www.w3.org/2013/11/12-webrtc-minutes.html#action03]

<trackbot> Created ACTION-101 - Talk to dom about whether we should clamp or throw exception for invalid params to insertdtmf. [on Daniel Burnett - due 2013-11-19].

<jib> How about: sender.insertDTMF("215-x"); -> SyntaxError (in string), and sender.insertDTMF("123", -1); -> NotSupportedError ?

juberti: createDTMFSender fails if other side doesn't support DTMF.

<martin_> jib, I think that sounds perfectly reasonable

<martin_> though InvalidAccessError seems more in fitting with the descriptions

juberti: if that goes away in mid-call, canSendDTMF reports that value, but there is no exception thrown.

<martin_> for the latter (-1 intertone gap)

<dom> NotSupportedError seems appropriate (the insertDTMF operation is not supported)

juberti: hta says this is a corner case.
... forget everything i said before.
... new agreement: createDTMFSender doesn't do any checking on remote DTMF capability.
... insertDTMF _does_ check remote DTMF support, and that the MST is still valid, and the parameters are good.

<rbarnes> where are we in the agenda?

if any are not good, throw not-supported exception.

juberti: so everything results in an exception, except for the edge case of remote side supports X-Y, and we send a Z.

cullen: we should say anything less than 0-9, *, # should be treated as no DTMF support

burn: stats model, 7.1.
... what should happen if you call getStats with an invalid selector (currently only MSTs are valid as selector)

hta: invalidargumentexception

burn: list of supported values is indicated by the enumerated type. see webidl
... delete note in the spec about other selectors
... getstats, 7.2.1

hta: getStats shouldn't throw if we call it after close().

cullen: we should have an explicit note in the spec about this.

jan-ivar: should close() also be valid here?

ekr: yes, idempotent.

<martin_> If we're overriding general guidance, we should always have a note, so close() should have some specific text too.

<dom> the notion of "invalid selector" is not defined

<dom> it should at least be clarified here what we mean

ekr: prologue about invalid states is gross, we should have a general guidance and then list exceptions, instead of doing this on a method by method basis

burn: i prefer everything being explicit, easier for the developer

<ekr> it's not easier for the developer

<ekr> issue: should we refactor the generic guidance on error handling out of the spec

<trackbot> Created ISSUE-3 - Should we refactor the generic guidance on error handling out of the spec. Please complete additional details at <http://www.w3.org/2011/04/webrtc/track/issues/3/edit>.

burn: let's discuss this later

stefanh: use invalidparameter/illegalargument for getStats with invalid selector

hta: agreed

burn: RTCStats dictionary, 7.5

<ekr> https://www.w3.org/2011/04/webrtc/track/issues/3

martin: The text is correct.

burn: What should the app do?

martin: It should ignore any unknown values. Just like any other dictionary.

<martin_> if (isUnknown(stats)) { window.close(); }

<dom> "MUST" is not appropriate here; MUST in this spec should only apply to things relevant to User Agents, not to applications

while (isUnknown(stats)) { alert("not known!"); }

<dom> +1

juberti: move to skip identity discussion, since we don't have a working impl yet

ekr: let's not use that as an excuse to dump identity because we don't have as spec.
... we have identity later.

hta: let's move on

juberti: moving on to unannounced ssrc handling

hta: a=msid identifies streams/tracks consistently.
... what about non-webrtc endpoints, which don't send a=msid?
... they still expect sync/grouping
... behavior needs to be predictable

predictable = media plays out when it arrives.

and media with a single CNAME should be synchronized (not 100% clear, see LS)

proposals for handling: all incoming media in one MS, each in its own MS, group in MS based on CNAME

cullen: what do you get if you get multiple SSRCs?

hta: multiple tracks.
... cname identifies sync context; exact language in 3550 is iffy
... same JS should result in same CNAME
... moving track from one stream to another when there are different CNAMEs is hard

martin: 2 streams - one with A and B, one with B and C - do they have same CNAMEs
... jonathan means they have clocks that advance at same rate

cullen: lipsync existed long before LS was invented

<burn> For the minutes, I believe this topic of interoperability with non-WebRTC endpoints is out of scope for this group.

I think we need to know what happens at the API level

<burn> juberti, what happens at the API level is that you talk to a WebRTC endpoint. The other side has to implement the APIs as described.

So we make msid as mandatory to use?

<burn> Once the scope includes non-WebRTC there is no longer any natural boundary for the scope.

<ekr> burn, uh, it's toally news to me that interop isn't important

<ekr> or ins cope

<ekr> in scope

<dom> ekr, the question burn is raising is on interop with legacy devices (rather than with other browsers)

<ekr> dom, yes, I understand that. I totally disagree that it's not in scope

hta: we don't know where to stick a new track without its CNAME. ANd we don't have CNAME in SDP always.

cullen: can we move a MST to another MS when RTCP arrives?

ekr: yuck

<dom> (I guess there is a question of whether there is a need for interoperable behavior in this space or it can be left to implementors to determine the best course of action)

<ekr> dom, yes, I don't think that's acceptbale

hta: we need to either stuff in default group, or in its own

<burn> I don't want to see API changes just for non-WebRTC endpoints, because, again, there is no limit to the scope of changes that might be necessary.

hta: if we like what's in the document, we're finished.

<ekr> burn, well we've already agreed to a bunch of such changes, such as for bundle-only

(which is one MST per MS)

pthatcher: we can expose CNAME and then let app group as needed

<burn> ekr, that's not true. BUNDLE is not about legacy interop. It is very specifically about efficient firewall traversal which is directly relevant for WebRTC only communications

<ekr> burn, I said "bundle only"

jesup: so this will be the case for a single audio and video stream?
... app developer probably won't be expecting this

cullen: it's not clear how you move this stuff around, the default should be a single MS

juberti: agree
... do we really need an API for this?

<burn> Record this for posterity -- we will regret this scope creep. I will attempt to refrain from saying "I told you so" a year from now.

<dom> no you won't, burn

juberti: I think we should stuff everything into a single MS

<burn> dom, :)

juberti: unless you set a=msid.

martin: the browser won't sync things that are totally out of sync anyway.

hta: suggestion is that all un-MSIDed SSRCS create tracks in a single default MSID

cullen: is CNAME part of stats?

juberti: not currently

hta: that is the full proposal.

cullen: is there a real problem with adding a CNAME property>
... what does a gateway need to do?

juberti: add 2 MSIDs: ms1 t1, and ms1 t2 or ms2 t1

cullen: how do you demux without the a=ssrc values?

juberti: you're not BUNDLing, because legacy, so you can demux by 5-tuple

adam: what happens if you get an invalid a=msid line

hta: then you have an illegal SDP
... what should you do with an illegal SDP?
... and there is a line needed for msid-semantic WMS.

<ekr> juberti: will this show up on the screen?

<ekr> or maybe hta:

<ekr> I am now in complete control of hta's screen

pthatcher: should there be a default MSID?

<martin_> martin: generate a default msid and it's all good

martin: no, generate one.

ekr: should be cryptographically random

juberti: and we're done.

<martin_> yeah, 500bits of entropy

juberti: new topic: data channel

jesup: new drafts, etc, etc
... open issue from IETF: max msg size

data channel

jesup: various proposals to set max msg size
... would prefer to stay with something like websockets
... where there is no specified max
... websockets has no streaming interface. you get a blob that plops out.

cullen: how should file transfer stuff work then?

ekr: i can figure out how to chew up memory and cpu in js in other ways no problem.

dom - we reconnected to the room


jesup: as long as you don't run out of RAM, you should be able to send.

cullen: how do i write code to this.

jesup: get blob from user, send blob. comes out the other end as a blob. done.

cullen: how does this work on a 2 GB video file.

jesup: works if you have enough RAM.
... i don't recommend this except for simple cases. real apps should do chunking.

cullen: i'd like some certain minimum blob size that would work.

ekr: i don't care what the number is. I just want feedback.

jesup: firefox supports sending 2 GB chunks in websockets.

pthatcher: any real app is going to use chunks. for a progress bar.

<ekr> pthatcher, i don't disagree

<ekr> but that doesn't mean we shouldn't have tood API semantics

juberti: can we defer this? seems like a big hairy issue

ekr: we agreed to defer it in IETF to here

juberti: so this overall API seems non-ideal. i want a real streams interface

jesup: so you could take that to W3C and solve this for Websockets and datachannels

ekr: websockets is mainly a replacement for comet, so this issue isn't as critical there.

harald, can you dial Zakim?

ekr: if you try to send too much, you get "data channel is now dead"

<ekr> though perhaps juberti feels the same way

yeah, lost the plot there

jesup: if receiving side gets a too big message, it will fire onerror with data-too-large

juberti: does this teardown and propagate to sender?

someone: no, just for the individual packet

jesup: app can discuss over the channel to figure out how to get back on track

cullen: example: any packet < 10 KB, must be delivered

juberti: 64 KB

<ekr> ekr: 640kb should be enough

juberti: probably not reasonable to expect that any size thing can be sent
... should have some minimum, but implementations can impose a maximum

jesup: we're going to be intentionally diverging from websockets.

jesup: and we need some way to communicate "closed with error" back to the other side

<martin_> issue: requiring that negotiated channels be created on the receiver before any data can be received is problematic for some use cases

<trackbot> Created ISSUE-4 - Requiring that negotiated channels be created on the receiver before any data can be received is problematic for some use cases. Please complete additional details at <http://www.w3.org/2011/04/webrtc/track/issues/4/edit>.

<dom> scribenick: fluffy

Define a min support size that works on order of 64 k

add a read only attribute of how much your side can receive

read only attribute of how much other side can read

IETF protocol would cause these attributes to be set shortly after channel got opened

IETF could do this with new message or piggy back on open messages

Randal and Peter T are ok with this

Martin seems OK with this

the attributes would probably be on the DataChannel

would throw exception JS tries to send something larger than allowed size


chairs suggest some interim meeting (or call) to sort out what we might have in version 1

Justin: the scope of API is a w3c decision and don't need to much

<rbarnes_> scribenick fluffy

need a list of topics that are in

question is phone call in december or meeting in January

dan: not sure we need a prioritization on items in order. In practice the group self selects to not do any more as people stop writing stuff

Justin: prefer to have a done by time x

???: If we don't get this right, we don't get good features. So should drive it from that

dom: issues is identity a current feature or next feature

justin: not trying to pick on nay feature, but we should make a list of all the features that need to happen and see what needs to be done

… if we say that is the min we need to do, still working at a bunch of time ahead of us

… partial offer / answer perhaps we don't do that

… not picking on anything specific

… but if we want to finish in 2014, we are going to need to drop some stuff that we are going to really wish we had

ekr: not really prioritization ordering in that people vote with their feet

jstin: need people to make list and we can review

hta: chairs need to be part of it
... propose we ask list about a call on dec 11

chairs: will do usual to sett up time and day

Transport Control

<ekr> ??? wrt upper side is Adam

<dom> Stefan's slides

stefanh: [slide 2]

... ["Background"]

stefanh: I'm proposing an API modelled on the DTMF handler for control

... [slide 3] links to the proposal

... [slide 4] shows a proposed addition to RTCPeerConnection with a getMediaTrackTransmissionController method

juberti: this is for send and receive, or only send?

stefanh: just "send"

juberti: I was hoping you could get this back when adding a stream to a peer connection

<ekr> new proposed name is doohickey

hta: when you don't want to control this, you can just ignore it

juberti: if you make it a return value of addStream, you don't add a new API surface

stefanh: FWIW, I agree with justin — it seems cleaner

juberti: addstream gives you back the handlers for each track within the stream, or we remove addstream and switch to doing addtrack.

martin: you don't know which stream tracks are part of.

cullen: that would require that each track added has a list of contexts it is part of.

stefanh: this may have been said, but all the tracks will have the same syncrhonization context anyway

... so they could be reassembled by the application via out of band information

adambe: I think streams are just complicating the transmission over the network

... we have ids on the tracks, so we can always signal the composition of the streams

martin: I'm glad you guys have finally seen the way

martin: i have argued against this enough, I'm now good with it.

martin: when you look at the track object, it has a list of the streams it is part of.

randell: how do you know when you have all the tracks for the videostream?

burn: if you do this, you don't even need msid anymore

stefanh: you do need track id

burn: yes, but not stream ids

cullen: on the receiving side, you will have callbacks saying new tracks have arrived. and the sdp will still have the track/stream mapping.

hta: we don't have a specific proposal for such a change; I think we need to focus on the proposal on the table

... martin, if you want to take an action item to provide a concrete proposal...

<dom> ACTION: martin to make proposal on moving away from addStream toward addTrack [recorded in http://www.w3.org/2013/11/12-webrtc-minutes.html#action04]

<trackbot> Created ACTION-102 - Make proposal on moving away from addstream toward addtrack [on Martin Thomson - due 2013-11-19].

stefanh: [slide "new API"]

... describes the proposes Transmission controller interface

... it has a reference to the track, and a boolean "theNewThing"

<JimBarnett> constraints can have boolean values

juberti: any reason this is an attribute rather than a constraint (?)

fluffy: the question is how much we do through contraints vs specific attributes

juberti: I think we need to take one approach or the other

... deciding constraint vs attribute should be done based on a well-defined set of criteria

Jim: the definition of constraints accept boolean

burn: you can, but keep in mind that the primary design of constraints is to allow for expressing preferences with possible fallbacks

hta: the New Thing is going to trigger a negotiationneeded event when we flip it.

juberti: realistically constraints have been used to work around WebIDL limitations of predefined names

jesup: one of the questions is how you get values out of these

randell: what about getting the values?

hta: please check the newest constrainable inteface - there is an interface for getting the values.

<jib> jib: +1

<jib> dan: +1

burn: constraints should not be used for every possible setting

... they are meant to express a preference

ekr: when I want to stop RTP, I want to stop RTP - it's not something that interacts with other constraints.

<rbarnes> ekr.constrain({ mandatory: { wordRatePerSecond: 2 } })

jesup: constraints should be used only when we absolutely need

<derf> rbarnes: Is that an upper bound or a lower bound?

burn: I don't have an answer off-hand given the modifications made to constraints via the Constrainable interface

<derf> Or is it like imageattr and he'll just ignore it?

jib: for a constraint, you need to have a selection between multiple choices

... the only place they make sense right now is for getUserMedia

... I'm probably arguing against using them in PeerConnection

... we should not replace dictionaries with constraints

juberti: there are many examples of constraints in the spec that would not satisfy the criteria just laid out.

burn: we decided yesterday all the constraints usage need to be reviewed

... it may be that most or all usage is not justified

juberti: if the answer is replacing constraints with dictionaries, then that may be fine.

jib: constraints are good when you want fallback (?)

... when I implemented the peerconnection settings, I found that we abused the mandatory/optional model (?)

juberti: in your review, the transmission controller should or should not be using constraints?

jib: no

hta: let's focus on the current problem before branching in yet another discussion

ekr: independently of the constraints/attribute question, we need to get to the bottom of theNewThing doohey thingy

hta: we have agreement they should be bound to the track and @@@

justin and cullen: we're proposing that there should be a similar doohickey on the receive side.

stefanh: [slide "Initial constraints"]

... (maybe settings rather than constraints :)

... proposal is: priority and bitrate

<dom> Resource Priorities API (WebPerf WG)

<dom> [the Resource Priorities API has 3 levels: "normal", "lazy-load", "postpone" FWIW]

martin: we need at least 4 priorities.

cullen: we need 3 priorities, these can be combined with the data types, which the scheduler knows, giving 9.

martin: need to look at the line that shows which goes first.

juberti: scavenger, low, high, highest. Making assumptions from the media type could be dangerous.

stefan: bitrate.

stefanh: for bitrate, I was suggesting a min-max value; maybe just a maximum value makes sense, although people have expressed the desire to express a min bitrate as well

cullen: we need to be clear if there is a target, a max or a floor - on IP, the lowest bitrate is always zero.

martin: a floor means that if we get below a certain floor, we should stop sending.

martin: a floor on quality makes more sense than a floor on bitrate.

juberti: we need a cap on the whole peerconnection, not necessarily on the individual track.

martin: this is for use cases where the app knows something about the path.

randell: the app may know which videos are more important for the application. we should give it the tools to say so.

<martin_> I just dispensed with my action from before

juberti: example: I want to stop sending video if the result is unusable; if the bandwidth comes back, I want video to resume.

juberti: quality thresholds can give us some tools that the scheduler can use.

dand: I agree with randell the application should be in control

... it should be about expressing a desire, more than making it a hardset setting

randell: the automated mechanism should be kept simple. COmplex stuff should be left to the application's hands.

cullen: even if I'm on a 50 Mbit 4G connection, it's perfectly reasonable to say that I don't want to use more than 1 Mbit of that.

justin: if I send hires, lores and audio, I want to drop the hires then the lores when bandwidth disappears, and claw it back when it becomes available. With thresholds in quality, not bandwidth.

fluffy: I think we should move away from bitrate specified as min/max

hta: I've heard support for a max rate for bitrate as useful

... and people arguing that setting a minimum quality level would be more useful

... but that needs a definition of quality

<ekr> Quality? PSNR

try again you are breaking up badly

<stefanh> I was saying that a min bitrate in combination with knowing the codec gives an estimate of the quality

... and so we need a proposal from those that think this is a good idea

... and if the application need to see information, this also needs a proposal

stefanh: if you combine codec and bitrate, you get a pretty good indication of quality

... so with a minimal bit rate you can actually get meaningful information

juberti: difficulty of correlating QoS metrics - bandwidth is highly scene dependent.

pthatcher: should you also be able to set codecs?

stefhak: that should be added somewhere.

<burn> action derf to get jesup to resend to the list an earlier proposal on how to interact with tracks

<trackbot> Created ACTION-103 - Get jesup to resend to the list an earlier proposal on how to interact with tracks [on Timothy Terriberry - due 2013-11-19].

ekr: a number of the frobs on the doohickey will cause negotiationneeded.

adam: I want to call TheNewThing "suspend" (suspended?)

<burn> I like suspendend

ekr, juberti: don't like paused, perhaps inactive is ok.

<burn> suspended, I mean

<ekr> suspendeded

adam: suspended has the same direction of the sign as muted.

<stefanh> I could leave it up to the editors and move on

<stefanh> name is not that important

adam: at least 2 telco systems have suspend / resume that mean exactly this.

<stefanh> did we ever conclude on receiver side "TheNewThing"?

adam: I think we need suspended (TheNewThing) on the receive side.

adam: the suspended bit on one side does not affect the suspended bit on the other side. these are controllers, not statuses.

ekr: believe we need receiver side doohickey.

juberti: do we need to set resolution on receive side?

fluffy: we should be able to set max resolution, at least.

stefan: do we want all this in the sdp?

adam: the signalling is already defined for SDP. Stuff that will interoperate with us will expect to have this work.

<stefanh> Think we need to close this now

<hta> Robin Raymond: I think we should not add the receive-side doohickey. It adds a lot of complexity.

cullen: I don't see why we want to signal this stuff (suspend for example) over a different channel than SDP.

pthatcher: don't see that there's the same amount at receiver as at sender.

<stefanh> Proposal: those wanting it develop a proposal for the reciever-side doohikey (including attributes)

pthatcher: the receive doohickey, which controls SDP, is lower priority than the send doohickey, which controls stuff that happens locally.

cullen: I think the priority is completely the opposite. The most important thing is that the receiver can ask to turn off.

stefanh: why don't people develop a proposal for the receiver side offline so that we can move on

<ekr> it's going to be very hard to add doohickeys on the receive side later

burn: you asked if I had some rules for constraints; I've sent a number of mail on this to the list

... there are a number of edge cases

... I'm happy to have that conversation again once we're ready for that

... I want to take the time to explain it properly

<dom> [coffee break]

Statistics in WebRTC

slide: statistics in webrtc

slide; Main API definition

slide: defining new stats items
... Stats defined
... implementation status
... issues found in practical usage
... issue: personally identifiable info

ekr: the way we've been doing this is to gradually add things in

slide: questions to address

fluffy: is it required to have a document for the stat?

hta: expert review

derf: [on an earlier slide] the standard you want for volume is EBU R128

hta: ... which practically requires a document for the expert to review
... part of the point of the expert review is to avoid duplication

ekr: standard should be for the stat to be (1) clear and (2) non-duplicative
... don't even really need a security review, we can catch that in implementation

juberti: went to xrblock, they're defining a whole bunch of stats
... they could possibly tell us a best set of stats
... seems good to be able to get stats in other ways than peerconnection
... don't want all the stats, just stats for X

ekr: would be OK with many different objects having a stats surface

<stefanh> note that the Media Source Extension doc extends the video element with stats (video related)

fluffy: i would view the IANA registry purely as a name conflict resolution thing

adam: e.g., you could have the same thing at different levels of aggregation

juberti: what are the main questions you would like to see answered?

hta: on the slide

fluffy: want to have the stats that are good to have, not the stats that are easy to compute

hta: add those that we know we need only

jib: how does the iana thing work?

hta: ietf tradition is that once the wg is finished, it goes away. so the iana exists to maintain things into the future

ekr: it's hard to make people implement constraints, because they can understand but ignore

jesup: would say all the stats are optional
... would like to hear the case for things being mandatory

juberti: applications will depend on them...

ekr: this sounds like a good argument for not having important stuff depend on stats

fluffy: clearly not all of them can be MTI
... but if they're optional, they might as well not exist

<ekr> Actually, I have things not quite right for constraints: you can ignore optional and fail on mandatory

jesup: they're useful in debugging and collecting data, but if you don't get the data, you don't get the data

hta: use them for discovering trends in usage -- how long do people stay on calls, how often does it terminate b/c of an error
... would be sad if there were significant holes in coverage. could probably live with it if we could discover which stats are not present (so that we could factor them out)

jesup: we already have that case today, because firefox doesn't have all the stats google does

juberti: if we're going to put certain stats in the spec, people should implement them because they've been vetted, seen as important
... real-time apps are super hard to debug, need these stats to do it
... if we're going to be more conservative about which we specify, we should make them mandatory

<stefanh> +1 to Justin

fluffy: when you look at individual stats, you'll probably get agreement from most people

jesup: agree that we should look at which are mandatory, which are not

<burn> ekr, what do you mean about constraints? optional and mandatory for constraints are regarding satisfaction of them by the browser, from the point of the JS developer -- they have nothing to do with which ones are supported by the browser

juberti: wouldn't bother putting it in the spec if it weren't worth implementing
... number of stats right now is not overwhelming
... 6 counters

hta: would be good to get some input from people, especially those aware of ICE

ekr: we currently expose the state of every ICE candidate

<jib> ekr means in privileged browser api only, not to content

fluffy: debugging something like hangouts does require automated feedback without user involvement

juberti: we could review what Chrome and Firefox implement, as a way of getting an idea of what to put in the document

ekr: justin and i could get together on that

<ekr> action erescorl to meet with justin to review ICE stats and see which make sense in statistics

<trackbot> Created ACTION-104 - Meet with justin to review ice stats and see which make sense in statistics [on Eric Rescorla - due 2013-11-19].

ekr: if the review indicates a need for more richness, we'll come back and figure that out

juberti: what about non-pc stats?

fluffy: the doohickies help with that

jesup: not with gUM

fluffy: never imagined there was utility to gUM stats

juberti: jitter frames, capture delay, stdev(delay)
... say you want to display a meter for voice to display the energy

<ekr> for those of you on IRC: I said $(gum).vumeter(div)

adam: are we going to give freq bands so they can do spectrum?

juberti: lots of phone apps do VUmeter, and don't do spectral

jesup: lots of this can be done with web audio

<stefanh> the Web Audio API enables you to do vu meter I think

<stefanh> it interfaces to MediaStreamTrack

fluffy: this falls in the category of easy things should be easy

stefanh: web audio enables you to display audio levels

juberti: i think some stats will not be computable via web audio, so we'll need the interface anyway

jesup: if there are any stats that are computationally non-trivial to compute, there's a good argument for not making them default
... do generally agree that we should have some stats available for tracks

rbarnes: tracks or doohickies

juberti: tracks for now

jib: no way to specify what selector you're getting. could we get stats for data streams?

martin_: why not just define a MIB?

hta: closing this topic

juberti: what about gUM stats, any actions?

martin_: no, but data channels are interesting

hta: could you take an action to suggest some?

martin_: yes

<scribe> scribenick: juberti


ekr: you want to me able to control the DTLS keys that are used

and cache them between sessions

need to make sure they are scoped to identity to prevent supercookies

temporary keys can also be generated

or created via WebCrypto and shoved down into the PeerConnection via a new setDtlsKey method

The WebCrypto mechanism is much more flexible, allows application to choose its key length

and makes the state management super obvious, since app is doing it

better mechanism, but not without some flaws

passing in the public exponent is kind of gross

juberti: are you arguing for this new mechanism and APIs

ekr: yes

juberti: what is the implementation status on this?

ekr: barnes?

rbarnes: spec is pretty stable. not sure about implementation status.

cullen: we can go talk to sleevi.

juberti: can this be done in 2014?

ekr: we could retrofit this later.
... would be nice to know about other side's keys, for key continuity

expose an array of arraybuffers, in DER form, with certificates or remote side.

juberti: where does one get these arraybuffers?

ekr: next slide
... I give you, pc.remoteCertificates

list can be parsed with WebCrypto

no claims about the browser's opinion of the certs

juberti: how do we deal with chains, when we also have fingerprint?

<ekr> " For DTLS, all m= sections MUST use the certificate for the identity

<ekr> that has been specified for the PeerConnection; as a result, they

<ekr> MUST all have the same [RFC4572]fingerprint value."

juberti: so the fingerprint indicates that the cert is what you think, and the chain indicates whether you trust the identity from the cert

ekr: yes

juberti: how do you handle the case where there are two DTLS connections (with their own remote certs?)

ekr: can this happen?

juberti: yes, if talking to legacy gateway

ekr: hmm, maybe we need to move this to the doohickey

pthatcher: what about data channels, they have no doohickey (yet)

martin: we can add the property to the doohickey and the data channels
... and duck type if necessary

<ekr> hta, that would be fine with me as well

<rbarnes> hta: sounds good to me

pthatcher: could we add a parameter to indicate which DTLS do we want to get the certificates from?

if no parameter, only works if there is one dtls connection

hta: each object except for PC only has one DTLSContext

ekr: I like this since it gives us insight into DTLS and stuff

<ekr> action erescorl come up with a proposal for exposing a transport/DTLS doohickey for each non-PC object

<trackbot> Created ACTION-105 - Come up with a proposal for exposing a transport/dtls doohickey for each non-pc object [on Eric Rescorla - due 2013-11-19].

pthatcher: and other transport stuff

back to ekr

ekr: remote identity is directly observable

via new pc.peerIdentity

here's how it works

onidentityresult provides a RTCIdentity corresponding to the obtained identity (from remote)

rename peerIdentity to remoteIdentity to match remoteDescription

localIdentity contains own identity

pthatcher: can you have multiple remote identities

ekr: no; JSEP says only one identity
... way too complicated to have more than one

moving on

a MessageChannel is needed for moving identity stuff around

which needs a specific name. TBD, but proposing identityMessageChannel

hta: does each PeerConnection have its own MessageChannel?

ekr: yes
... otherwise not necessarily safe

<ekr> ACTION: ekr to generate a single monolithic description of who sends what on identity [recorded in http://www.w3.org/2013/11/12-webrtc-minutes.html#action07]

<trackbot> Created ACTION-106 - Generate a single monolithic description of who sends what on identity [on Eric Rescorla - due 2013-11-19].

ekr: noaccess and peerIdentity

Can't attach MediaStreams that are isolated to PeerConnections (or other undesirable sinks)

martin suggested that instead when things were nonpermitted they generated silence or blackness

martin suggests you can always glue things together however you want

stefanh: do streams get marked, or tracks?

martin: tracks

jesup: a few questions about black/silence
... what info is leaked through these aforementioned black frames?
... does this leak more than passing nothing?

ekr: here's the upside
... allows JS to get a noaccess stream with no permissions/prompting

can be pushed into video tag, usable for hair check etc

martin: browser can control how much info gets let through

ekr: you could use this for checking all cameras

jesup: do something, camera will come on, no permission

ekr: hence more creepy

juberti: this seems hard to explain to a user
... cam comes on, no permissions, but they we need to give permissions to start sending the video

someone jib: this could be an implementation decision

<dom> [so to clarify, we're trying to figure out if we can make a reasonable UI that would make the noaccess feature realistically usable, right?]

rbarnes: I think we want a common permissions model across apps

<ekr> dom: well, sort of.

(and browsers)

<dom> [I don't think we should spend ages discussing specific UI ideas directly; figuring out whether the feature is realistic sounds relevant though]

ekr: main thing this gives you is in-content device selection.
... do we care about this? if not, we can do something else.

if we don't do this, user has no way to make an informed choice on this.

<stefanh> we could have the browser display info (thumbnail) in browser chrome

We can't have two prompts - too complicated - so any device selection must be done either in chrome or when user gives access to all devices.

FF UI asks you to pick a camera, but you can't change it later.

pthatcher: doorhanger could indicate the available cameras.

martin: example of plugin dialog in firefox

jesup: not so sure. so in hair check scenario, what happens?

martin: protected from sampling by noaccess stuff

ekr: secure from design, but not necess from UX

juberti: this seems dangerous. if we make a mistake, we will be very unhappy.

jesup: people won't expect the camera light to come on?

pthatcher: when user is prompted
... they can get an allow/deny dialog, plus a preview button that would let the page display the video without granting access

jesup: can we have promotions from preview to allow?

juberti: i still think this is hard for users to understand

<stefanh> agree to juberti

<hta> ACTION: martin to drive discussion with ekr and pthatcher about permissions model (brainstorm) [recorded in http://www.w3.org/2013/11/12-webrtc-minutes.html#action08]

<trackbot> Created ACTION-107 - Drive discussion with ekr and pthatcher about permissions model (brainstorm) [on Martin Thomson - due 2013-11-19].


dom: working on setting up testing meeting

if you are interested, now is a good time to get involved

ekr: testing this stuff is kind of tricky, hard to verify audio and video, needs permissions bypass

dom: want to avoid duplication of effort

google wants to cooperate on test harness

<ekr> google would rather not test?

hta: google folks are working on incorporating w3c tests into google tests

not sure which harness will run where

but that is the purpose of the work

if we promise to make tests and make sure they continue working, we want them to run on our bot system

if we can get together and figure out how to make the same tests work on moz and chrome, that would be a Good Thing.

ekr: we should include NATs as part of this

juberti: sure. but how far do we go on this? do we test Chrome's proxy detection?
... we have a bunch of testing facilities that make this all easier. we just want to make sure the w3c tests work in our test rig.

ekr: that's the only thing that makes sense.

cullen: sipit interop testing coming up on monday.

<dom> ACTION: Dom to coordinate testing questions before a dedicated meeting [recorded in http://www.w3.org/2013/11/12-webrtc-minutes.html#action09]

<trackbot> Created ACTION-108 - Coordinate testing questions before a dedicated meeting [on Dominique Hazaël-Massieux - due 2013-11-19].

not automated, alas, but very in-depth


hta: we covered a lot of things over the past two days

and recorded a lot of new actions

and uncovered a lot of new issues

but the flow here was not what we wanted

the interactions in a satellite meeting was not good.

there were various scheduling difficulties that led to this, but we are sorry about the experience.

stefanh: i want to apologize to everyone who traveled here

dom: this all works better when things are all in the same place

jesup: when we did the interim meeting connecting to Stockholk, things were much better; because connectivity was much better.

we will do better next time.

Summary of Action Items

[NEW] ACTION: adambe to clarify whether RTCdatachannel close and error events are mutually exclusive or whether error + close is possible [recorded in http://www.w3.org/2013/11/12-webrtc-minutes.html#action02]
[NEW] ACTION: adambe to modify the maxRetransmitTime and maxRetransmits text to say that the max values do not require the implementation to go over its internal builtins [recorded in http://www.w3.org/2013/11/12-webrtc-minutes.html#action01]
[NEW] ACTION: burn to talk to dom about whether we should clamp or throw exception for invalid params to insertDTMF. [recorded in http://www.w3.org/2013/11/12-webrtc-minutes.html#action03]
[NEW] ACTION: jesup to resend to the list an earlier proposal on how to interact with tracks. [recorded in http://www.w3.org/2013/11/12-webrtc-minutes.html#action05]
[NEW] ACTION: martin to make proposal on moving away from addStream toward addTrack [recorded in http://www.w3.org/2013/11/12-webrtc-minutes.html#action04]
[NEW] ACTION: randell to resend to the list an earlier proposal on how to interact with tracks. [recorded in http://www.w3.org/2013/11/12-webrtc-minutes.html#action06]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2013-11-19 10:26:36 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/websockets doesn't use strings?/websockets now uses enum; we should do the same and get error handling for free from WebIDL/
Succeeded: s/burn:/burn,/
Succeeded: s/juberti/ekr/
Succeeded: s/ - /:/
Succeeded: s/Juntin/Justin/
Succeeded: s/???: upper side is a pox on the industry//
Succeeded: s/could could/could/
Succeeded: s/while/why/
Found ScribeNick: juberti
Found ScribeNick: fluffy
Inferring Scribes: juberti, fluffy
Scribes: juberti, fluffy
ScribeNicks: juberti, fluffy

WARNING: No "Present: ... " found!
Possibly Present: AndyF AndyF_ BY DanD DanS GANG GangL Jim JimBarnett Jim_Barnett Justin LeiWANG Leon Marcus_Altman_ Marcus_Altman__ Proposal TZH TZH_ Takahiro Takahiro_ Tony Tony_ Travis aaaa aabb aacc aadd adam adambe burn chairs chris christer cullen dan derf dom dom_ dom_proj dom_proj_ ekr elagerway fluffy frodek hiroki hta https ijongcheol issue jan-ivar jeff jehoochen_ jehoochen__ jeromemarco jeromemarcon jesup jib jinkyu_seong joined jstin juberti ken kodonog kotakagi kotakagi_ lgombos martin martin_ mchampion minami mreavy pthatcher randell rbarnes rbarnes_ richt richt_ robin room scribenick silvia silvia1 silvia2 silvia3 someone stefan stefanh stefhak stephane stephane_ tao taocai tcai trackbot webrtc wyh_ yahui yimin yusuke yusuke_ ywu
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy

WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting

Agenda: http://www.w3.org/2011/04/webrtc/wiki/November_11_-_November_12_2013#Tuesday
Got date from IRC log name: 12 Nov 2013
Guessing minutes URL: http://www.w3.org/2013/11/12-webrtc-minutes.html
People with action items: adambe burn jesup martin randell

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.

[End of scribe.perl diagnostic output]