See also: IRC log
<alexG> ScribeNick: alexG
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
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
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.
<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
<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
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
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
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
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
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
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