20:25:51 <RRSAgent> RRSAgent has joined #webrtc
20:25:51 <RRSAgent> logging to http://www.w3.org/2014/10/30-webrtc-irc
20:25:54 <alexG> ... if i wanted to get a track and send it at two resolutions
20:25:54 <Zakim> Zakim has joined #webrtc
20:26:00 <dom> RRSAgent, this meeting spans midnight
20:26:01 <alexG> juberti: you need to clone it
20:26:08 <dom> q+ bernard
20:26:11 <alexG> otherwise, you would shave the same msid for both
20:26:12 <dom> q+ stefanh
20:26:14 <dom> q+ burn
20:26:17 <dom> ack bernard
20:26:20 <alexG> bernard: question
20:26:22 <dom> RRSAgent, make logs public
20:26:33 <alexG> bernard: let s say we do that (diff resolution)
20:26:50 <alexG> bernard: what happen with on track on the receiver side?
20:27:19 <alexG> juberti: ontrack is raised, and they would be sync grouping info for the app to know what to do with the other streams.
20:27:50 <dom> ack fluffy
20:28:08 <dom> q+ ekr
20:28:09 <fluffy> q?
20:28:12 <hioh> hioh has joined #webrtc
20:28:35 <alexG> stefan: do we have error here if you provide a track with info about a stream to which the track does not belong to
20:29:00 <alexG> burn: this does not actually create mediastream
20:29:06 <alexG> juberti: sort of
20:29:21 <dom> ack stefanh
20:29:21 <alexG> juberti: if you talk to an endpoint that does not have this maid, it will create it
20:29:23 <dom> ack burn
20:29:34 <hta> s/maid/msid/
20:29:51 <alexG> 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
20:29:59 <alexG> ... in this case, they would have to start learning
20:30:38 <alexG> 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.
20:30:46 <alexG> burn: ....
20:30:56 <alexG> juberti: say you have audio and video tracks in a single stream
20:31:10 <alexG> ... ...
20:31:18 <tidoust> tidoust has joined #webrtc
20:31:34 <alexG> bunr: now that we are talking about tracks as objects, the relationship is not clear.
20:32:16 <alexG> 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.
20:32:18 <dom> q?
20:32:25 <alexG> shijunshun: just to clarify
20:32:37 <alexG> ...
20:32:56 <alexG> juberti: you don t need to create an audio tag, then a video tag, ....
20:33:05 <alexG> ... there is always be at least one stream
20:33:17 <alexG> .. for you to stick into source
20:33:41 <alexG> shijunShun: but when you create the first element, do you already know the element type, or you need to wait?
20:33:43 <dom> ack ekr
20:33:46 <alexG> juberti: no need to wait
20:34:01 <alexG> ekr: .... hum .... i m good
20:34:14 <alexG> <slide 7>
20:35:02 <dom> ekr: what's the plan for deprecating the existing API?
20:35:05 <alexG> ekr: what is the interface? JSL
20:35:15 <dom> juberti: probably the same as for promises
20:35:16 <alexG> juberti: transports
20:35:16 <hta> (JSL=Javascript Library)
20:35:23 <eric_carlson> eric_carlson has joined #webrtc
20:36:02 <alexG> juberti:  global view of transports
20:36:21 <alexG> this allow you to introspect a lot of things
20:36:34 <alexG> before you don t exactly what was the point of failure when something failed
20:36:38 <alexG> now you know per transport
20:37:01 <alexG> ... now you can say directly the kind of connection (relay or not)
20:37:15 <alexG> ... you can now ask what is the dtls certificates being used
20:37:15 <dom> q+ ekr
20:37:29 <alexG> ... for each transport now you can see all those parameters
20:38:05 <alexG> ekr: we need to change the name of RTCIceTransport as we have an existing enum
20:38:15 <alexG> juberti: ok, add "policy" at the end
20:38:19 <alexG> <slide 8>
20:38:34 <alexG> ekr: what about rtcp-mux?
20:39:00 <alexG> juberti: we call it trptransport, but it could be rtcptransport
20:39:01 <kirby> kirby has joined #webrtc
20:39:48 <alexG> juberti: let s move to the API.
20:39:54 <alexG> <slide 9>
20:40:15 <alexG> .. on each sender/receiver you have a DTLSTransport
20:40:25 <alexG> ekr: we need to decide if they are nullable
20:40:41 <alexG> martin: the ugliness will manifest itself during the implementation
20:41:18 <alexG> juberti: if something failed because of dtlsError or iceError, then you can figure it out now.
20:41:29 <alexG> ... there are specific event for each
20:41:41 <alexG> ekr: what about data channel?
20:41:47 <alexG> juberti: glad you asked
20:41:57 <dom> q+ alexG
20:42:00 <dom> ack ekr
20:42:39 <jib> jib has joined #webrtc
20:42:45 <eric_carlson> eric_carlson has joined #webrtc
20:43:00 <jerome> jerome has joined #webrtc
20:43:04 <ShijunS> ShijunS has joined #webrtc
20:43:08 <alexG> martin: what would sftp transport expose?
20:43:12 <alexG> juberti: pretty minimal
20:43:24 <alexG> martin: i like the fact that it s small API.
20:44:22 <dom> ack alexG
20:46:25 <alexG> alexg: so n the specs right now, if a single ice connection fails, at peer connection level we tag all of them as failed
20:46:35 <alexG> ... will we change that now we can se which one failed?
20:46:53 <alexG> juberti: no, since you still need to do an ice restart that will reset all the connections.
20:47:02 <alexG> <slide 10>
20:47:09 <mt1> mt1 has joined #webrtc
20:47:09 <alexG> juberti: encoding parameters
20:47:19 <alexG> ... it covers everything you want to do with the stream
20:47:24 <alexG> ... some of them happen right away
20:47:32 <alexG> ... some of them happen at (re) negociation
20:48:00 <alexG> <slide 11>
20:48:40 <alexG> ... encoding parameters for 1.0
20:49:29 <jib_> jib_ has joined #webrtc
20:49:43 <alexG> dom: why having a dictionary with a single member? do you plan to extend it later?
20:49:46 <alexG> juberti: yes
20:49:56 <dom> q+ ekr
20:50:24 <alexG> bernard: what about this simulcast
20:50:51 <alexG> juberti: it would return a set
20:51:11 <alexG> ekr: do we really want dictionary here?
20:51:21 <fluffy> q+
20:51:23 <alexG> martin: dictionaries are mutable, so ...
20:51:33 <alexG> dom: you might want an array more than sequence.
20:51:46 <alexG> fluffy: for the extensibility thing, we need to pass a string list.
20:51:53 <alexG> ... basically the MTI strings
20:52:26 <alexG> ekr: there must be some way to reject parameters
20:52:53 <alexG> jib: is there any reason not to use attributes?
20:52:57 <alexG> dom: on what?
20:53:01 <alexG> jib: on sender
20:53:06 <saki> saki has joined #webrtc
20:53:14 <jun_ma> jun_ma has joined #webrtc
20:53:20 <alexG> bernard: they have to be consistent
20:53:30 <alexG> jib: i just knw image capture is playing with this
20:53:36 <alexG> burn: they have the same concern
20:53:52 <alexG> fluffy: if you re gonna change 5 things, you don t want 5 renegociation callbacks
20:54:14 <alexG> juberti: but if you wanted errors or callbacks, we would deed to do it as atomic operations
20:54:32 <alexG> <slide 12>
20:54:35 <eric_carlson> eric_carlson has joined #webrtc
20:54:52 <alexG> juberti: example: put people on hold and change the bitrate
20:55:31 <alexG> stefan: how to define bitrate ?
20:55:49 <alexG> fluffy: setting the parameters should be async
20:55:55 <alexG>  jberti: it depends
20:56:10 <alexG> ... we can just make it into a promise
20:56:24 <alexG> hta: if you can t tell immediately wether it failed or not, then make it a promise
20:56:29 <alexG> juberti: fair enough
20:56:36 <alexG> fluffy: you will need that for hardware codec.
20:56:41 <alexG> juberti: probably
20:56:55 <alexG> bernard: get parameters will always return what you put ?
20:57:23 <alexG> juberti: well, no. especially with async, or for things that won't work (11GBPS bitrate)
20:58:03 <alexG> fluffy: there will be times when
20:58:18 <alexG> ... you will try to set values that are not possible, but you still don t want error
20:58:19 <lgombos_> lgombos_ has joined #webrtc
20:58:22 <alexG> ... <example>
20:59:13 <eric_carlson_> eric_carlson_ has joined #webrtc
20:59:23 <tomoyuki> tomoyuki has joined #webrtc
20:59:48 <alexG> <slide 14>
20:59:57 <alexG> juberti: getCapabilities
21:01:31 <alexG> 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
21:02:00 <eric_carlson> eric_carlson has joined #webrtc
21:02:47 <rsun_> rsun_ has joined #webrtc
21:03:23 <alexG> fluffy: question about the semantic
21:03:32 <alexG> ... if i get the capabilities, how long is it valid
21:03:33 <dom> [I think at least using a Typedef would make it somewhat more readable]
21:03:41 <alexG> ekr: assume it is valid for now, and no other premises
21:04:18 <alexG> fluffy: i would prefer that for 1.0 we fix the combinations
21:04:35 <alexG> or at least the most common cases, the one that fall back to what we have today
21:05:27 <alexG> <slide 16>
21:05:41 <alexG> rtpSender.track
21:05:52 <alexG> juberti: it is readonly in current API
21:06:21 <alexG> ... if we were to make it mutable, it makes for an easy solution to "how to switch between front and back camera"
21:06:27 <alexG> <slide 17>
21:07:10 <alexG> hta: if the new track is different from the old track in any way .....
21:07:27 <alexG> jib: in firefox we have a replacetrack() that s async, but is doe snot have to be
21:07:31 <alexG> jib: could fail
21:07:58 <alexG> martin: if you had a 264 encoded track, that you want to replace with a non-264 track ? it wouldn t work right?
21:08:04 <alexG> juberti: yes, it wouldn t work.
21:08:15 <alexG> martin: so ... you just stop sending?
21:08:17 <alexG> juberti: yes.
21:08:33 <alexG> ... at least you don t renegociate
21:08:48 <alexG> .. the MSID then must be the same
21:09:07 <alexG> ... but sender/receiver are already associated with a m=line
21:09:46 <alexG> fluffy: well, then anything that would trigger a renegociation event would then fail, for speed sake.
21:10:29 <schuki> schuki has joined #webrtc
21:12:30 <alexG> juberti: now we can correlate between rtpsender and receiver, without the need for other info
21:12:50 <DanD> DanD has joined #webrtc
21:12:51 <alexG> hta msid is used for two things
21:13:12 <alexG> ... now, with this mid, some things become redundant
21:13:52 <alexG> martin: I think this is workable.
21:14:20 <myakura> myakura has joined #webrtc
21:16:01 <alexG> <slide 18>
21:16:15 <alexG> juberti: rtpSender.mid/msid
21:17:17 <timpanton> timpanton has joined #webrtc
21:17:37 <alexG> 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
21:18:01 <alexG> <slide 5>
21:18:12 <alexG> juberti: that s the current pull request
21:18:29 <alexG> ... and except for the array vs sequence thing, there was a consensus.
21:18:42 <eric_carlson> eric_carlson has joined #webrtc
21:18:59 <alexG> hta: modulo the array and getter discussion, does this to be acceptable to be in the spec.
21:19:12 <alexG> fluffy: well, we agreed to go this direction one year ago.
21:19:24 <alexG> ... this is very different from looking at the pull request.
21:19:47 <alexG> hta: shall the spec include this without asking the whole group again.
21:19:57 <alexG> juberti: let s put it into the spec.
21:20:06 <alexG> fluffy: but we will need to discuss the details
21:20:09 <alexG> everybody: right
21:20:10 <claudio_> claudio_ has joined #webrtc
21:20:29 <alexG> hta: go down to API transport
21:20:46 <alexG> ... my feeling is that it is less mature in people minds
21:21:02 <alexG> burn: we also know there will need to be duplication between ftp and rtcp
21:21:25 <alexG> fluffy: at this conceptual level, I think there is the same level of consensus: solve the small details and put it in the specs.
21:21:34 <alexG> hta: action is on justin
21:21:50 <alexG> burn: i would love more from justin before we put it in the specs
21:21:57 <alexG> fluffy: yes, work more on the list before
21:21:58 <dom> s/ftp/rtp/
21:22:20 <alexG> hta: accepted as starting point for some more discussion then integration
21:22:34 <alexG> dom: is it something we want for 1.0 and is it in the right direction?
21:22:58 <alexG> hta: so the encoding parameters ....
21:23:44 <alexG> fluffy: ...
21:24:12 <dom> s/.../I would want to think about which attributes should be part of the 1.0 set
21:24:15 <alexG> hta: my worry is: if we try to handle all the possible cases, we will never make it for 1.0
21:24:49 <alexG> fluffy: i want to think about what a minimal thing is before I agree for this.
21:25:12 <alexG> 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.
21:26:03 <alexG> bernard: my only concern here is the interaction between setting and getting.
21:26:55 <alexG> dom: looks like a pull request for discussion is interesting, but it wouldn t be a pull reuest that will be integrated
21:27:27 <alexG> juberti: i think that if I address the three things that were mentioned today, we re in good shape.
21:27:33 <alexG> hta: it is a feature request then.
21:27:49 <alexG> hta: next one in the list is getCapabilities()
21:28:45 <alexG> martin: we want something very simple, that supports what we can do today.
21:28:59 <wy> wy has joined #webrtc
21:29:01 <eric_carlson_> eric_carlson_ has joined #webrtc
21:30:39 <alexG> fluffy: would we clock rate be used?
21:30:50 <alexG> juberti: wide band codec
21:31:07 <wy> wy has joined #webrtc
21:31:18 <alexG> fluffy: clock rate might be the wrong name: sample rate?
21:33:03 <alexG> ekr: ekr: i m ok with that the way it is now, but be ready for extension
21:34:00 <alexG> hta: what i suggest to do is to make it a feature reuest, because it does not feel clear enough what we want.
21:34:24 <alexG> matrin: i would rather start with this, and drop things.
21:34:48 <alexG> burn: this itself is a feature request
21:34:57 <alexG> ekr: this is important for 1.0
21:35:21 <dom> s/for 1.0/, we should consider it for 1.0/
21:35:23 <alexG> juberti: the only structural issue is the extension of getCapabilities, so it makes me feel that we are on the right track
21:36:21 <alexG> fluffy, i think we should drive it into two questions: is this extensible enough for a complex codec.
21:36:45 <alexG> ... and is it simple enough to do the minimal case without too much oerhead
21:36:47 <alexG> overhead
21:37:42 <alexG> hta: we are back on being late on schedule.
21:38:23 <alexG> ... RtpSender.track
21:38:40 <alexG> martin: the only question is only wether we want a get or a function is the only thing remaining
21:38:58 <alexG> hta: ok. propose to the list.
21:39:18 <alexG> dom: are we at the state of making a pull request then?
21:39:21 <alexG> martin: yes
21:39:34 <alexG> hta: action: prepare a pull request, and discuss
21:39:41 <alexG> hta: who takes the action item?
21:39:45 <dom> ACTION: JIB to propose pull request for replaceTrack
21:39:45 <trackbot> Error finding 'JIB'. You can review and register nicknames at <http://www.w3.org/2011/04/webrtc/track/users>.
21:39:45 <alexG> jib: i can take that.
21:40:23 <alexG> juberti: API RtpSender/Receiver/mid/msid
21:40:58 <alexG> martin: i m not a big fan of it, but i won't oppose it either.
21:41:39 <alexG> 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.
21:42:06 <alexG> fluffy: if we understand why we need msid, that would help here.
21:42:35 <alexG> martin: I d like to keep mid, and then think about wethe ewe need maid later
21:42:42 <alexG> maid -> msid
21:42:43 <dom> ACTION: Justin to make pull request on RTPSender.mid
21:42:43 <trackbot> Created ACTION-114 - Make pull request on rtpsender.mid [on Justin Uberti - due 2014-11-06].
21:42:53 <alexG> juberti: I will take care of the pull request
21:44:48 <alexG> hta let s take a break and be back at 3 sharp
21:45:53 <ken> ken has joined #webrtc
21:59:28 <claudio_> claudio_ has joined #webrtc
22:04:47 <ekr> ekr has joined #webrtc
22:06:14 <shinwoo> shinwoo has joined #webrtc
22:07:30 <ken> ken has joined #webrtc
22:08:15 <hta> scribenick bernarda
22:11:00 <dom> dom has joined #webrtc
22:12:10 <bernard> bernard has joined #webrtc
22:12:22 <bernard> Why add promises?
22:12:26 <gludi|2> gludi|2 has joined #webrtc
22:12:35 <bernard> What is proposed - example of how promises could be used instead of success/failure callbacks.
22:12:44 <bernard> Eric:  Can we not debate whether this is superior?
22:12:54 <bernard> Another example with mediaCapture
22:13:21 <bernard> An example with WebIDL overloading.
22:14:54 <bernard> Shijun: Promise is in Media Capture already?  Yes.
22:15:52 <bernard> 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?
22:16:06 <bernard> Adam:  Can't we mandate that?
22:16:09 <ShijunS> ShijunS has joined #webrtc
22:18:06 <jerome> jerome has joined #webrtc
22:18:28 <bernard> Strength of promise is way better error handling.
22:19:21 <mt1> I wouldn't characterize this as "way better", just easier
22:19:21 <bernard> 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.
22:19:55 <bernard> EKR:  Why not just give them different names?  Then the problem with callbacks goes away.
22:20:11 <bernard> Adam: I would argue that moving to the promise model we don't have that enforcement anyway...
22:20:45 <bernard> EKR:  You are importing this misfeature from promises and now we have to live with it in callbacks...
22:21:08 <bernard> EKR:  We were trying to make people acknowledge errors by making the failure callback mandatory...
22:22:01 <bernard> Martin:  We have so much code out there that we could create problems....
22:22:34 <bernard> 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.
22:23:15 <bernard> Martin:  Both promises and callbacks.
22:23:41 <bernard> Cullen:  I am against having two ways to do the same thing.
22:24:29 <bernard> EKR:  My argument is that this text is controversial and it doesn't become a commitment...
22:24:49 <bernard> Cullen:  I was talking about the text Dan wrote in the current document.
22:25:35 <bernard> Dan:  In the text, I tried to be compatible with the group sentiment, understanding that you (EKR) was unhappy with it.
22:26:12 <dromasca> dromasca has joined #webrtc
22:26:17 <bernard> Slide on Hybrid approach.
22:26:50 <bernard> Stefan: Should we nove to promises... I hear we should move to promises.
22:27:10 <bernard> Justin:  We should add support for promises for the 4 or 5 methods we have identified... and keep callbacks so things keep working.
22:27:24 <bernard> Bernarda:  That makes more sense to me.
22:27:38 <bernard> Justin:  Keep existing things so as not to break the system.
22:28:11 <bernard> Justin:  If you want callbacks and promises in your code... have at it (not recommended, though).
22:28:51 <jib> jib has joined #webrtc
22:29:05 <bernard> Martin:  The fact that there are promises elsewhere and not callbacks is a hint to developers.
22:29:20 <bernard> Dan:  We can recommend the promise model where both are possible.
22:29:44 <bernard> EKR:  I would be satisfied with the first half of this note...
22:29:57 <bernard> Harald:  An agenda item for tomorrow's session on media capture.
22:30:12 <bernard> EKR:  In context of this... are we happy with the first paragraph?
22:30:38 <bernard> EKR:  I would be satsfied with a rewrite of the last paragraph.
22:31:06 <bernard> Stefan:  Who has the action to draft it?
22:31:14 <bernard> Martin:  There is a pull request... that has changed.
22:31:25 <bernard> Stefan:  Can we get a pull request for your proposal?
22:31:33 <bernard> If they have Internet on the plane....
22:31:52 <bernard> Martin:  Is there urgency on this?  Other than making progress ?
22:32:00 <bernard> JanIvar:  Left out getStats().
22:32:38 <dom> ACTION: JIB to create pull request on promise-based hybrid for webrtc
22:32:38 <trackbot> Error finding 'JIB'. You can review and register nicknames at <http://www.w3.org/2011/04/webrtc/track/users>.
22:32:55 <bernard> Stefan:  Next item:  DTLS certirficates.
22:33:11 <dom> Topic: DTLS certificates
22:33:47 <timpanton> Are the slides viewable somewhere for DTLS certs  ?
22:34:11 <jib_> jib_ has joined #webrtc
22:34:32 <bernard> Justin:  Keep callbacks, add classes to describe methods  and add promises for all new methods.
22:34:45 <bernard> Martin:  Certificate Selection API.
22:34:51 <dom> -> http://lists.w3.org/Archives/Public/public-webrtc/2014Oct/att-0101/keys.pdf Martin's slides
22:35:01 <timpanton> Thanks.
22:35:10 <bernard> options:  one cert per original, per RTCPeerConnection.
22:35:31 <bernard> Firefox generates a new certificate for each RTCPeerConnection.
22:36:05 <bernard> Martin: same cert over time OR different certs over time.
22:36:43 <bernard> Same cert allows for key continuity.
22:37:13 <bernard> Different certs allow sites to break correlation between sessions
22:37:55 <bernard> Proposal:  use new API to generate WebCrypto keys... PC API generates a cert based on those keys...
22:40:29 <bernard> Shijun:  private keys are stored and managed by user agent and are off limits
22:40:37 <bernard> Martin:  They would be non-exportable.
22:41:46 <bernard> Martin:  How it works.  Call a key generation function then construct RTCPeerconnectgion with "theKey".
22:42:17 <bernard> Shijun:  You could reuse the same set of keys for multiple RTCPeerConnection?
22:42:21 <bernard> Martin:  You could.
22:43:14 <bernard> Martin:  This key is only accessible to your origin.
22:44:06 <bernard> Cullen:  IndexDB doesn't show how you store stuff you can't look at.
22:44:14 <bernard> EKR:  You store the object in IndexDB.
22:44:43 <bernard> JanIvar:  What types is the key?  cryptoKeyPair
22:44:51 <tomoyuki> tomoyuki has joined #webrtc
22:45:00 <bernard> Martin:  There is no getPrivateKey method.
22:45:12 <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.
22:45:41 <timpanton> conversely, can the .generate() function control what is in the key ?
22:46:00 <ShijunS> q?
22:46:10 <fluffy> q?
22:46:13 <fluffy> q-
22:46:17 <ShijunS> q+
22:46:34 <timpanton> q+
22:46:47 <auchenberg> auchenberg has joined #webrtc
22:47:28 <dom> ACTION: martin to give an example of indexed-db key retrieval
22:47:28 <trackbot> Created ACTION-115 - Give an example of indexed-db key retrieval [on Martin Thomson - due 2014-11-06].
22:47:33 <fluffy> q?
22:47:33 <dom> ack ekr
22:47:37 <dom> ack ShijunS
22:47:48 <shige> shige has joined #webrtc
22:48:13 <timpanton> (no audio here I'm afraid - can some one voice me?)
22:48:29 <bernard> Shijun:  other side might be an existing legacy system.  Any problem with that?
22:48:45 <bernard> Martin:  Can have a negotiation failure... but this API is for grownups.
22:48:52 <bernard> Peter:  Does it return immediately?
22:48:57 <dom> Zakim, who's on the phone?
22:48:57 <Zakim> sorry, dom, I don't know what conference this is
22:48:58 <Zakim> On IRC I see shige, auchenberg, tomoyuki, jib, dromasca, jerome, ShijunS, bernard, dom, ken, shinwoo, ekr, claudio_, timpanton, myakura, DanD, schuki, lgombos_, saki, mt1, Zakim,
22:48:58 <Zakim> ... RRSAgent, stefanh, fluffy, varun, hta, sam_, alan-i, adamR, burn, panzana`, richt, Josh_Soref, derf_, stryx`, slightlyoff, timeless, decadance, trackbot
22:49:02 <bernard> Martin:  First one is a promise....
22:49:31 <timpanton> tricky - house full of sleeping folks.
22:50:31 <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."
22:51:02 <ShijunS> q-
22:51:21 <timpanton> conversely, can the .generate() function control what is in the key ?
22:51:25 <bernard> EKR:  The browser has no way of populating that stuff....
22:51:44 <bernard> EKR:  The way to deal with that ... servers can do that... but not browsers.
22:52:01 <Ruinan> Ruinan has joined #webrtc
22:52:12 <timpanton> Thanks.
22:52:14 <timpanton> q-
22:53:45 <bernard> Dominique sweating...
22:53:53 <bernard> Martin:  It is really hot in here!
22:54:04 <bernard> Dan:  We asked to turn down the AC... they turned it OFF!
22:55:17 <bernard> Martin:  I imagine it will be used once when you decide to talk to someone...
22:55:31 <bernard> Dan:  Does the programmer need to remember if this has been done before?
22:57:01 <bernard> Martin:  20 lines of text to be added to the spec....
22:57:55 <bernard> Martin:  Choosing keys... if no keys are provided they are generated  RTCPeerconnection picks a suitable key fro what is presented.. it might choose several.
22:58:58 <bernard> HTA:  Do we have agreement on major pieces ?
22:59:42 <bernard> Answer:
22:59:52 <bernard> Justin:  Google uses a different key per origin.
23:00:04 <bernard> EKR:   Mozilla uses different key for each RTCPeerConnection.
23:00:23 <bernard> Cullen:  If it takes more than 3 seconds on nobile phones... don't want it.
23:01:24 <bernard> Martin:  Will generate a pull request for review.
23:03:19 <claudio_> s/nobile/mobile/
23:06:42 <ken> ken has joined #webrtc
23:07:22 <ken> ken has joined #webrtc
23:09:16 <ken_> ken_ has joined #webrtc
23:20:03 <shinwoo> shinwoo has joined #webrtc
23:20:13 <song__> song__ has joined #webrtc
23:20:29 <alan-i_> alan-i_ has joined #webrtc
23:23:07 <ken> ken has joined #webrtc
23:26:26 <burn> burn has joined #webrtc
23:28:46 <bernarda> bernarda has joined #webrtc
23:28:49 <dom> ScribeNick: jib
23:28:57 <bernarda> Erorrs in ICE gathering
23:29:02 <ken_> ken_ has joined #webrtc
23:29:10 <dom> Topic:  How to handle errors during the ICE gathering phase
23:29:19 <dom> -> https://www.w3.org/2011/04/webrtc/wiki/images/a/a7/ICE_gathering_phase_errors.pdf justin's slides
23:29:31 <bernarda> JS has no idea what went wrong (becuase of bad TURN Sever), but would like to know when it works too.
23:29:31 <bernarda> Want a success and failutre event
23:29:35 <masatakayakura> masatakayakura has joined #webrtc
23:29:58 <bernarda> Proposal;  Add a url to the IceEvent to say what ICE server the candidate is from
23:30:18 <bernarda> Solution A: Generic onerror event.
23:30:42 <alexG> alexG has joined #webrtc
23:30:50 <dom> s/ScribeNick: jib/ScribeNick: bernarda
23:31:15 <bernarda> When:  We would have a type (e.g. "ice-gather" "bad-credentials", etc.
23:31:27 <dom> [nit: "int" is not a type in WebIDL]
23:31:28 <bernarda> uri of the TURN/STUN server in question.
23:31:34 <bernarda> Also, reason code
23:32:04 <bernarda> Solution B: is IceCandidateErrorEvent (specific to ICE)
23:32:20 <bernarda> again, with url, reason, description
23:32:52 <saki__> saki__ has joined #webrtc
23:33:06 <bernarda> Martin:  General approach - is it just for ICE?
23:34:25 <bernarda> Justin:  Given we have no clear second usage am inclined toward specific solution.
23:34:27 <ekr> ekr has joined #webrtc
23:35:12 <bernarda> HTA:  Seems odd to have this particular error be different from the usual error event
23:35:14 <myakura> myakura has joined #webrtc
23:35:30 <bernarda> Justin:  We could just replace description with containing an error object.
23:36:11 <bernarda> Justin:  Should we derive it fron an existing error event?  Or include an existing event in the structure?
23:36:50 <bernarda> EKR:  These are all gathering errors.
23:40:45 <ken> ken has joined #webrtc
23:42:31 <claudio> claudio has joined #webrtc
23:42:55 <tidoust> tidoust has joined #webrtc
23:43:52 <ekr1> ekr1 has joined #webrtc
23:45:14 <jib> abr: Look to XHR as model
23:45:20 <jib> justion: not a pretty model
23:45:34 <jinkyu_seong> jinkyu_seong has joined #webrtc
23:45:43 <jib> ekr: Suggest we leave the question of how to encode error to editor discretion
23:46:19 <dom> ACTION: Justin to draft pull request on icecandidate error
23:46:19 <trackbot> Created ACTION-116 - Draft pull request on icecandidate error [on Justin Uberti - due 2014-11-06].
23:47:02 <dom> ACTION: AdamR to look at how to represent network error on ICE gathering based on XHR/Fetch/WebSockets
23:47:02 <trackbot> Error finding 'AdamR'. You can review and register nicknames at <http://www.w3.org/2011/04/webrtc/track/users>.
23:47:50 <som> som has joined #webrtc
23:48:02 <dom> ScribeNick: jib
23:48:42 <jib> Topic: Stats
23:49:58 <jib> varun: RTCStatsType: there is one in the peerConnection doc as well. Needs to move out of stats doc, as I understood. opinions?
23:50:24 <jib> dom: it’s in the idl of the getStats
23:50:56 <jib> … move all of getStats to stats doc
23:51:06 <dom> ACTION: varun to move getStats and associated idl to stats doc
23:51:06 <trackbot> Created ACTION-117 - Move getstats and associated idl to stats doc [on Varun Singh - due 2014-11-06].
23:51:35 <jib> varun: stats dictionaries correspond to data in various internal components
23:52:24 <jib> … open issues: inbound stats have a lots of RTP values but not fractionLost
23:52:51 <jib> hta: is it since last time or a consistent value?
23:52:57 <jib> varun: consistent value at any time
23:53:40 <jib> … additional metrics: packetsDiscarded? packetsRepaired? opinions?
23:53:46 <auchenbe_> auchenbe_ has joined #webrtc
23:54:09 <jib> bernarda: take things from XR draft ? next slode
23:54:11 <alan-i> alan-i has joined #webrtc
23:54:11 <jib> slide
23:54:46 <auchenbe_> auchenbe_ has joined #webrtc
23:54:58 <jib> varun: RTCDataChannelState - is odd:  other areas we usually only measure payload, not headers
23:55:21 <jib> … (bytesSent/Received) include headers or not?
23:55:30 <jib> .. suggest just payload
23:55:33 <auchenberg> auchenberg has joined #webrtc
23:56:17 <jib> .. open issue: RTCCodec.kind?
23:56:34 <jib> … instead of codec
23:56:38 <auchenbe_> auchenbe_ has joined #webrtc
23:56:48 <jib> hta: good idea. breaking up codec type = bad idea
23:57:01 <jib> ekr: kind: video codec vp8?
23:57:03 <jib> hta: yes
23:57:18 <auchenbe_> auchenbe_ has joined #webrtc
23:57:29 <jib> mt: break up info in the m-line or not?
23:57:40 <jib> hta: broken up because RTP does
23:58:10 <jib> … its a bad design that the m-lines contain the top level types
23:58:12 <jib> mt: agree
23:58:25 <jib> berndarda: things that don’t have a kind
23:59:24 <jib> justin: splitting sounds good
23:59:52 <jib> hta: does kind belong up in mediatrack stat?
00:00:09 <jib> jib: jib: i agree
00:00:50 <jib> hta: move kind to mediastreamtrack stat
00:01:41 <jib> next steps
00:01:54 <jib> varun: missing metrics?
00:02:15 <jib> (silence)
00:02:24 <jib> next slide: References
00:03:20 <jib> ekr: better to put stats in same doc?
00:03:38 <jib> burn: I’d love to keep getStats in there but it’s hard
00:04:03 <jib> varun: thanks
00:04:12 <tidoust> tidoust has joined #webrtc
00:05:46 <jib> varun: fractionLost should be kept. No interest in packetsDiscarded/Repaired
00:05:52 <ken> ken has joined #webrtc
00:06:33 <jib> … discrarded is like if you have a jitter buffer and you have to discard it
00:07:12 <jib> justin: what impact does nacs have
00:07:17 <jib> fec
00:07:42 <jib> .. we expose stats on how many we use conceilment on
00:07:55 <jib> .. neteq, jitterbuffer
00:08:08 <jib> .. one for expansion based on, partial recover…
00:09:04 <juberti> juberti has joined #webrtc
00:09:25 <jib> varun: RTCCodec would have a mimeType instead of codec, and (what was the second part?)
00:09:35 <jib> hta: kind up there
00:09:58 <jib> justin: should make capabilities and stats match
00:10:12 <jib> hta: someone should review the match and see
00:10:27 <jib> … varun to take action
00:10:30 <dom> ACTION: varun to review matches between capabilities and stats
00:10:31 <trackbot> Created ACTION-118 - Review matches between capabilities and stats [on Varun Singh - due 2014-11-07].
00:16:25 <auchenberg> auchenberg has joined #webrtc
00:48:25 <myakura> myakura has joined #webrtc
01:03:30 <Zakim> Zakim has left #webrtc
01:13:57 <jerome> jerome has joined #webrtc
01:13:58 <varun> varun has joined #webrtc
01:15:07 <tidoust> tidoust has joined #webrtc
01:19:36 <tidoust2> tidoust2 has joined #webrtc
01:35:03 <ken> ken has joined #webrtc
02:32:03 <ekr> ekr has joined #webrtc
02:37:42 <ekr> ekr has joined #webrtc
02:48:27 <auchenberg> auchenberg has joined #webrtc
03:01:42 <lgombos_> lgombos_ has joined #webrtc
03:03:45 <ekr> ekr has joined #webrtc
03:08:11 <ekr> ekr has joined #webrtc
03:27:48 <jib> jib has joined #webrtc
03:34:11 <adamR> adamR has joined #webrtc
04:01:30 <auchenberg> auchenberg has joined #webrtc
05:19:47 <ekr> ekr has joined #webrtc
05:22:07 <auchenberg> auchenberg has joined #webrtc
06:04:20 <adamR> adamR has joined #webrtc
06:06:50 <myakura> myakura has joined #webrtc
06:37:18 <ken> ken has joined #webrtc
06:53:38 <tidoust2> tidoust2 has joined #webrtc
06:56:42 <tidoust3> tidoust3 has joined #webrtc
07:05:52 <auchenberg> auchenberg has joined #webrtc
07:10:42 <myakura> myakura has joined #webrtc
07:48:01 <ken> ken has joined #webrtc
07:58:08 <ken> ken has joined #webrtc
09:25:14 <sam> sam has joined #webrtc
09:26:21 <sam_> sam_ has joined #webrtc
09:47:47 <ken> ken has joined #webrtc
09:49:03 <ken_> ken_ has joined #webrtc
10:09:59 <shinwoo> shinwoo has joined #webrtc
10:10:03 <shinwoo> ,minutes
10:10:37 <shinwoo> .minutes
10:10:42 <shinwoo> ;minutes
10:10:47 <shinwoo> :minutes
10:18:18 <ken> ken has joined #webrtc
10:20:07 <ken_> ken_ has joined #webrtc
11:20:50 <ken> ken has joined #webrtc
11:47:04 <myakura> myakura has joined #webrtc
12:21:38 <ken> ken has joined #webrtc
12:22:09 <lgombos_> lgombos_ has joined #webrtc
12:23:25 <ken> ken has joined #webrtc
12:40:36 <eric_carlson> eric_carlson has joined #webrtc
12:51:43 <lgombos_> lgombos_ has joined #webrtc
13:15:37 <eric_carlson> eric_carlson has joined #webrtc
13:24:09 <ken> ken has joined #webrtc
13:33:05 <varun> varun has joined #webrtc
13:37:45 <ekr> ekr has joined #webrtc
13:58:54 <hta> hta has joined #webrtc
14:09:52 <eric_carlson> eric_carlson has joined #webrtc
14:12:10 <adamR> adamR has joined #webrtc
14:17:24 <adamR_> adamR_ has joined #webrtc
14:24:54 <ken> ken has joined #webrtc
14:37:13 <ekr> ekr has joined #webrtc
14:48:57 <ekr1> ekr1 has joined #webrtc
14:54:45 <varun> varun has joined #webrtc
14:55:21 <ekr> ekr has joined #webrtc
15:08:42 <adamR> adamR has joined #webrtc
15:11:48 <adamR_> adamR_ has joined #webrtc
15:12:45 <ken> ken has joined #webrtc
15:14:27 <mt> mt has joined #webrtc
15:15:26 <hta> hta has joined #webrtc
15:28:11 <ekr> ekr has joined #webrtc
15:31:07 <myakura> myakura has joined #webrtc
15:35:11 <burn> burn has joined #webrtc
15:35:38 <dom> dom has joined #webrtc
15:36:27 <dom> RRSAgent, this meeting spans midnight
15:36:39 <dromasca> dromasca has joined #webrtc
15:36:43 <dom> ScribeNick: dromasca
15:36:56 <dom> Topic: Bugs Walkthrough
15:37:06 <dromasca> status of the bug tracker
15:37:16 <dromasca> harald = h
15:37:37 <varun> varun has joined #webrtc
15:37:41 <dromasca> bugzilla 47 bugs open
15:37:49 <dom> -> 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 WebRTC open bugs list
15:38:03 <dromasca> 7 issues in github tracker
15:38:24 <dromasca> classes of bugs
15:38:43 <dromasca> errors in the spec - got to fix
15:39:00 <dromasca> request for functionality - essential to add
15:39:01 <jerome> jerome has joined #webrtc
15:39:15 <dromasca> unessentia - wg needs to decide
15:39:17 <tidoust> tidoust has joined #webrtc
15:39:37 <dromasca> proposed methodology - bug tracker on screen, look at bugs, categorize
15:40:23 <dromasca> discuss or assign someone to take care of it?
15:40:27 <dromasca> makes sense?
15:41:23 <dromasca> yesterday's not yet in? - no
15:41:56 <alan-i> alan-i has joined #webrtc
15:42:21 <dromasca> ekr - github - should we use only one tracker? issue?
15:42:48 <dromasca> h: got to get rid of this stuff
15:43:07 <dromasca> s - people like to have one tool
15:43:28 <tidoust2> tidoust2 has joined #webrtc
15:43:38 <dromasca> document bug or discuss
15:43:40 <tomoyuki> tomoyuki has joined #webrtc
15:44:25 <dromasca> a, ekr - use tracker stuff is different than reports than requests
15:45:00 <dromasca> github easier to track, link, include
15:45:16 <dromasca> dom - other wgs in w3c working with github
15:46:08 <dromasca> issues different than discussions, no single w3c policy
15:46:09 <dromasca> can it be linked to mail list?
15:46:15 <dromasca> there is a tool to do it
15:46:33 <dromasca> we are not just talking about editorial
15:47:03 <varun_> varun_ has joined #webrtc
15:47:11 <dromasca> everything that is substance needs mail list
15:48:03 <dom> ACTION: stefan to look at our bug tracking strategy for WebRTC with harald
15:48:03 <trackbot> Created ACTION-119 - Look at our bug tracking strategy for webrtc with harald [on Stefan Håkansson - due 2014-11-07].
15:48:07 <dromasca> chairs - stay with this tool while experimenting - update the statements accordingly
15:48:22 <dom> 15861
15:48:31 <dromasca> 15861
15:48:50 <dom> -> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15861 API for JS interaction with congestion control
15:48:57 <dromasca> proposal yesterday real-time interaction with cc
15:49:20 <dromasca> per encoding - needs text
15:50:15 <dom> -> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17287 PeerConnectionErrorCallback argument
15:50:19 <dromasca> 17287
15:51:05 <dromasca> close
15:51:28 <dom> -> https://www.w3.org/Bugs/Public/show_bug.cgi?id=19580  Callbacks need to be called asynchronously
15:51:32 <dromasca> 19580
15:51:43 <dromasca> was fixed
15:51:58 <dromasca> 19729
15:52:29 <dom> -> https://www.w3.org/Bugs/Public/show_bug.cgi?id=19729 missing a reference for XMLHttpRequest in 4.1 Introduction
15:52:45 <dromasca> needs to be assigned
15:52:53 <juberti> juberti has joined #webrtc
15:53:08 <dromasca> 20806
15:53:23 <ken> ken has joined #webrtc
15:53:57 <dromasca> security consideration text - needs review
15:54:06 <dom> -> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20806 Section 15 (Security Considerations) is empty
15:54:49 <dromasca> dom to review
15:55:01 <dom> -> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20809 Stream rejection not possible
15:55:03 <dromasca> 20809
15:55:55 <dromasca> ekr - needs text to document
15:56:34 <dromasca> between ontrack and createAnswer
15:57:26 <dromasca> j: what happens in a two-way track if one side rejected from remote?
15:57:38 <dromasca> stays on hold?
15:57:49 <dromasca> bernar d- in stp there is no difference
15:57:55 <dom> s/stp/sdp/
15:58:06 <dromasca> needs to indicate the difference
15:59:46 <dromasca> for inactive - both sides clear, what happens in the one side case, how it's signaled in sdp?
16:00:31 <dromasca> h- propose text, example
16:00:36 <dromasca> to assign later
16:00:45 <dromasca> 20811
16:01:12 <dromasca> what rtp profile is mti?
16:01:23 <dom> -> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20811 RTP usage not defined
16:01:25 <dom> (just needs closing)
16:01:29 <dromasca> 20816
16:01:39 <dromasca> hold
16:01:59 <dom> -> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20816  	"Hold" unspecified
16:02:37 <dromasca> send only / receive only states
16:02:55 <dromasca> assign to justin
16:03:30 <dromasca> muting a track is a local event only, hold changes to receive only
16:03:36 <rsun> rsun has joined #webrtc
16:03:45 <jerome_> jerome_ has joined #webrtc
16:04:02 <dromasca> ekr - is there a need in the api to say remote side stop sending
16:04:15 <dromasca> can phones do this now?
16:04:24 <dromasca> this can be done in the app
16:05:17 <JINGWang_qi> JINGWang_qi has joined #webrtc
16:05:39 <dromasca> important enough to do spec
16:06:18 <dromasca> send only can be done with existing api
16:06:54 <dromasca> assign to justin
16:07:05 <dromasca> 20819
16:07:15 <dom> -> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20819  no priority API
16:07:18 <dromasca> no priority api
16:08:20 <dromasca> app level priorities, not dscp
16:08:35 <dromasca> 4 level proposal
16:08:55 <dromasca> proposal in the rtcweb transport
16:09:10 <jib> jib has joined #webrtc
16:09:27 <dromasca> we just need the api - simple - behavior defined in the ietf spec
16:09:34 <dromasca> is this needed for 1.0
16:10:29 <dromasca> rtpsender api - resolve later
16:10:47 <dromasca> 21086
16:11:01 <dom> -> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21086 --- 	getLocalStreams and getRemoteStreams should return empty sequence after Peerconnection::close
16:11:51 <dromasca> leave open
16:11:54 <dromasca> 21877
16:12:17 <dom> -> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21877 API is unable to handle inbound streams prior to arrival of answer
16:15:05 <dromasca> offer public address or browser - different cases
16:15:39 <dromasca> h - any change in the api to fix this?
16:15:50 <dromasca> send information about stuff that cannot be handled
16:17:04 <dromasca> bd - announce big stuff arriving
16:17:28 <dromasca> a - partial information about the track, when more info arrives needs to update
16:18:24 <dromasca> h - give the implementation the option of holding the data until get an answer
16:18:45 <dromasca> sometimes the time window is too short
16:18:50 <eric_carlson> eric_carlson has joined #webrtc
16:19:19 <dromasca> the only api change - indication in the header, stuff arrived, i could not handle it
16:19:59 <dromasca> j - looks like a short-time solution
16:21:20 <dromasca> covers a short spectrum of scenarios
16:21:35 <dromasca> assign martin to write text
16:21:58 <dromasca> s/short/whole
16:24:12 <dromasca> 1.0 scope
16:24:32 <dromasca> 21878
16:24:51 <dom> -> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21878 Unable to learn of unknown inbound media
16:25:03 <wy> wy has joined #webrtc
16:25:42 <dromasca> overtaken by events?
16:25:50 <dom> -> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21879 Unable to access certificate information in the API
16:25:54 <dromasca> 21879
16:26:44 <dromasca> varun - identity is there now
16:27:12 <dromasca> solved
16:27:17 <dromasca> 21880
16:28:09 <dom> -> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21880 Certificate management is underspecified
16:28:46 <dromasca> attach to the proposal made yesterday
16:28:55 <dromasca> assign to martin
16:29:02 <dromasca> 22441
16:29:25 <dom> -> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22441 Bug in section 8.1.2 Requesting Assertions
16:29:49 <jmr_> jmr_ has joined #webrtc
16:30:25 <dromasca> assign to martin
16:30:30 <dom> -> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22442 Bug in section 8.1.3 Verifying Assertions
16:30:31 <dromasca> 22442
16:30:42 <dromasca> same
16:30:57 <dom> -> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23832 Requiring that negotiated channels be created on the receiver before any data can be received is problematic for some use cases
16:31:05 <dromasca> 23832
16:31:39 <dromasca> close
16:31:55 <dom> -> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23919 DataChannel.onerror callback needs an error argument specified.
16:32:00 <dromasca> resolved, will not fix
16:32:02 <dromasca> 23919
16:34:07 <dromasca> needs edit
16:34:35 <dromasca> todos sumary in section 11
16:35:48 <dromasca> assign to the editors
16:35:54 <dromasca> 23920
16:36:19 <dom> -> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23920 TURN authentication failures should be surfaced as some event
16:36:35 <dromasca> assign t ojustin
16:36:40 <dromasca> to justin
16:36:44 <dom> -> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25102 RTCDataChannel::send() steps are not proper.
16:36:46 <dromasca> 25102
16:37:41 <claudio> claudio has joined #webrtc
16:40:27 <dromasca> needs more work, proposal, discussion
16:40:31 <dromasca> assign to adam
16:40:41 <dromasca> 25440
16:40:43 <dom> -> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25440 MediaStreamTrack.readyState has no muted attribute
16:42:58 <dromasca> dom will make proposal
16:43:09 <dromasca> 25497
16:44:11 <dromasca> 25513
16:45:11 <dromasca> h - change definition
16:45:24 <dromasca> should be documented - editorial
16:45:39 <dromasca> 25533
16:45:42 <dom> -> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25513 WebRTC spec should explicitly specify all muted events of MediaStreamTrack related to RTCPeerConnection.
16:46:29 <dromasca> justin - rollback issue
16:46:56 <dom> -> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25533  	WebRTC spec should explicitly specify the state transition for cancelled offers
16:47:02 <ken_> ken_ has joined #webrtc
16:47:16 <dromasca> needs add to api. assigned to ekr
16:47:46 <dromasca> 25533
16:47:52 <dom> -> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25544 Options attribute of createOffer / createAnswer should be validated before processing.
16:47:58 <dromasca> 25544
16:49:38 <jerome> jerome has joined #webrtc
16:51:32 <dromasca> webIDL type checking
16:51:42 <dromasca> 25545
16:52:01 <dom> -> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25545 Initialization of of RTCConfiguration while invoking RTCPeerConnection.getConfiguration should be updated.
16:52:46 <dromasca> edit proposal - obe
16:52:54 <dromasca> 25576
16:53:04 <dom> -> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25576  	steps for createDTMFSender() are missing
16:54:02 <dromasca> assign to editors
16:54:07 <dromasca> 25579
16:54:11 <dom> -> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25579  	State transitions are missing in RTCPeerConnections state transition diagram
16:55:01 <dromasca> j: just say no
16:57:07 <dromasca> 25596
16:58:02 <dom> -> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25596 updateIce should be called setConfiguration
16:58:12 <dromasca> mark as solved - there's already a call rewquest
16:58:31 <dom> -> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25806 ice pool size
16:58:35 <dromasca> 25808
16:59:22 <dromasca> 25596 - jusitn
16:59:26 <dromasca> 25806
16:59:55 <dromasca> assign to peter
17:00:10 <dromasca> should be done
17:00:15 <dromasca> 25808
17:00:39 <dom> -> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25808 add new acces for the active remote/local SDP
17:01:25 <dromasca> clone of gerhard's issue
17:02:18 <jib> jib has joined #webrtc
17:02:18 <dromasca> assign to justin
17:02:28 <dromasca> 25811
17:04:09 <eric_carlson> eric_carlson has joined #webrtc
17:07:10 <ken> ken has joined #webrtc
17:09:56 <ekr> ekr has joined #webrtc
17:10:12 <eric_carlson> eric_carlson has joined #webrtc
17:11:47 <ken_> ken_ has joined #webrtc
17:12:57 <ekr> ekr has joined #webrtc
17:14:18 <shinwoo> shinwoo has joined #webrtc
17:21:49 <claudio> claudio has joined #webrtc
17:23:04 <ekr1> ekr1 has joined #webrtc
17:24:05 <pan> pan has joined #webrtc
17:25:22 <shinwoo> rrsagent, draft minutes
17:25:22 <RRSAgent> I have made the request to generate http://www.w3.org/2014/10/30-webrtc-minutes.html shinwoo
17:26:02 <eric_carlson_> eric_carlson_ has joined #webrtc
17:27:06 <jib> jib has joined #webrtc
17:28:21 <Jingwang_qi_> Jingwang_qi_ has joined #webrtc
17:28:35 <dom> dom has joined #webrtc
17:28:40 <auchenberg> auchenberg has joined #webrtc
17:28:49 <tidoust2> tidoust2 has joined #webrtc
17:28:51 <dom> dom has joined #webrtc
17:30:28 <dromasca> afterbreak
17:30:44 <dromasca> 25811
17:32:03 <dom> -> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25811  	Change extensible enum to dom strings
17:32:42 <dromasca> existing enumerations?
17:33:51 <jerome> jerome has joined #webrtc
17:34:55 <dom> -> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25828 Need to add pc.canTrickle
17:35:28 <dromasca> 25828
17:36:20 <dromasca> assigned to marin
17:36:26 <dromasca> martin
17:36:31 <tidoust2> tidoust2 has joined #webrtc
17:39:07 <dromasca> 25833
17:39:51 <dromasca> martin - any new information?
17:39:51 <dom> -> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25833 change the definition of "enqueue a task" as EKR slides May 20
17:42:13 <dom> -> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25834 close is synchronous & idempotent
17:42:13 <dromasca> assigned to martin
17:42:18 <dromasca> 25834
17:44:27 <dromasca> 25835
17:44:37 <dom> -> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25835 when closing, all outstanding actions are cancelled and their callbacks are fired with a "cancelled" error
17:44:56 <dromasca> 25836
17:44:58 <dom> -> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25836 add note about addtrack being async
17:45:13 <dromasca> depending on the previous (last 3)
17:46:12 <dromasca> interaction with track adding and state transition
17:47:04 <dromasca> createOffer, addTrack, callback comes, what's the status?
17:47:11 <dromasca> createOffer not synchronous
17:52:06 <dromasca> h - anybody interested to see when onTrack is finished?
17:52:34 <dromasca> addTrack
17:52:39 <dromasca> can fail
17:52:58 <dromasca> ? remains void, returns exception
17:54:13 <dromasca> same queue? we do not say that
17:55:50 <dromasca> h- save changes
17:56:00 <dromasca> 25856
17:56:51 <dromasca> Martin - add attributes
17:56:58 <dromasca> 25859
17:57:48 <dom> -> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25856 Add way to find out if a MST is isolated or becomes islocated
17:57:48 <dom> -> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25859 Streams that become isolated generate errors on PC
17:58:29 <dromasca> assign to Martin
18:01:34 <dromasca> 25893
18:02:21 <dromasca> close - don't fix
18:02:29 <dromasca> 25957
18:04:42 <dromasca> assign t ojustin
18:04:46 <dromasca> to justin
18:05:05 <dromasca> 25975
18:06:42 <jerome_> jerome_ has joined #webrtc
18:06:48 <myakura> myakura has joined #webrtc
18:07:24 <dom> -> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25893  	Offer Answer options should supported sendOnly and inactive media states
18:07:28 <dom> -> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25957 PeerConnection should have an onerror event handler
18:07:36 <dromasca> still send DTMF?
18:07:43 <dom> -> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25975 When do the value of DTMFSender.canInsertDTMF can change.
18:08:13 <dromasca> check reflects the current state
18:09:17 <jib> jib has joined #webrtc
18:12:34 <dromasca> can DTMFsender change?
18:12:39 <masatakayakura> masatakayakura has joined #webrtc
18:12:43 <alan-i_> alan-i_ has joined #webrtc
18:12:44 <dromasca> assigned to Peter
18:12:56 <dromasca> harald file new item
18:13:54 <dromasca> 26027
18:14:50 <dromasca> editorial
18:16:44 <dom> -> https://www.w3.org/Bugs/Public/show_bug.cgi?id=26027 addIceCandidate should not be callable when PeerConnection is closed
18:16:59 <dom> -> https://www.w3.org/Bugs/Public/show_bug.cgi?id=26279 Options attribute is required for createAnswer
18:17:14 <dromasca> 26279
18:17:39 <dromasca> justin can update this
18:17:49 <WY> WY has joined #webrtc
18:18:54 <dromasca> need identifier - voice activity detection
18:19:20 <dromasca> based on what you receive, not on what you send
18:20:32 <dromasca> can't preclude using offerAnswer in the future
18:23:35 <dromasca> assign to Justin, edit as per harald
18:23:49 <dromasca> 26364
18:25:19 <dromasca> 26620
18:26:06 <dromasca> timestamp
18:26:07 <Shige> Shige has joined #webrtc
18:26:28 <dromasca> varun - move to the stats doc
18:26:33 <dromasca> assign to adam
18:26:43 <dromasca> 26644
18:27:20 <dromasca> harald assigns to himself
18:28:52 <dromasca> justin two things in this bug, add new event, we should do it
18:32:57 <dom> dom has joined #webrtc
18:34:06 <dromasca> add MID
18:34:12 <dromasca> 27211
18:35:16 <dom> https://github.com/w3c/webrtc-pc/issues
18:36:28 <dromasca> Github
18:36:35 <dromasca> #4
18:37:40 <dromasca> more information needed, justin and cullen not here
18:37:43 <dromasca> #5
18:38:44 <dromasca> varun - keep simple? what 'simple' means
18:40:53 <dromasca> #6
18:40:55 <dromasca> differ
18:41:17 <dromasca> defer
18:41:22 <dromasca> #7
18:41:49 <dromasca> already assigned
18:41:57 <dromasca> #8
18:42:13 <dromasca> same as #5?
18:47:28 <dromasca> #9
18:47:53 <dromasca> assigned to cullen
18:48:54 <dromasca> #10
18:50:02 <dromasca> closed
18:50:24 <dom> dom has joined #webrtc
18:50:48 <dom> RRSAgent, draft minutes
18:50:48 <RRSAgent> I have made the request to generate http://www.w3.org/2014/10/30-webrtc-minutes.html dom
18:50:57 <dromasca> editors will edit - there will be a new version
18:51:11 <ekr> ekr has joined #webrtc
18:51:33 <dromasca> probably last call not in 2014
18:59:35 <mt> mt has joined #webrtc
18:59:36 <tidoust2> tidoust2 has joined #webrtc
18:59:42 <auchenberg> auchenberg has joined #webrtc
19:07:04 <ken> ken has joined #webrtc
19:17:33 <ekr1> ekr1 has joined #webrtc
19:19:49 <forty4> forty4 has joined #webrtc
19:29:57 <auchenberg> auchenberg has joined #webrtc
19:32:53 <eric_carlson> eric_carlson has joined #webrtc
19:34:36 <forty4> RRSAgent, draft minutes
19:34:36 <RRSAgent> I have made the request to generate http://www.w3.org/2014/10/30-webrtc-minutes.html forty4
19:42:51 <eric_carlson_> eric_carlson_ has joined #webrtc
19:43:48 <eric_carlson_> eric_carlson_ has joined #webrtc
19:48:05 <mt> mt has joined #webrtc
19:48:18 <auchenberg> auchenberg has joined #webrtc
19:52:31 <nsakai2_> nsakai2_ has joined #webrtc
19:58:52 <wy> wy has joined #webrtc
20:01:54 <wy_> wy_ has joined #webrtc
20:02:18 <auchenberg> auchenberg has joined #webrtc
20:02:52 <mt> mt has joined #webrtc
20:05:28 <juberti> juberti has joined #webrtc
20:06:17 <adamR> adamR has joined #webrtc
20:15:06 <claudio> claudio has joined #webrtc
20:16:48 <jib> jib has joined #webrtc
20:33:38 <auchenberg> auchenberg has joined #webrtc
20:54:11 <lgombos__> lgombos__ has joined #webrtc
21:00:34 <forty4> forty4 has joined #webrtc
21:00:40 <tomoyuki> tomoyuki has joined #webrtc
21:01:57 <forty4> forty4 has joined #webrtc
21:10:04 <shige> shige has joined #webrtc
21:20:53 <gludi> gludi has joined #webrtc
22:01:12 <myakura> myakura has joined #webrtc
22:02:34 <auchenberg> auchenberg has joined #webrtc
22:33:58 <myakura> myakura has joined #webrtc
22:38:09 <jib> jib has joined #webrtc
22:51:11 <adamR> adamR has joined #webrtc
22:51:43 <adamR> adamR has joined #webrtc
22:53:27 <auchenberg> auchenberg has joined #webrtc
22:56:24 <dom> dom has joined #webrtc
23:12:33 <mt> mt has joined #webrtc
23:13:35 <dom> dom has joined #webrtc
23:14:25 <adamR> adamR has left #webrtc
23:22:27 <adamR> adamR has joined #webrtc
23:23:00 <dom> dom has joined #webrtc
00:16:29 <lgombos__> lgombos__ has joined #webrtc
00:42:46 <lgombos__> lgombos__ has joined #webrtc
00:43:32 <jib> jib has joined #webrtc
01:06:46 <ekr> ekr has joined #webrtc
01:08:53 <jib> jib has joined #webrtc
01:09:46 <jib> jib has joined #webrtc
01:11:12 <ekr> ekr has joined #webrtc
01:32:59 <forty4> forty4 has joined #webrtc
01:34:13 <lgombos_> lgombos_ has joined #webrtc
01:42:43 <myakura> myakura has joined #webrtc
01:53:44 <ekr> ekr has joined #webrtc
02:57:25 <ekr> ekr has joined #webrtc
02:59:47 <ekr> ekr has joined #webrtc
03:15:27 <myakura> myakura has joined #webrtc
03:17:14 <ken> ken has joined #webrtc
03:30:49 <ekr> ekr has joined #webrtc
03:34:43 <forty4> forty4 has joined #webrtc
03:46:21 <ekr> ekr has joined #webrtc
04:08:34 <ekr> ekr has joined #webrtc
04:20:46 <ekr> ekr has joined #webrtc
04:30:07 <ekr> ekr has joined #webrtc
04:36:23 <ekr> ekr has joined #webrtc
04:50:31 <ken> ken has joined #webrtc
05:04:23 <ken> ken has joined #webrtc
07:40:49 <ekr> ekr has joined #webrtc
11:37:35 <lgombos_> lgombos_ has joined #webrtc
12:07:05 <lgombos_> lgombos_ has joined #webrtc
12:56:22 <myakura> myakura has joined #webrtc
13:18:48 <lgombos_> lgombos_ has joined #webrtc
14:22:06 <stryx`> stryx` has joined #webrtc
14:27:18 <tomoyuki> tomoyuki has joined #webrtc
14:31:00 <myakura> myakura has joined #webrtc
14:35:00 <ekr> ekr has joined #webrtc
14:39:39 <ekr> ekr has joined #webrtc
14:50:57 <ekr> ekr has joined #webrtc
14:58:13 <jib> jib has joined #webrtc
15:14:15 <lgombos_> lgombos_ has joined #webrtc
17:21:17 <auchenberg> auchenberg has joined #webrtc
17:34:49 <ekr> ekr has joined #webrtc
18:08:02 <eric_carlson> eric_carlson has joined #webrtc
18:53:33 <tomoyuki> tomoyuki has joined #webrtc
19:28:04 <lgombos_> lgombos_ has joined #webrtc
20:00:23 <lgombos_> lgombos_ has joined #webrtc
23:09:51 <jib> jib has joined #webrtc
23:29:18 <lgombos_> lgombos_ has joined #webrtc
23:53:03 <auchenberg> auchenberg has joined #webrtc
23:54:42 <auchenbe_> auchenbe_ has joined #webrtc
00:53:03 <auchenberg> auchenberg has joined #webrtc
00:55:50 <auchenberg> auchenberg has joined #webrtc
01:02:13 <jib> jib has joined #webrtc
01:28:01 <ekr> ekr has joined #webrtc
02:14:55 <ekr> ekr has joined #webrtc
02:48:06 <lgombos_> lgombos_ has joined #webrtc
03:26:27 <jib> jib has joined #webrtc
03:42:41 <ekr> ekr has joined #webrtc
04:39:41 <ekr> ekr has joined #webrtc
05:29:45 <auchenberg> auchenberg has joined #webrtc
08:48:46 <auchenberg> auchenberg has joined #webrtc
12:47:13 <lgombos_> lgombos_ has joined #webrtc
14:06:53 <ekr> ekr has joined #webrtc
14:13:23 <ekr> ekr has joined #webrtc
14:45:06 <ekr> ekr has joined #webrtc
14:47:33 <lgombos_> lgombos_ has joined #webrtc
14:56:57 <lgombos_> lgombos_ has joined #webrtc
14:57:07 <ekr> ekr has joined #webrtc
15:46:35 <ekr> ekr has joined #webrtc
16:37:11 <lgombos_> lgombos_ has joined #webrtc
17:37:53 <auchenberg> auchenberg has joined #webrtc
17:38:58 <lgombos_> lgombos_ has joined #webrtc
18:11:21 <lgombos_> lgombos_ has joined #webrtc
19:23:44 <ekr> ekr has joined #webrtc
19:34:07 <ekr> ekr has joined #webrtc
19:44:06 <ekr> ekr has joined #webrtc
19:45:39 <ekr1> ekr1 has joined #webrtc
20:34:24 <myakura> myakura has joined #webrtc
20:34:37 <ekr> ekr has joined #webrtc
23:16:53 <auchenberg> auchenberg has joined #webrtc
00:26:11 <ekr> ekr has joined #webrtc
00:31:31 <lgombos> lgombos has joined #webrtc
00:52:44 <myakura> myakura has joined #webrtc
01:25:57 <ekr> ekr has joined #webrtc
01:33:39 <auchenberg> auchenberg has joined #webrtc
01:45:41 <ekr> ekr has joined #webrtc
01:46:14 <lgombos_> lgombos_ has joined #webrtc
01:46:51 <lgombos_> lgombos_ has joined #webrtc
01:47:51 <lgombos__> lgombos__ has joined #webrtc
01:48:34 <lgombos_> lgombos_ has joined #webrtc
01:49:14 <lgombos_> lgombos_ has joined #webrtc
01:49:54 <lgombos_> lgombos_ has joined #webrtc
01:50:38 <lgombos__> lgombos__ has joined #webrtc
01:51:14 <lgombos__> lgombos__ has joined #webrtc
01:51:55 <lgombos_> lgombos_ has joined #webrtc
01:52:37 <lgombos__> lgombos__ has joined #webrtc
01:53:15 <lgombos_> lgombos_ has joined #webrtc
01:53:57 <lgombos__> lgombos__ has joined #webrtc
01:54:35 <lgombos_> lgombos_ has joined #webrtc
01:55:17 <lgombos__> lgombos__ has joined #webrtc
01:55:55 <lgombos_> lgombos_ has joined #webrtc
02:33:56 <lgombos_> lgombos_ has joined #webrtc
02:53:01 <auchenberg> auchenberg has joined #webrtc
03:32:47 <ekr> ekr has joined #webrtc
04:07:43 <ekr> ekr has joined #webrtc
04:55:39 <ekr> ekr has joined #webrtc
05:18:35 <ekr> ekr has joined #webrtc
05:30:09 <ekr> ekr has joined #webrtc
05:40:28 <ekr> ekr has joined #webrtc
05:51:59 <ekr> ekr has joined #webrtc
07:42:27 <dom> dom has joined #webrtc
08:25:19 <auchenberg> auchenberg has joined #webrtc
09:47:31 <auchenberg> auchenberg has joined #webrtc
10:48:33 <auchenberg> auchenberg has joined #webrtc
11:49:44 <auchenberg> auchenberg has joined #webrtc
12:50:44 <auchenberg> auchenberg has joined #webrtc
13:20:07 <lgombos> lgombos has joined #webrtc
13:32:26 <ekr> ekr has joined #webrtc
13:50:16 <lgombos> lgombos has joined #webrtc
13:50:57 <ekr> ekr has joined #webrtc
13:51:46 <auchenberg> auchenberg has joined #webrtc
14:31:44 <ekr> ekr has joined #webrtc
14:52:47 <auchenberg> auchenberg has joined #webrtc
15:07:09 <adamR> adamR has joined #webrtc
15:32:33 <auchenberg> auchenberg has joined #webrtc
16:06:08 <lgombos> lgombos has joined #webrtc
16:06:37 <ekr> ekr has joined #webrtc
16:07:20 <ekr> ekr has joined #webrtc
16:09:16 <ekr> ekr has joined #webrtc
16:32:13 <timeless> timeless has changed the topic to: WebRTC (after TPAC)
16:44:15 <auchenberg> auchenberg has joined #webrtc
16:47:24 <auchenbe_> auchenbe_ has joined #webrtc
17:01:33 <ekr> ekr has joined #webrtc
18:30:15 <auchenberg> auchenberg has joined #webrtc
19:48:27 <ekr> ekr has joined #webrtc
19:51:02 <ekr> ekr has joined #webrtc
19:53:42 <mt> mt has joined #webrtc
20:29:52 <mt> mt has joined #webrtc
20:30:26 <ekr> ekr has joined #webrtc
21:39:40 <mt> mt has joined #webrtc
21:41:09 <mt1> mt1 has joined #webrtc
22:03:20 <auchenberg> auchenberg has joined #webrtc