W3C

WebRTC F2F (TPAC 2014)

30-31 Oct 2014

See also: IRC log

Attendees

Present
Harald, Stefan, Alexandre, Dom, DanBurnett, Justin, Peter, Martin, EKR, AdamRoach, Jan-Ivar, ShijunS, BernardA, Cullen, DanDrutta, DanRomascanu
Regrets
Chair
HTA, StefanH
Scribe
alexG, bernard, jib, dromasca

Contents


<alexG> ScribeNick: alexG

Administrativia and agenda bashing

hta: do we approve last meeting minutes

<dom> http://www.w3.org/2014/05/20-webrtc-minutes.html

<dom> http://www.w3.org/2014/05/21-webrtc-minutes.html

<discussion about the saving of previous meeting videos on youtube>

hta: does anybody object to approving those minutes?
... they are approved
... does anybody wish to challenge the agenda?

ekr: this is a GOOD agenda!

beranrd: do you really want to spend 60mn on promises?

hta: it s here if we need it
... i really want to close this discussion today

juberti: how to handle errors with candidate? i d love for us to talk about it. i haven t prepare slides, but i could for tomorrow.
... onerror for failure during gathering
... we previously agreed on having a new callback for gathering state changes, and wether candidates have failed or succeeded

hta: adding this to the agenda for today, if we can't address it today, we ll do it tomorrow
... the agenda has been bashed, let s justin take over and talk about doohickeys

RTCRTPSender/Receiver

juberti: doohickeys are dead
... only RTCRTPSenders/receiver are here to saty

how many people have checked the pull request

scribe: good. One of the thing that is nice about it, it the way we factored out the data channel, the peer connection API is much simpler.
... <slide 3>
... the whole reason to do it, is that there was no way to control how it is transmitted over the wire (bitrate, .....)
... introspecting inside peer connection was incredibly difficult

<slide 4>

scribe: now we have the right multiplicity
... per track parameters to check how it is send / received
... we also spoke about transport (DTLS, ICE transport parameters)
... all those objects coupled together give you all you need to answer the questions that were hidden within peer connection

<slide 5>

scribe: the streams API ar egone, track-based API are in.
... there are few changes form last time
... you can now declare a track as being part of multiple stream (watch the variation)
... onaddtrack is now called ontrack, consistent with ondatachannel
... this is the current pull request being reviewed

dom: ok, you cannot use sequences as attribute, but why not array .
... a sequence is always by value, whereas an array is by reference
... you use sequence when you want to get something and keep it.
... and you use array otherwise

juberti: tell me what you want

dom: i ll take it offline.

ekr: two questions
... question1 ......

juberti: if you pass no stream, we assumed that there is no sync needed.
... otherwise, we will create a sync pool.

adam: is this related to msid?

juberti: no.

adam: ok just wanted to make sure it was separated.

juberti: the question is what happen when you talk to an end point to knows only about ....

fluffy: on the add track
... if i wanted to get a track and send it at two resolutions

juberti: you need to clone it

otherwise, you would shave the same msid for both

bernard: question
... let s say we do that (diff resolution)
... what happen with on track on the receiver side?

juberti: ontrack is raised, and they would be sync grouping info for the app to know what to do with the other streams.

stefan: do we have error here if you provide a track with info about a stream to which the track does not belong to

burn: this does not actually create mediastream

juberti: sort of
... if you talk to an endpoint that does not have this msid, it will create it

burn: i am trying to think about how you explain this to people that are JS dev that are trying really hard not to know about the underlying things
... in this case, they would have to start learning

juberti: well, not really, you don't have a lot of things to do. just attach the stream to a media element. if you get multiple streams, it is expected that you know what is going where.

burn: ....

juberti: say you have audio and video tracks in a single stream
... ...

bunr: now that we are talking about tracks as objects, the relationship is not clear.

juberti: say you have a video track, you attach it to a video element, then later an audio track comes, sync with that stream, and it s working already.

shijunshun: just to clarify
...

juberti: you don t need to create an audio tag, then a video tag, ....
... there is always be at least one stream
... for you to stick into source

shijunShun: but when you create the first element, do you already know the element type, or you need to wait?

juberti: no need to wait

ekr: .... hum .... i m good

<slide 7>

<dom> ekr: what's the plan for deprecating the existing API?

ekr: what is the interface? JSL

<dom> juberti: probably the same as for promises

juberti: transports

