W3C home > Mailing lists > Public > public-webrtc@w3.org > November 2014

[minutes] Oct 30-31 F2F

From: Dominique Hazael-Massieux <dom@w3.org>
Date: Wed, 05 Nov 2014 16:04:42 +0100
To: public-webrtc@w3.org
Message-Id: <1415199882.4862.2@smtp-mit.w3.org>

The minutes of our F2F last week at TPAC on October 30-31 are availble 
and copied as text below.

Please send corrections to the list.


                         WebRTC F2F (TPAC 2014)

30-31 Oct 2014

   See also: [2]IRC log

      [2] http://www.w3.org/2014/10/30-webrtc-irc


          Harald, Stefan, Alexandre, Dom, DanBurnett, Justin,
          Peter, Martin, EKR, AdamRoach, Jan-Ivar, ShijunS,
          BernardA, Cullen, DanDrutta, DanRomascanu


          HTA, StefanH

          alexG, bernard, jib, dromasca


     * [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

   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
   ... 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

   <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
   ... 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
   ... 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
   ... you use sequence when you want to get something and keep
   ... 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

   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

   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
   ... 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>


   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

   <slide 5>

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

   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

   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

   hta: action is on justin

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

   fluffy: yes, work more on the list before

   hta: accepted as starting point for some more discussion then

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

   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

   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

   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


   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

   <trackbot> Error finding 'JIB'. You can review and register
   nicknames at

     [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

   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

   <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

   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

   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

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

   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

   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
   ... 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

   <trackbot> Error finding 'JIB'. You can review and register
   nicknames at

     [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


   <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

   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

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

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

   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

   <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

   <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

   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

   <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

   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 ?


   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


   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

   <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

   <trackbot> Error finding 'AdamR'. You can review and register
   nicknames at

     [24] 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.

   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

   <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?

   bernarda: take things from XR draft ? next slode


   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

   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?


   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

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

   justin: what impact does nacs have


   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

   <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


   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,

   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

   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

   <trackbot> Created ACTION-119 - Look at our bug tracking
   strategy for webrtc with harald [on Stefan HÃ¥kansson - due

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

   <dom> 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



   <dom> [31]Callbacks need to be called asynchronously

     [31] https://www.w3.org/Bugs/Public/show_bug.cgi?id=19580


   was fixed


   <dom> [32]missing a reference for XMLHttpRequest in 4.1

     [32] https://www.w3.org/Bugs/Public/show_bug.cgi?id=19729

   needs to be assigned


   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


   ekr - needs text to document

   between ontrack and createAnswer

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

   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


   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)



   <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

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

   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


   <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

   is this needed for 1.0

   rtpsender api - resolve later


   <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


   <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


   <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


   varun - identity is there now



   <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


   <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



   <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



   <dom> [46]DataChannel.onerror callback needs an error argument

     [46] https://www.w3.org/Bugs/Public/show_bug.cgi?id=23919

   resolved, will not fix


   needs edit

   todos sumary in section 11

   assign to the editors


   <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


   needs more work, proposal, discussion

   assign to adam


   <dom> [49]MediaStreamTrack.readyState has no muted attribute

     [49] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25440

   dom will make proposal



   h - change definition

   should be documented - editorial


   <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


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

     [52] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25544


   webIDL type checking


   <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


   <dom> [54]steps for createDTMFSender() are missing

     [54] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25576

   assign to editors


   <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


   <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


   25596 - jusitn


   assign to peter

   should be done


   <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




   <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


   assigned to marin



   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



   <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


   <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?


   can fail

   ? remains void, returns exception

   same queue? we do not say that

   h- save changes


   Martin - add attributes


   <dom> [65]Add way to find out if a MST is isolated or becomes

     [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


   close - don't fix


   assign t ojustin

   to justin


   <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

     [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



   <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


   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




   varun - move to the stats doc

   assign to adam


   harald assigns to himself

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

   add MID


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

     [72] https://github.com/w3c/webrtc-pc/issues



   more information needed, justin and cullen not here


   varun - keep simple? what 'simple' means





   already assigned


   same as #5?


   assigned to cullen


   <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
   [NEW] ACTION: JIB to create pull request on promise-based
   hybrid for webrtc [recorded in
   [NEW] ACTION: JIB to propose pull request for replaceTrack
   [recorded in
   [NEW] ACTION: Justin to draft pull request on icecandidate
   error [recorded in
   [NEW] ACTION: Justin to make pull request on RTPSender.mid
   [recorded in
   [NEW] ACTION: martin to give an example of indexed-db key
   retrieval [recorded in
   [NEW] ACTION: stefan to look at our bug tracking strategy for
   WebRTC with harald [recorded in
   [NEW] ACTION: varun to move getStats and associated idl to
   stats doc [recorded in
   [NEW] ACTION: varun to review matches between capabilities and
   stats [recorded in

   [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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:42 UTC