- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Wed, 05 Nov 2014 16:04:42 +0100
- To: public-webrtc@w3.org
Hi,
The minutes of our F2F last week at TPAC on October 30-31 are availble
at:
http://www.w3.org/2014/10/30-webrtc-minutes.html
and copied as text below.
Please send corrections to the list.
Dom
WebRTC F2F (TPAC 2014)
30-31 Oct 2014
See also: [2]IRC log
[2] http://www.w3.org/2014/10/30-webrtc-irc
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
* [3]Topics
1. [4]Administrativia and agenda bashing
2. [5]RTCRTPSender/Receiver
3. [6]Promises in WebRTC
4. [7]DTLS certificates
5. [8]How to handle errors during the ICE gathering phase
6. [9]Stats
7. [10]Bugs Walkthrough
* [11]Summary of Action Items
__________________________________________________________
<alexG> ScribeNick: alexG
Administrativia and agenda bashing
hta: do we approve last meeting minutes
<dom> [12]http://www.w3.org/2014/05/20-webrtc-minutes.html
[12] http://www.w3.org/2014/05/20-webrtc-minutes.html
<dom> [13]http://www.w3.org/2014/05/21-webrtc-minutes.html
[13] 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
[14]http://www.w3.org/2014/10/30-webrtc-minutes.html#action01]
<trackbot> Error finding 'JIB'. You can review and register
nicknames at
<[15]http://www.w3.org/2011/04/webrtc/track/users>.
[15] 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
[16]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
[17]http://www.w3.org/2014/10/30-webrtc-minutes.html#action03]
<trackbot> Error finding 'JIB'. You can review and register
nicknames at
<[18]http://www.w3.org/2011/04/webrtc/track/users>.
[18] 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> [19]Martin's slides
[19]
http://lists.w3.org/Archives/Public/public-webrtc/2014Oct/att-0101/keys.pdf
<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
[20]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> [21]justin's slides
[21]
https://www.w3.org/2011/04/webrtc/wiki/images/a/a7/ICE_gathering_phase_errors.pdf
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
[22]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
[23]http://www.w3.org/2014/10/30-webrtc-minutes.html#action06]
<trackbot> Error finding 'AdamR'. You can review and register
nicknames at
<[24]http://www.w3.org/2011/04/webrtc/track/users>.
[24] 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
[25]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
[26]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> [27]WebRTC open bugs list
[27]
https://www.w3.org/Bugs/Public/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=WebRTC%20API&list_id=42889&product=WebRTC%20Working%20Group&query_format=advanced
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
[28]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> [29]API for JS interaction with congestion control
[29] https://www.w3.org/Bugs/Public/show_bug.cgi?id=15861
proposal yesterday real-time interaction with cc
per encoding - needs text
<dom> [30]PeerConnectionErrorCallback argument
[30] https://www.w3.org/Bugs/Public/show_bug.cgi?id=17287
17287
close
<dom> [31]Callbacks need to be called asynchronously
[31] https://www.w3.org/Bugs/Public/show_bug.cgi?id=19580
19580
was fixed
19729
<dom> [32]missing a reference for XMLHttpRequest in 4.1
Introduction
[32] https://www.w3.org/Bugs/Public/show_bug.cgi?id=19729
needs to be assigned
20806
security consideration text - needs review
<dom> [33]Section 15 (Security Considerations) is empty
[33] https://www.w3.org/Bugs/Public/show_bug.cgi?id=20806
dom to review
<dom> [34]Stream rejection not possible
[34] https://www.w3.org/Bugs/Public/show_bug.cgi?id=20809
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> [35]RTP usage not defined
[35] https://www.w3.org/Bugs/Public/show_bug.cgi?id=20811
<dom> (just needs closing)
20816
hold
<dom> [36]Hold unspecified
[36] https://www.w3.org/Bugs/Public/show_bug.cgi?id=20816
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> [37]no priority API
[37] https://www.w3.org/Bugs/Public/show_bug.cgi?id=20819
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> [38]--- getLocalStreams and getRemoteStreams should
return empty sequence after Peerconnection::close
[38] https://www.w3.org/Bugs/Public/show_bug.cgi?id=21086
leave open
21877
<dom> [39]API is unable to handle inbound streams prior to
arrival of answer
[39] https://www.w3.org/Bugs/Public/show_bug.cgi?id=21877
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> [40]Unable to learn of unknown inbound media
[40] https://www.w3.org/Bugs/Public/show_bug.cgi?id=21878
overtaken by events?
<dom> [41]Unable to access certificate information in the API
[41] https://www.w3.org/Bugs/Public/show_bug.cgi?id=21879
21879
varun - identity is there now
solved
21880
<dom> [42]Certificate management is underspecified
[42] https://www.w3.org/Bugs/Public/show_bug.cgi?id=21880
attach to the proposal made yesterday
assign to martin
22441
<dom> [43]Bug in section 8.1.2 Requesting Assertions
[43] https://www.w3.org/Bugs/Public/show_bug.cgi?id=22441
assign to martin
<dom> [44]Bug in section 8.1.3 Verifying Assertions
[44] https://www.w3.org/Bugs/Public/show_bug.cgi?id=22442
22442
same
<dom> [45]Requiring that negotiated channels be created on the
receiver before any data can be received is problematic for
some use cases
[45] https://www.w3.org/Bugs/Public/show_bug.cgi?id=23832
23832
close
<dom> [46]DataChannel.onerror callback needs an error argument
specified.
[46] https://www.w3.org/Bugs/Public/show_bug.cgi?id=23919
resolved, will not fix
23919
needs edit
todos sumary in section 11
assign to the editors
23920
<dom> [47]TURN authentication failures should be surfaced as
some event
[47] https://www.w3.org/Bugs/Public/show_bug.cgi?id=23920
assign t ojustin
to justin
<dom> [48]RTCDataChannel::send() steps are not proper.
[48] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25102
25102
needs more work, proposal, discussion
assign to adam
25440
<dom> [49]MediaStreamTrack.readyState has no muted attribute
[49] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25440
dom will make proposal
25497
25513
h - change definition
should be documented - editorial
25533
<dom> [50]WebRTC spec should explicitly specify all muted
events of MediaStreamTrack related to RTCPeerConnection.
[50] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25513
justin - rollback issue
<dom> [51]WebRTC spec should explicitly specify the state
transition for cancelled offers
[51] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25533
needs add to api. assigned to ekr
25533
<dom> [52]Options attribute of createOffer / createAnswer
should be validated before processing.
[52] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25544
25544
webIDL type checking
25545
<dom> [53]Initialization of of RTCConfiguration while invoking
RTCPeerConnection.getConfiguration should be updated.
[53] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25545
edit proposal - obe
25576
<dom> [54]steps for createDTMFSender() are missing
[54] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25576
assign to editors
25579
<dom> [55]State transitions are missing in RTCPeerConnections
state transition diagram
[55] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25579
j: just say no
25596
<dom> [56]updateIce should be called setConfiguration
[56] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25596
mark as solved - there's already a call rewquest
<dom> [57]ice pool size
[57] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25806
25808
25596 - jusitn
25806
assign to peter
should be done
25808
<dom> [58]add new acces for the active remote/local SDP
[58] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25808
clone of gerhard's issue
assign to justin
25811
afterbreak
25811
<dom> [59]Change extensible enum to dom strings
[59] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25811
existing enumerations?
<dom> [60]Need to add pc.canTrickle
[60] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25828
25828
assigned to marin
martin
25833
martin - any new information?
<dom> [61]change the definition of "enqueue a task" as EKR
slides May 20
[61] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25833
<dom> [62]close is synchronous & idempotent
[62] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25834
assigned to martin
25834
25835
<dom> [63]when closing, all outstanding actions are cancelled
and their callbacks are fired with a "cancelled" error
[63] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25835
25836
<dom> [64]add note about addtrack being async
[64] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25836
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> [65]Add way to find out if a MST is isolated or becomes
islocated
[65] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25856
<dom> [66]Streams that become isolated generate errors on PC
[66] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25859
assign to Martin
25893
close - don't fix
25957
assign t ojustin
to justin
25975
<dom> [67]Offer Answer options should supported sendOnly and
inactive media states
[67] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25893
<dom> [68]PeerConnection should have an onerror event handler
[68] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25957
still send DTMF?
<dom> [69]When do the value of DTMFSender.canInsertDTMF can
change.
[69] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25975
check reflects the current state
can DTMFsender change?
assigned to Peter
harald file new item
26027
editorial
<dom> [70]addIceCandidate should not be callable when
PeerConnection is closed
[70] https://www.w3.org/Bugs/Public/show_bug.cgi?id=26027
<dom> [71]Options attribute is required for createAnswer
[71] https://www.w3.org/Bugs/Public/show_bug.cgi?id=26279
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> [72]https://github.com/w3c/webrtc-pc/issues
[72] 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
[73]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
[74]http://www.w3.org/2014/10/30-webrtc-minutes.html#action03]
[NEW] ACTION: JIB to propose pull request for replaceTrack
[recorded in
[75]http://www.w3.org/2014/10/30-webrtc-minutes.html#action01]
[NEW] ACTION: Justin to draft pull request on icecandidate
error [recorded in
[76]http://www.w3.org/2014/10/30-webrtc-minutes.html#action05]
[NEW] ACTION: Justin to make pull request on RTPSender.mid
[recorded in
[77]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
[78]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
[79]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
[80]http://www.w3.org/2014/10/30-webrtc-minutes.html#action07]
[NEW] ACTION: varun to review matches between capabilities and
stats [recorded in
[81]http://www.w3.org/2014/10/30-webrtc-minutes.html#action08]
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [82]scribe.perl version
1.137 ([83]CVS log)
$Date: 2014-11-05 15:02:57 $
Received on Wednesday, 5 November 2014 15:05:03 UTC