<hta> (JSL=Javascript Library)

juberti: global view of transports

this allow you to introspect a lot of things

before you don t exactly what was the point of failure when something failed

now you know per transport

scribe: now you can say directly the kind of connection (relay or not)
... you can now ask what is the dtls certificates being used
... for each transport now you can see all those parameters

ekr: we need to change the name of RTCIceTransport as we have an existing enum

juberti: ok, add "policy" at the end

<slide 8>

ekr: what about rtcp-mux?

juberti: we call it trptransport, but it could be rtcptransport
... let s move to the API.

<slide 9>

scribe: on each sender/receiver you have a DTLSTransport

ekr: we need to decide if they are nullable

martin: the ugliness will manifest itself during the implementation

juberti: if something failed because of dtlsError or iceError, then you can figure it out now.
... there are specific event for each

ekr: what about data channel?

juberti: glad you asked

martin: what would sftp transport expose?

juberti: pretty minimal

martin: i like the fact that it s small API.

alexg: so n the specs right now, if a single ice connection fails, at peer connection level we tag all of them as failed
... will we change that now we can se which one failed?

juberti: no, since you still need to do an ice restart that will reset all the connections.

<slide 10>

juberti: encoding parameters
... it covers everything you want to do with the stream
... some of them happen right away
... some of them happen at (re) negociation

<slide 11>

scribe: encoding parameters for 1.0

dom: why having a dictionary with a single member? do you plan to extend it later?

juberti: yes

bernard: what about this simulcast

juberti: it would return a set

ekr: do we really want dictionary here?

martin: dictionaries are mutable, so ...

dom: you might want an array more than sequence.

fluffy: for the extensibility thing, we need to pass a string list.
... basically the MTI strings

ekr: there must be some way to reject parameters

jib: is there any reason not to use attributes?

dom: on what?

jib: on sender

bernard: they have to be consistent

jib: i just knw image capture is playing with this

burn: they have the same concern

fluffy: if you re gonna change 5 things, you don t want 5 renegociation callbacks

juberti: but if you wanted errors or callbacks, we would deed to do it as atomic operations

<slide 12>

juberti: example: put people on hold and change the bitrate

stefan: how to define bitrate ?

fluffy: setting the parameters should be async

jberti: it depends
... we can just make it into a promise

hta: if you can t tell immediately wether it failed or not, then make it a promise

juberti: fair enough

fluffy: you will need that for hardware codec.

juberti: probably

bernard: get parameters will always return what you put ?

juberti: well, no. especially with async, or for things that won't work (11GBPS bitrate)

fluffy: there will be times when
... you will try to set values that are not possible, but you still don t want error
... <example>

<slide 14>

juberti: getCapabilities

martin: there in your object you have kind which can be audio or video, maybe we need specialized object, which make lot of things easier

fluffy: question about the semantic
... if i get the capabilities, how long is it valid

<dom> [I think at least using a Typedef would make it somewhat more readable]

ekr: assume it is valid for now, and no other premises

fluffy: i would prefer that for 1.0 we fix the combinations

or at least the most common cases, the one that fall back to what we have today

<slide 16>

rtpSender.track

juberti: it is readonly in current API
... if we were to make it mutable, it makes for an easy solution to "how to switch between front and back camera"

<slide 17>

hta: if the new track is different from the old track in any way .....

jib: in firefox we have a replacetrack() that s async, but is doe snot have to be
... could fail

martin: if you had a 264 encoded track, that you want to replace with a non-264 track ? it wouldn t work right?

juberti: yes, it wouldn t work.

martin: so ... you just stop sending?

juberti: yes.
... at least you don t renegociate
... the MSID then must be the same
... but sender/receiver are already associated with a m=line

fluffy: well, then anything that would trigger a renegociation event would then fail, for speed sake.

juberti: now we can correlate between rtpsender and receiver, without the need for other info

hta msid is used for two things

scribe: now, with this mid, some things become redundant

martin: I think this is workable.

<slide 18>

juberti: rtpSender.mid/msid

hta: the goal here is to decide if it is exciting enough for us to ask justin to make a pull request, not to make a final decision

<slide 5>

juberti: that s the current pull request
... and except for the array vs sequence thing, there was a consensus.

hta: modulo the array and getter discussion, does this to be acceptable to be in the spec.

fluffy: well, we agreed to go this direction one year ago.
... this is very different from looking at the pull request.

hta: shall the spec include this without asking the whole group again.

juberti: let s put it into the spec.

fluffy: but we will need to discuss the details

everybody: right

hta: go down to API transport
... my feeling is that it is less mature in people minds

burn: we also know there will need to be duplication between rtp and rtcp

fluffy: at this conceptual level, I think there is the same level of consensus: solve the small details and put it in the specs.

hta: action is on justin

burn: i would love more from justin before we put it in the specs

fluffy: yes, work more on the list before

hta: accepted as starting point for some more discussion then integration

dom: is it something we want for 1.0 and is it in the right direction?

hta: so the encoding parameters ....

fluffy: I would want to think about which attributes should be part of the 1.0 set

hta: my worry is: if we try to handle all the possible cases, we will never make it for 1.0

fluffy: i want to think about what a minimal thing is before I agree for this.

hta: this is a starting point for discussion and we ll see wether we can agree on a set that we feel safe enough to go in the 1.0 specs.

bernard: my only concern here is the interaction between setting and getting.

dom: looks like a pull request for discussion is interesting, but it wouldn t be a pull reuest that will be integrated

juberti: i think that if I address the three things that were mentioned today, we re in good shape.

hta: it is a feature request then.
... next one in the list is getCapabilities()

martin: we want something very simple, that supports what we can do today.

fluffy: would we clock rate be used?

juberti: wide band codec

fluffy: clock rate might be the wrong name: sample rate?

ekr: ekr: i m ok with that the way it is now, but be ready for extension

hta: what i suggest to do is to make it a feature reuest, because it does not feel clear enough what we want.

matrin: i would rather start with this, and drop things.

burn: this itself is a feature request

ekr: this is important , we should consider it for 1.0

juberti: the only structural issue is the extension of getCapabilities, so it makes me feel that we are on the right track

fluffy, i think we should drive it into two questions: is this extensible enough for a complex codec.

scribe: and is it simple enough to do the minimal case without too much oerhead

overhead

hta: we are back on being late on schedule.
... RtpSender.track

martin: the only question is only wether we want a get or a function is the only thing remaining

hta: ok. propose to the list.

dom: are we at the state of making a pull request then?

martin: yes

hta: ACTION: prepare a pull request, and discuss
... who takes the action item?

<dom> ACTION: JIB to propose pull request for replaceTrack [recorded in http://www.w3.org/2014/10/30-webrtc-minutes.html#action01]

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

jib: i can take that.

juberti: API RtpSender/Receiver/mid/msid

martin: i m not a big fan of it, but i won't oppose it either.

juberti: we haven t been super clear from the beginning what MSID is and how it should be used. this gives us an opportunity to address that.

fluffy: if we understand why we need msid, that would help here.

martin: I d like to keep mid, and then think about wethe ewe need maid later

maid -> msid

<dom> ACTION: Justin to make pull request on RTPSender.mid [recorded in http://www.w3.org/2014/10/30-webrtc-minutes.html#action02]

<trackbot> Created ACTION-114 - Make pull request on rtpsender.mid [on Justin Uberti - due 2014-11-06].

juberti: I will take care of the pull request

hta let s take a break and be back at 3 sharp

<hta> scribenick: bernard

Promises in WebRTC

Why add promises?

What is proposed - example of how promises could be used instead of success/failure callbacks.

Eric: Can we not debate whether this is superior?

Another example with mediaCapture

An example with WebIDL overloading.

Shijun: Promise is in Media Capture already? Yes.

EKR: In the current spec, if you only specify a success callback, you get a runtime error... to force people to look at errors. This won't be true with promises, right?

Adam: Can't we mandate that?

Strength of promise is way better error handling.

<mt1> I wouldn't characterize this as "way better", just easier

In the xample (media Capture) there is one line of error handling.... then can take a success and failure callback... most people don't check for errors at every turn... if any step fails you can catch it at the end.

EKR: Why not just give them different names? Then the problem with callbacks goes away.

Adam: I would argue that moving to the promise model we don't have that enforcement anyway...

EKR: You are importing this misfeature from promises and now we have to live with it in callbacks...
... We were trying to make people acknowledge errors by making the failure callback mandatory...

Martin: We have so much code out there that we could create problems....

Dan: This is not like media capture... here these are all extensibly use... can't use same trick with media capture... have to overload all... or none.

Martin: Both promises and callbacks.

Cullen: I am against having two ways to do the same thing.

EKR: My argument is that this text is controversial and it doesn't become a commitment...

Cullen: I was talking about the text Dan wrote in the current document.

Dan: In the text, I tried to be compatible with the group sentiment, understanding that you (EKR) was unhappy with it.

Slide on Hybrid approach.

Stefan: Should we nove to promises... I hear we should move to promises.

Justin: We should add support for promises for the 4 or 5 methods we have identified... and keep callbacks so things keep working.

Bernarda: That makes more sense to me.

Justin: Keep existing things so as not to break the system.
... If you want callbacks and promises in your code... have at it (not recommended, though).

Martin: The fact that there are promises elsewhere and not callbacks is a hint to developers.

Dan: We can recommend the promise model where both are possible.

EKR: I would be satisfied with the first half of this note...

Harald: An agenda item for tomorrow's session on media capture.

EKR: In context of this... are we happy with the first paragraph?
... I would be satsfied with a rewrite of the last paragraph.

Stefan: Who has the action to draft it?

Martin: There is a pull request... that has changed.

Stefan: Can we get a pull request for your proposal?

If they have Internet on the plane....

Martin: Is there urgency on this? Other than making progress ?

JanIvar: Left out getStats().

<dom> ACTION: JIB to create pull request on promise-based hybrid for webrtc [recorded in http://www.w3.org/2014/10/30-webrtc-minutes.html#action03]

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

Stefan: Next item: DTLS certirficates.

DTLS certificates

<timpanton> Are the slides viewable somewhere for DTLS certs ?

Justin: Keep callbacks, add classes to describe methods and add promises for all new methods.

Martin: Certificate Selection API.

<dom> Martin's slides

<timpanton> Thanks.

options: one cert per original, per RTCPeerConnection.

Firefox generates a new certificate for each RTCPeerConnection.

Martin: same cert over time OR different certs over time.

Same cert allows for key continuity.

Different certs allow sites to break correlation between sessions

Proposal: use new API to generate WebCrypto keys... PC API generates a cert based on those keys...

Shijun: private keys are stored and managed by user agent and are off limits

Martin: They would be non-exportable.
... How it works. Call a key generation function then construct RTCPeerconnectgion with "theKey".

Shijun: You could reuse the same set of keys for multiple RTCPeerConnection?

Martin: You could.
... This key is only accessible to your origin.

Cullen: IndexDB doesn't show how you store stuff you can't look at.

EKR: You store the object in IndexDB.

JanIvar: What types is the key? cryptoKeyPair

Martin: There is no getPrivateKey method.

<timpanton> Does this mean that the x509 the far end sees has none of the standard fields ? no CN etc? We were looking a while back at having a call centre service provider present DTLS keys that were publicly signed, and the same as the ones that the web page offered - giving you extra confidence that the page and the media was from the same origin - i.e. your bank.

<timpanton> conversely, can the .generate() function control what is in the key ?

<dom> ACTION: martin to give an example of indexed-db key retrieval [recorded in http://www.w3.org/2014/10/30-webrtc-minutes.html#action04]

<trackbot> Created ACTION-115 - Give an example of indexed-db key retrieval [on Martin Thomson - due 2014-11-06].

<timpanton> (no audio here I'm afraid - can some one voice me?)

Shijun: other side might be an existing legacy system. Any problem with that?

Martin: Can have a negotiation failure... but this API is for grownups.

Peter: Does it return immediately?

Martin: First one is a promise....

<timpanton> tricky - house full of sleeping folks.

<timpanton> ": Does this mean that the x509 the far end sees has none of the standard fields ? no CN etc? We were looking a while back at having a call centre service provider present DTLS keys that were publicly signed, and the same as the ones that the web page offered - giving you extra confidence that the page and the media was from the same origin - i.e. your bank."

<timpanton> conversely, can the .generate() function control what is in the key ?

EKR: The browser has no way of populating that stuff....
... The way to deal with that ... servers can do that... but not browsers.

<timpanton> Thanks.

Dominique sweating...

Martin: It is really hot in here!

Dan: We asked to turn down the AC... they turned it OFF!

Martin: I imagine it will be used once when you decide to talk to someone...

Dan: Does the programmer need to remember if this has been done before?

Martin: 20 lines of text to be added to the spec....
... Choosing keys... if no keys are provided they are generated RTCPeerconnection picks a suitable key fro what is presented.. it might choose several.

HTA: Do we have agreement on major pieces ?

Answer:

Justin: Google uses a different key per origin.

EKR: Mozilla uses different key for each RTCPeerConnection.

Cullen: If it takes more than 3 seconds on mobile phones... don't want it.

Martin: Will generate a pull request for review.

<dom> ScribeNick: bernarda

Erorrs in ICE gathering

How to handle errors during the ICE gathering phase

<dom> justin's slides

JS has no idea what went wrong (becuase of bad TURN Sever), but would like to know when it works too.

Want a success and failutre event

Proposal; Add a url to the IceEvent to say what ICE server the candidate is from

Solution A: Generic onerror event.

When: We would have a type (e.g. "ice-gather" "bad-credentials", etc.

<dom> [nit: "int" is not a type in WebIDL]

uri of the TURN/STUN server in question.

Also, reason code

Solution B: is IceCandidateErrorEvent (specific to ICE)

again, with url, reason, description

Martin: General approach - is it just for ICE?

Justin: Given we have no clear second usage am inclined toward specific solution.

HTA: Seems odd to have this particular error be different from the usual error event

Justin: We could just replace description with containing an error object.
... Should we derive it fron an existing error event? Or include an existing event in the structure?

EKR: These are all gathering errors.

<jib> abr: Look to XHR as model

<jib> justion: not a pretty model

<jib> ekr: Suggest we leave the question of how to encode error to editor discretion

<dom> ACTION: Justin to draft pull request on icecandidate error [recorded in http://www.w3.org/2014/10/30-webrtc-minutes.html#action05]

<trackbot> Created ACTION-116 - Draft pull request on icecandidate error [on Justin Uberti - due 2014-11-06].

<dom> ACTION: AdamR to look at how to represent network error on ICE gathering based on XHR/Fetch/WebSockets [recorded in http://www.w3.org/2014/10/30-webrtc-minutes.html#action06]

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

<dom> ScribeNick: jib

Stats

varun: RTCStatsType: there is one in the peerConnection doc as well. Needs to move out of stats doc, as I understood. opinions?

dom: it’s in the idl of the getStats

… move all of getStats to stats doc

<dom> ACTION: varun to move getStats and associated idl to stats doc [recorded in http://www.w3.org/2014/10/30-webrtc-minutes.html#action07]

<trackbot> Created ACTION-117 - Move getstats and associated idl to stats doc [on Varun Singh - due 2014-11-06].

varun: stats dictionaries correspond to data in various internal components

… open issues: inbound stats have a lots of RTP values but not fractionLost

hta: is it since last time or a consistent value?

varun: consistent value at any time

… additional metrics: packetsDiscarded? packetsRepaired? opinions?

bernarda: take things from XR draft ? next slode

slide

varun: RTCDataChannelState - is odd: other areas we usually only measure payload, not headers

… (bytesSent/Received) include headers or not?

scribe: suggest just payload
... open issue: RTCCodec.kind?

… instead of codec

hta: good idea. breaking up codec type = bad idea

ekr: kind: video codec vp8?

hta: yes

mt: break up info in the m-line or not?

hta: broken up because RTP does

… its a bad design that the m-lines contain the top level types

mt: agree

berndarda: things that don’t have a kind

justin: splitting sounds good

hta: does kind belong up in mediatrack stat?

jib: jib: i agree

hta: move kind to mediastreamtrack stat

next steps

varun: missing metrics?

(silence)

next slide: References

ekr: better to put stats in same doc?

burn: I’d love to keep getStats in there but it’s hard

varun: thanks
... fractionLost should be kept. No interest in packetsDiscarded/Repaired

… discrarded is like if you have a jitter buffer and you have to discard it

justin: what impact does nacs have

fec

scribe: we expose stats on how many we use conceilment on
... neteq, jitterbuffer
... one for expansion based on, partial recover…

varun: RTCCodec would have a mimeType instead of codec, and (what was the second part?)

hta: kind up there

justin: should make capabilities and stats match

hta: someone should review the match and see

… varun to take action

<dom> ACTION: varun to review matches between capabilities and stats [recorded in http://www.w3.org/2014/10/30-webrtc-minutes.html#action08]

<trackbot> Created ACTION-118 - Review matches between capabilities and stats [on Varun Singh - due 2014-11-07].

<dom> ScribeNick: dromasca

Bugs Walkthrough

status of the bug tracker

harald = h

bugzilla 47 bugs open

<dom> WebRTC open bugs list

7 issues in github tracker

classes of bugs

errors in the spec - got to fix

request for functionality - essential to add

unessentia - wg needs to decide

proposed methodology - bug tracker on screen, look at bugs, categorize

discuss or assign someone to take care of it?

makes sense?

yesterday's not yet in? - no

ekr - github - should we use only one tracker? issue?

h: got to get rid of this stuff

s - people like to have one tool

document bug or discuss

a, ekr - use tracker stuff is different than reports than requests

github easier to track, link, include

dom - other wgs in w3c working with github

issues different than discussions, no single w3c policy

can it be linked to mail list?

there is a tool to do it

we are not just talking about editorial

everything that is substance needs mail list

<dom> ACTION: stefan to look at our bug tracking strategy for WebRTC with harald [recorded in http://www.w3.org/2014/10/30-webrtc-minutes.html#action09]

<trackbot> Created ACTION-119 - Look at our bug tracking strategy for webrtc with harald [on Stefan Håkansson - due 2014-11-07].

chairs - stay with this tool while experimenting - update the statements accordingly

<dom> 15861

15861

<dom> API for JS interaction with congestion control

proposal yesterday real-time interaction with cc

per encoding - needs text

<dom> PeerConnectionErrorCallback argument

17287

close

<dom> Callbacks need to be called asynchronously

19580

was fixed

19729

<dom> missing a reference for XMLHttpRequest in 4.1 Introduction

needs to be assigned

20806

security consideration text - needs review

<dom> Section 15 (Security Considerations) is empty

dom to review

<dom> Stream rejection not possible

20809

ekr - needs text to document

between ontrack and createAnswer

j: what happens in a two-way track if one side rejected from remote?

stays on hold?

bernar d- in sdp there is no difference

needs to indicate the difference

for inactive - both sides clear, what happens in the one side case, how it's signaled in sdp?

h- propose text, example

to assign later

20811

what rtp profile is mti?

<dom> RTP usage not defined

<dom> (just needs closing)

20816

hold

<dom> Hold unspecified

send only / receive only states

assign to justin

muting a track is a local event only, hold changes to receive only

ekr - is there a need in the api to say remote side stop sending

can phones do this now?

this can be done in the app

important enough to do spec

send only can be done with existing api

assign to justin

20819

<dom> no priority API

no priority api

app level priorities, not dscp

4 level proposal

proposal in the rtcweb transport

we just need the api - simple - behavior defined in the ietf spec

is this needed for 1.0

rtpsender api - resolve later

21086

<dom> --- getLocalStreams and getRemoteStreams should return empty sequence after Peerconnection::close

leave open

21877

<dom> API is unable to handle inbound streams prior to arrival of answer

offer public address or browser - different cases

h - any change in the api to fix this?

send information about stuff that cannot be handled

bd - announce big stuff arriving

a - partial information about the track, when more info arrives needs to update

h - give the implementation the option of holding the data until get an answer

sometimes the time window is too short

the only api change - indication in the header, stuff arrived, i could not handle it

j - looks like a short-time solution

covers a whole spectrum of scenarios

assign martin to write text

1.0 scope

21878

<dom> Unable to learn of unknown inbound media

overtaken by events?

<dom> Unable to access certificate information in the API

21879

varun - identity is there now

solved

21880

<dom> Certificate management is underspecified

attach to the proposal made yesterday

assign to martin

22441

<dom> Bug in section 8.1.2 Requesting Assertions

assign to martin

<dom> Bug in section 8.1.3 Verifying Assertions

22442

same

<dom> Requiring that negotiated channels be created on the receiver before any data can be received is problematic for some use cases

23832

close

<dom> DataChannel.onerror callback needs an error argument specified.

resolved, will not fix

23919

needs edit

todos sumary in section 11

assign to the editors

23920

<dom> TURN authentication failures should be surfaced as some event

assign t ojustin

to justin

<dom> RTCDataChannel::send() steps are not proper.

25102

needs more work, proposal, discussion

assign to adam

25440

<dom> MediaStreamTrack.readyState has no muted attribute

dom will make proposal

25497

25513

h - change definition

should be documented - editorial

25533

<dom> WebRTC spec should explicitly specify all muted events of MediaStreamTrack related to RTCPeerConnection.

justin - rollback issue

<dom> WebRTC spec should explicitly specify the state transition for cancelled offers

needs add to api. assigned to ekr

25533

<dom> Options attribute of createOffer / createAnswer should be validated before processing.

25544

webIDL type checking

25545

<dom> Initialization of of RTCConfiguration while invoking RTCPeerConnection.getConfiguration should be updated.

edit proposal - obe

25576

<dom> steps for createDTMFSender() are missing

assign to editors

25579

<dom> State transitions are missing in RTCPeerConnections state transition diagram

j: just say no

25596

<dom> updateIce should be called setConfiguration

mark as solved - there's already a call rewquest

<dom> ice pool size

25808

25596 - jusitn

25806

assign to peter

should be done

25808

<dom> add new acces for the active remote/local SDP

clone of gerhard's issue

assign to justin

25811

afterbreak

25811

<dom> Change extensible enum to dom strings

existing enumerations?

<dom> Need to add pc.canTrickle

25828

assigned to marin

martin

25833

martin - any new information?

<dom> change the definition of "enqueue a task" as EKR slides May 20

<dom> close is synchronous & idempotent

assigned to martin

25834

25835

<dom> when closing, all outstanding actions are cancelled and their callbacks are fired with a "cancelled" error

25836

<dom> add note about addtrack being async

depending on the previous (last 3)

interaction with track adding and state transition

createOffer, addTrack, callback comes, what's the status?

createOffer not synchronous

h - anybody interested to see when onTrack is finished?

addTrack

can fail

? remains void, returns exception

same queue? we do not say that

h- save changes

25856

Martin - add attributes

25859

<dom> Add way to find out if a MST is isolated or becomes islocated

<dom> Streams that become isolated generate errors on PC

assign to Martin

25893

close - don't fix

25957

assign t ojustin

to justin

25975

<dom> Offer Answer options should supported sendOnly and inactive media states

<dom> PeerConnection should have an onerror event handler

still send DTMF?

<dom> When do the value of DTMFSender.canInsertDTMF can change.

check reflects the current state

can DTMFsender change?

assigned to Peter

harald file new item

26027

editorial

<dom> addIceCandidate should not be callable when PeerConnection is closed

<dom> Options attribute is required for createAnswer

26279

justin can update this

need identifier - voice activity detection

based on what you receive, not on what you send

can't preclude using offerAnswer in the future

assign to Justin, edit as per harald

26364

26620

timestamp

varun - move to the stats doc

assign to adam

26644

harald assigns to himself

justin two things in this bug, add new event, we should do it

add MID

27211

<dom> https://github.com/w3c/webrtc-pc/issues

Github

#4

more information needed, justin and cullen not here

#5

varun - keep simple? what 'simple' means

#6

differ

defer

#7

already assigned

#8

same as #5?

#9

assigned to cullen

#10

<scribe> closed

editors will edit - there will be a new version

probably last call not in 2014

Summary of Action Items

[NEW] ACTION: AdamR to look at how to represent network error on ICE gathering based on XHR/Fetch/WebSockets [recorded in http://www.w3.org/2014/10/30-webrtc-minutes.html#action06]
[NEW] ACTION: JIB to create pull request on promise-based hybrid for webrtc [recorded in http://www.w3.org/2014/10/30-webrtc-minutes.html#action03]
[NEW] ACTION: JIB to propose pull request for replaceTrack [recorded in http://www.w3.org/2014/10/30-webrtc-minutes.html#action01]
[NEW] ACTION: Justin to draft pull request on icecandidate error [recorded in http://www.w3.org/2014/10/30-webrtc-minutes.html#action05]
[NEW] ACTION: Justin to make pull request on RTPSender.mid [recorded in http://www.w3.org/2014/10/30-webrtc-minutes.html#action02]
[NEW] ACTION: martin to give an example of indexed-db key retrieval [recorded in http://www.w3.org/2014/10/30-webrtc-minutes.html#action04]
[NEW] ACTION: stefan to look at our bug tracking strategy for WebRTC with harald [recorded in http://www.w3.org/2014/10/30-webrtc-minutes.html#action09]
[NEW] ACTION: varun to move getStats and associated idl to stats doc [recorded in http://www.w3.org/2014/10/30-webrtc-minutes.html#action07]
[NEW] ACTION: varun to review matches between capabilities and stats [recorded in http://www.w3.org/2014/10/30-webrtc-minutes.html#action08]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.137 (CVS log)
$Date: 2014-11-05 15:02:57 $