17:27:57 <RRSAgent> RRSAgent has joined #webrtc
17:27:57 <RRSAgent> logging to http://www.w3.org/2014/05/20-webrtc-irc
17:27:59 <trackbot> RRSAgent, make logs world
17:27:59 <Zakim> Zakim has joined #webrtc
17:28:01 <trackbot> Zakim, this will be RTC
17:28:01 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
17:28:02 <trackbot> Meeting: Web Real-Time Communications Working Group Teleconference
17:28:02 <trackbot> Date: 20 May 2014
17:28:11 <dom> s/Teleconference/F2F Day 1/
17:28:15 <dom> Chair: hta, stefanh
17:28:38 <stefanh> Agenda and stuff: https://www.w3.org/2011/04/webrtc/wiki/May_19_-_May_21_2014
17:29:01 <jib> jib has joined #webrtc
17:29:23 <gmandyam> gmandyam has joined #webrtc
17:30:09 <fluffy> fluffy has joined #webrtc
17:30:37 <Ted_> Ted_ has joined #webrtc
17:30:56 <adambe> adambe has joined #webrtc
17:32:41 <DanD> DanD has joined #webrtc
17:32:44 <dom> ScribeNick: stefanh
17:33:09 <stefanh> Approval of minutes of telco April 28th: approved
17:33:11 <dom> -> http://lists.w3.org/Archives/Public/public-webrtc/2014Apr/0070.html previous WebRTC teleconf minutes
17:33:19 <dom> Topic: Doohickeys
17:33:25 <stefanh> Next topic: Doohickeys, Justin to present
17:33:33 <dom> -> https://www.w3.org/2011/04/webrtc/wiki/images/6/63/WebRTC_RTCSender-Receiver.pdf Justin's slides
17:33:42 <Dini> Dini has joined #webrtc
17:34:11 <stefanh> Justin: doohickeys aka RtpSenders/Receivers
17:34:23 <mt_> mt_ has joined #webrtc
17:34:28 <stefanh> ...first: basics
17:34:33 <coopdanger> coopdanger has joined #webrtc
17:34:36 <mt_> The objects *formally* known as Doohickeys
17:35:00 <stefanh> ....Problem statement: need to tweak on a per track basis how they are sent over the net
17:35:19 <stefanh> ....e.g. bitrate limits, direction,...
17:36:14 <stefanh> ....They may be needed to be changed during operation, hence cannot be done at addTrack/Stream time
17:36:35 <stefanh> ...Object model slide
17:37:06 <stefanh> ....for stats we solved it with one model
17:37:50 <stefanh> ...new object for RtpSending/Receiving to work on track level
17:38:25 <stefanh> ....but a track can have several encodings (layered codec, simulcast) - may be out of scope for 1.0 though
17:38:49 <stefanh> Magnus: RTP -retrans may also genereate extra SSRC for a track
17:39:02 <stefanh> Justin: showing Solution Diagram slide
17:40:12 <stefanh> ...How to obtain the objects (RtpSender/Receiver): event onaddtrack delivers Receiver, addTrack delivers Sender
17:40:40 <stefanh> ...This model is simpler than addStream generating several Senders
17:41:16 <stefanh> Martin: Agree. We had this discussion in the China TPAC, addTrack better for several reasons.
17:41:32 <stefanh> ....got a lot of support
17:42:03 <stefanh> Justin: change quite straightforward replace Stream for Track
17:42:57 <stefanh> ....special case: addTrack. A track can be part of several Streams, needs to be signaled to preserve that model.
17:43:43 <stefanh> ...several options, not signal for example, signal all Stream associations, single stream association.
17:44:36 <stefanh> Ted: Let's say video is added to an audio only session.Full offer answer needed.
17:45:35 <stefanh> Detailed discussion of streams vs. tracks vs. SDP O/A.
17:45:42 <stefanh> ...complex.
17:46:16 <stefanh> Martin: I think we need to address the everything case. Lot's of details to sort though.
17:46:42 <stefanh> ...basic thing signed on to: signal MediaStream configuration.
17:46:50 <fluffy> q?
17:47:03 <burn> burn has joined #webrtc
17:47:11 <stefanh> Randell: Onnegneeded will fire if video is added to a session.
17:47:29 <stefanh> Adam R: On same page as Martin -> everything
17:47:41 <stefanh> ...ugly, but doable
17:47:55 <stefanh> Justin: is this in scope for us?
17:48:26 <stefanh> ....maybe we don't need to signal all changes.
17:49:14 <stefanh> Cullen: If we deleted one track from one stream, signaling will happen. If we add the track to a new Stream -> move situation
17:49:21 <stefanh> q+
17:49:50 <stefanh> ...do we need to signal everything? No something can go out of band.
17:50:16 <stefanh> Martin: not the right way to hink about this.
17:50:35 <stefanh> ...would surprise people
17:51:07 <dom> ack stefanh
17:51:45 <stefanh> StefanH: support signal nothing.
17:52:05 <stefanh> Justin: Compromise solution.
17:52:41 <stefanh> ...addign a track that is already added: error, it's already added.
17:52:54 <stefanh> ..but adding a cloned track is OK
17:54:03 <stefanh> Ted: asking clarifying question about one track in several streams.
17:54:41 <stefanh> ...optimizing transport not sending same track several times even though in several streams.
17:55:19 <stefanh> ...the streams can contain different number of tracks.
17:56:05 <stefanh> Randell: have discussed this, worked on designs, but not concluded AFA can remember.
17:56:20 <stefanh> Justin: not sure this is affected by this.
17:56:50 <stefanh> ....should work fine.
17:57:16 <stefanh> (Slide: addTrack proposal)
17:57:54 <stefanh> Magnus: transmission should be optimized.
17:58:13 <stefanh> AdamR: do you want to simplify API, SDP processing or what?
17:58:32 <stefanh> Justin: optimizing the mental model. Make it simpler.
17:58:44 <stefanh> ....simplify signaling.
17:59:27 <stefanh> PeterT: Wants a simpler solution that handles the simple case,
17:59:52 <stefanh> AdamB: optimize for using the Track, but make it possible to polyfill
18:00:15 <stefanh> Justin: make it possible to signal synch state, but not signal all changes
18:00:59 <stefanh> ... simplest model makes polyfill harder, my compromise handles that.
18:01:38 <stefanh> Cullen: msid in SDP tells for a track which streams it is in. What if msid is null?
18:01:56 <stefanh> Justin: generate on sending/receiving side - can't be null.
18:02:24 <stefanh> Cullen: SDP changes must always be communicated.
18:02:37 <stefanh> Justin: yes
18:03:29 <stefanh> Cullen and Justin seem to agree around onnegneeded etc.
18:05:52 <stefanh> Martin: We should keep the current model. Tracks can exist without streams. Remove onnegotiatinneeded event when someone plays with the grouping.
18:06:20 <stefanh> ...would need to be onaddstream
18:06:32 <stefanh> (details discussed - scribe not keeping up)
18:06:59 <stefanh> Justin: onaddtrack could indicate sequence of streams it belongs to
18:08:04 <stefanh> Martin: no way to navigate from a track to find all streams it is part of.
18:09:50 <stefanh> Ted: In practice a track is usually part of one stream only.
18:10:24 <stefanh> ...does the application know in advance, then it can work fine with Justin's proposal.
18:10:54 <stefanh> ....the advanced cases can be handled over the top signaling.
18:11:21 <stefanh> ....i.e. get the common case with current semantics, advanced cases different.
18:11:33 <stefanh> ....but the app needs to know in advance.
18:12:26 <stefanh> Justin: streams is about signaling synchronization. audio and video should be in synch, screen share need not be
18:13:32 <stefanh> AdamR: We're talking about two things: streams where tracks are added locally, nothing should happen on PC.
18:14:16 <stefanh> ...scribe losing track of discussion ...
18:14:55 <stefanh> ...AdamR OK with Justins proposal
18:15:46 <stefanh> Ted: there are cases when you may want to move things out of synch context, but app is aware and can handle that out of band
18:16:50 <stefanh> Justin: we have to deal with this since we before could add things to the container (=stream).
18:17:32 <stefanh> ....What should we optimize for? We can return details.
18:18:16 <mt_> For the record, I remain unconvinced, mostly because I think that the polyfill is trivial with c=0..n, but far more complicated than c=0..1
18:18:43 <stefanh> AdamB: Why is a new stream created if none was provided with addTrack?
18:19:08 <stefanh> Justin: To make app writing simpler.
18:19:28 <stefanh> AdamB: Solvable anyway.
18:19:45 <stefanh> Justin agree, but convenient.
18:20:22 <stefanh> Cullen: can you add a track to two streams, and have it be in the synch state of both streams?
18:20:43 <stefanh> Justin: no, not with this proposal.
18:21:00 <stefanh> Peter: You can accomplish that on the receive side.
18:21:13 <stefanh> Martin: yes, but the signaling is different.
18:21:22 <stefanh> Justin: this is a change.
18:21:50 <stefanh> Cullen: I'd describe this that a track can only be part of one stream over a peerconnection.
18:21:56 <stefanh> Justin: yes.
18:22:32 <stefanh> ....discussion about synch context....
18:23:45 <stefanh> Cullen: everything in a peerconnection has a common time base, but not synched.
18:25:07 <stefanh> ....discussion about synch....a very significant change....
18:25:39 <stefanh> Martin: what advantage do we get from the simplification?
18:27:10 <stefanh> Justin: I am OK with several streams being possible for a track
18:27:24 <stefanh> ....at addTrack time.
18:28:11 <stefanh> Cullen: I have never heard a compelling use case for one track being in several streams. I don't really care.
18:29:30 <stefanh> Conclusion: going with the vector.
18:29:49 <stefanh> But can't change after addTrack (need to remove and add again).
18:30:23 <stefanh> Martin: default for the second parameter should be null.
18:31:05 <jesup> I forget the usecase that was used originally for sharing tracks.  I remember there was one.  I don't care that much....  I think it was to combine with different sets of tracks (audio, video).  Note that the receiver could do some of these (modulo sync) by reworking the tracks into streams.
18:31:12 <jesup> I'm good with what we ended up with
18:32:00 <stefanh> Justin: onremovestream. Never clear when they should fire. Take away, the tracks just end at remote side.
18:32:30 <stefanh> AdamB: a stream never ends in the current spec.
18:32:49 <stefanh> Martin: what about RTCP-bye?
18:33:30 <stefanh> Ekr: have to listen to ended on a track? Seems Ok to me.
18:34:00 <stefanh> Justin: showing the actual API. Should not be surprising.
18:34:23 <stefanh> ...but a vector should be added for the stream's part
18:35:21 <stefanh> Sense of the room?
18:36:24 <stefanh> harald asking questions. Who thinks we should change to this track model (instead of stream) for addXXX for PeerConnection is good?
18:37:30 <stefanh> Cullen thinks premature to ask.
18:39:03 <stefanh> ...I like the proposal, but premature to decide
18:39:33 <stefanh> Should we pursue (with right to abandon later if not good)
18:39:38 <stefanh> on not.
18:39:45 <jesup> Persue
18:39:57 <Erik> +1 to pursuing it
18:40:12 <stefanh> Almost all wanted to pursue, no one wanted to stop it.
18:40:28 <stefanh> Consensus in the room to pursue this.
18:41:37 <stefanh> Cullen: can a Receiver do removeTrack?
18:41:42 <jesup> We ;lost the feed from the room.....
18:42:09 <Ted_> Just a second
18:42:28 <jesup> back
18:43:03 <stefanh> Justin continuing with the contriversial stuff
18:43:32 <stefanh> ....Transports: ICE state, DTLS certs
18:43:58 <stefanh> ....proposal to add a .transport property per RTPSender/Receiver
18:44:46 <stefanh> ....Transports 1.0 API shown
18:46:11 <stefanh> Ekr: for clarification - something about bundling and ICE and stuff....endorsing this
18:46:43 <stefanh> Kiran: codec preferenses question
18:46:55 <stefanh> Justin: we've not at that slide yet
18:47:02 <stefanh> ...it comes later
18:47:27 <stefanh> Martin: likes the idea, some worries - solvable
18:48:19 <stefanh> Justin: do you agree with the properties that I propose are _in_ ?
18:48:35 <stefanh> Martin: the first probably OK, the second one not sure
18:48:58 <stefanh> Ted and Cullen: agree on second certificate comment
18:49:38 <stefanh> Cullen: I love this in every detail!
18:50:13 <stefanh> Ted: Don't like the part about the remote certs. Details about JS trust certs and stuff
18:50:59 <stefanh> ....afraid someone will eventually have JS flush certs (or something....scribe losing it)
18:51:13 <stefanh> ...not sure it is worth it
18:51:52 <stefanh> Harald: Opposite react to Ted: JS wants to know cert changes e.g. for stats reasons
18:51:57 <richt> richt has joined #webrtc
18:52:02 <stefanh> ...but what about ICE components?
18:52:28 <stefanh> Justin: let's ignore comp. for now
18:52:34 <stefanh> Ekr: seems fine to me.
18:53:33 <stefanh> Martin: can we take advantage of that we have someone knowing web crypto in the room?
18:53:41 <stefanh> Barnes: they are just objects
18:54:11 <stefanh> ....ArrayBuffer or ArrayBufferView - detail to sort later.
18:54:15 <Ted_> He said "octets", not "objects"
18:54:28 <stefanh> s/objects/octets/
18:55:06 <stefanh> Justin: next, encoding parameters
18:55:06 <DanD> q?
18:55:22 <JonathanLennox> JonathanLennox has joined #webrtc
18:55:58 <stefanh> ...codecs and parameters payload types... can be read out in RtpSender
18:57:24 <stefanh> ....and we can make changes, three types: those that do not need negotiation - signaling not needed, those that need negotiation (pause); but can't change things that would be incosistent with SDP
18:58:07 <stefanh> ...when changing, onnegotiationneeded might fire, then SDP O/A is needed to carry out the changes.
18:58:50 <stefanh> ....a consequence: changes that req nego needs to be clearly described in SDP
18:59:26 <stefanh> ...
19:00:06 <stefanh> AdamR: special case involving codecs, tones, switch Opus -> G.711 -> Opus. Allowed?
19:00:10 <stefanh> Justin: no
19:00:57 <stefanh> Martin: Is the intent of the API to express desires or expose the state?
19:01:35 <stefanh> ...on reading out things that have been changed but not negotiated - what is read out?
19:01:49 <stefanh> Cullen: I can propose text.
19:02:25 <stefanh> ....The values should represent the actual encoding, not the asked for (but not yet negotiated)
19:03:18 <stefanh> ....changes coupled to setLocal in soem cases, to get answer back in other cases
19:03:26 <jesup> So, I have more parameters that should be here.  See https://www.w3.org/Bugs/Public/show_bug.cgi?id=15861 for some examples
19:04:02 <stefanh> ....we can set a set of easy to follow rules for this
19:05:14 <stefanh> Martin: some things happen immediately, some require some negotiation,
19:05:16 <jesup> q+
19:05:42 <stefanh> Suhas: bitrates within bounds of b=AS
19:05:56 <stefanh> Justin: need to look more into this.
19:06:19 <stefanh> ....related to congestion control
19:07:01 <stefanh> Randell: Supportive if this - helps stuff I've proposed before
19:07:07 <hta1> hta1 has joined #webrtc
19:07:49 <stefanh> ...frameRate, motionpreferred, bitrate and resolution issues, target video quality,....
19:08:08 <stefanh> Justin: resolution and framerate already on tracks.
19:08:38 <stefanh> Cullen: how do we decide what we do on tracks and what we do on doohickeys?
19:08:59 <stefanh> justin: depends on if it happens in raw media domain or encoded domain
19:09:28 <stefanh> Randell: scribe lost track
19:10:01 <stefanh> ....quality parameters goes into the doohickey
19:10:33 <stefanh> AdamR: we should have a clean separation, model and view
19:10:40 <stefanh> Justin: agree
19:11:18 <stefanh> Justin: we already have current and proposed SDPs
19:11:47 <stefanh> Martin: there is value in knowing what the browser is doing
19:12:02 <stefanh> ...e.g. read out music detector state
19:12:58 <stefanh> Randell: talks for the use-case: an application wants to control if continue sending a track if the bitrate is too low. This could be the control surface for this.
19:13:21 <stefanh> Justin: auto pausing: set a minimum bitrate
19:14:07 <stefanh> ...prioritization between tracks
19:15:14 <stefanh> Justin: we do not have well defined SDP for simulcast
19:15:29 <stefanh> ....showing the EncParams for 1.0 that he proposes
19:16:06 <stefanh> Ekr: simulcast: need to do JS controlled clone track etc....
19:16:30 <stefanh> Cullen: do we know how to add Simulcast SVC later, what do we do?
19:16:45 <stefanh> Justin: sequence of encoding parameters
19:17:45 <stefanh> ....add a scaler for the different streams, def 1.0, add 0.5, 0.25 etc.
19:18:40 <stefanh> Cullen: scale makes me said - but we can figure that out
19:18:45 <stefanh> ...how would FEC work?
19:18:59 <stefanh> Justin: parameter on encoding params
19:20:00 <stefanh> Cullen: would be much happier to have a sequence for SVC/Simulcast than the scale thing
19:20:44 <stefanh> ....on the fly design discussion ongoing....
19:21:13 <stefanh> ...let's poke on the lack of SDP support for simulcast. Is that really true?
19:21:39 <stefanh> ...simulcast can be done pretty quickly if we want do. I want to.
19:22:07 <stefanh> ...if simulcast was ready before this text should it be in?
19:22:18 <stefanh> Justin: as long as not stalling this doc
19:23:27 <stefanh> ...moving on to discuss scheduling
19:24:11 <stefanh> Kiran: something about codec preferences
19:24:14 <DanD> q+
19:24:23 <jesup> q-
19:25:03 <stefanh> ....related to offer answer negoneeded ....
19:25:54 <stefanh> AdamR: example coding parameters - current vs proposed
19:26:42 <stefanh> Bernard: you can already do simulcast: JS controlled. Losing efficiency, but doable.
19:27:25 <stefanh> Peter: How do I know what to set for SSRC?
19:27:47 <stefanh> ....future question.
19:27:58 <stefanh> Ekr: I can live with JS simulcast
19:28:51 <stefanh> ....worried about changing codecs
19:29:10 <stefanh> ....conflicts can be a headache
19:30:37 <stefanh> Martin: you have not been very clear on teh model to use, related to negotiating the requested changes, what happens if you are half way through a nego?
19:30:45 <stefanh> Cullen: active and proposed SDP
19:31:48 <stefanh> Martin: this changes what you will propose the next time you propose something. How long does the browser keep the proposal? Until used.
19:32:05 <stefanh> ....active and proposed state
19:32:17 <stefanh> q?
19:33:59 <stefanh> DanD: What about priority? Not shown on the slides.
19:34:32 <stefanh> Justin: should be on the encoding params. Left it out because we need to decide what it means, prio 1 compared to prio 2
19:35:00 <stefanh> DanD: I think the idea was that it is more of a desire than a setting. Do you see it coming into 1.0?
19:35:17 <stefanh> Justin: no, but if someone willing to do the work it could get in.
19:35:41 <stefanh> Harald: Would be nice to have here
19:36:01 <stefanh> ....LGTM, but more discussion needed.
19:36:38 <stefanh> Justin: would people be ok with a pull request for the Transport part?
19:36:51 <stefanh> Harald putting questions
19:37:29 <stefanh> Unclear result
19:38:17 <stefanh> ....is transport state ready for pull req?
19:38:31 <DanD> q?
19:38:38 <DanD> q-
19:38:43 <stefanh> Result: new proposal with two objects, one for tranpsort state, one for DTLS certs
19:38:52 <stefanh> ....jusstin will write up
19:39:13 <stefanh> Coffee break till 3:55
19:39:26 <stefanh> new scribe will be needed after coffee
19:44:44 <jib> jib has joined #webrtc
19:58:23 <jib> jib has joined #webrtc
19:58:38 <dom> Topic: Error handing
19:58:42 <dom> ScribeNick: adambe
19:59:08 <dom> -> https://www.w3.org/2011/04/webrtc/wiki/images/0/0f/Webrtc-error.pdf EKR's slides
19:59:51 <adambe> ekr: programming error gets exceptions, all other get error callbacks
20:00:03 <adambe> ... web idl does type checking
20:00:15 <adambe> ... I don't like when things fail silently
20:00:41 <adambe> ... if people think failing silently is good, lets have the discussion now
20:01:00 <adambe> ... the spec is written as: follow these steps
20:01:18 <adambe> ... at the end it says: if the PC is close, don't do anything
20:01:22 <adambe> ... this is confusing
20:01:46 <adambe> ... proposal: if the PC is close, don't do anything (for any method0
20:02:01 <Ted_> Ted_ has joined #webrtc
20:03:48 <adambe> ... at teh point where the next item is picked from teh queue, we should check for errors
20:04:15 <adambe> (missed what Martin said)
20:05:55 <mt_> proposal is to have an InvalidStateError thrown when any action is enqueued; have the corresponding action fail (with an InvalidStateError) when dequeuing an action
20:06:02 <adambe> juberti: what's the arguing from not letting everything in the queue complete
20:06:29 <adambe> ekr: I would vote for close() to be queued
20:07:40 <adambe> hta1: close should be synchronous
20:08:10 <adambe> jesup: I agree with hta1
20:08:22 <adambe> ... apps are doing this already
20:08:41 <adambe> ekr: do people think we could drop errors?
20:08:55 <adambe> jesup: that would be problematic with e.g. promises
20:09:24 <adambe> ekr: createOffer in the same event loop iteration as close will never have its callbakc fired
20:10:02 <adambe> jib: close comes from the app
20:10:47 <adambe> juberti: invalid state may not be the right error
20:10:57 <burn_> burn_ has joined #webrtc
20:11:28 <adambe> mt_: close called a 2nd time always work
20:11:55 <adambe> ekr: we should not have check for closed in every method description
20:12:30 <adambe> fluffy: is this getting into the minutes
20:13:07 <mt_> ok: proposal is to change the definition of "enqueue a task" as above
20:13:15 <mt_> close is synchronous
20:13:20 <mt_> multiple calls to close succeed
20:13:50 <mt_> when closing, all outstanding actions are cancelled and their callbacks are fired with a "cancelled" error
20:14:07 <adambe> ekr: addStream behavior may be overtaken by events
20:14:28 <adambe> ... multiple calls to addTrack with the same track should fire ResourceInUse
20:14:54 <adambe> ... should addTrack be queued?
20:15:13 <adambe> juberti: that would mean that a lot of other stuff needs to be async as well
20:15:35 <adambe> ekr: we're already changing a lot of stuf
20:15:35 <mt_> addTrack could be made asynchronous
20:15:37 <sean> sean has joined #webrtc
20:15:49 <mt_> but at the same time, asynchronous calls suck to use
20:17:34 <hta> you can't emulate a synchronous call on top of an async one (unless you're prepared to ignore the results).
20:17:56 <adambe> jib: the queue exist to protect our state
20:18:23 <adambe> adam: it's no point to have sync and async stuff to interact with each other
20:19:05 <adambe> jib: you need the result from createOffer() to continue
20:19:24 <adambe> mt_: you don't need the output of createOffer to add a stream (track)
20:19:57 <adambe> juberti: what ways can addStream() fail (except the steram already added)
20:20:02 <adambe> ... ?
20:20:45 <adambe> ekr: you don't think it will it fail if you ask for too many encoders
20:20:48 <adambe> ... ?
20:22:07 <adambe> ekr: it's only addTrack() and close() async atm
20:22:48 <adambe> juberti: removeStream() is being replaced with removeTrack()
20:22:56 <hta> s/async/sync/
20:23:44 <adambe> mt_: if you add a track twice it's simply gets added
20:24:33 <adambe> juberti: I'm having second thoughts about setConfiguration() not needing to be async
20:25:16 <adambe> adam: if addTrack() is sync the tracks won't show up on teh next line of code
20:27:25 <adambe> mt_: addTrack() should add the track async if there's something in the queue, not otherwise
20:28:41 <adambe> fluffy: I'm fine if implementations do what mt said, but I don't want mandate it
20:28:52 <mt_> my point here was that it should be ok to run these void functions (i.e., those without callbacks) synchronously
20:30:11 <adambe> adambe: it's strange if things get queued sometimes but run sync otherwise
20:31:27 <adambe> juberti: addTrack() returns an object now
20:31:35 <adambe> ... what state is that object in?
20:32:07 <fluffy> http://mozillamemes.tumblr.com/post/79874049694/it-worked-fine-yesterday
20:32:13 <adambe> jib: we should use promises as a measuring stick
20:35:18 <jib> jib has joined #webrtc
20:36:22 <adambe> erk: send on a closed DataChannel should throw
20:37:13 <adambe> ekr: try to create a DTMFSender with a video track -> InvalidParameter
20:37:21 <JonathanLennox> Great big picture of the number
20:37:55 <adambe> ekr: send dtmf when canSendDTMF is false -> InvalidState
20:38:26 <adambe> ... insert DTMF with bogus values should generate InvalidParameter exception
20:41:13 <stefanh> WebIDL way to clamp DTMF errors
20:41:21 <dom> scribenick: stefanh
20:41:31 <stefanh> Unused errors - remove them
20:41:42 <stefanh> (mentioned in Ekr's slide)
20:41:57 <stefanh> RTCSdpError:
20:42:03 <stefanh> defined, never used
20:42:31 <stefanh> proposal: spec that it is used in the error callbacks
20:43:31 <stefanh> the error should be redefined to inherit from the MediaStreamError (or whatever the name is now)
20:44:28 <stefanh> skiped slide
20:44:37 <stefanh> addIceCand bogus data
20:44:47 <stefanh> lot's of TBDs in the spec
20:45:19 <stefanh> error with line no not useful with ice cand - almost no linces
20:45:35 <stefanh> Ekr proposing us to define new errors
20:46:19 <stefanh> failure callbacks for createOffer/Answer
20:46:42 <stefanh> but can anything go wrong here? Only internal error?
20:47:05 <stefanh> (resource reservation happening on setLocal/Remote)
20:48:23 <stefanh> Cullen: resource reservation happens at createO, but released at callback.
20:49:21 <stefanh> ...what should happen at createO if the ua knows it does not have teh resources?
20:49:35 <stefanh> ...something needs to fail somewhere
20:50:16 <stefanh> Justin: setLocal can fail, seems better to only fire errors there
20:51:00 <stefanh> ...if you can have createO fail, do something, have it succeed, that may talk for errors on createO
20:51:15 <stefanh> ...but I think we can have all teh errors coming out of setLocal
20:52:07 <stefanh> hta: createO guarantees that the resources are avail. createO should be able to fail with "resources unavailable"
20:52:16 <stefanh> Justin: agree
20:52:39 <lgombos_> lgombos_ has joined #webrtc
20:52:54 <stefanh> ...needs more discussion on the error data.
20:53:40 <stefanh> failure callbacks for setL/setR
20:53:47 <stefanh> can fail for many reasons
20:54:54 <stefanh> needs to add more errors, e.g. peeridentity error, invalidstateerror, invalidsdperror
20:55:33 <stefanh> adambe: what does invalidstateerror mean for setLocal with an answer?
20:55:43 <stefanh> ekr: can't go to that state
20:56:31 <stefanh> cullen: difference between not valid sdp and one that is valid but not compatible with the offer
20:58:03 <stefanh> ekr: ...more discussion on incompatible vs. invalid
20:58:37 <stefanh> suhas: enough with one error: SDP was wrong plus line number
20:59:21 <stefanh> hta: the diff is what was wrong -sdp generating code or state handling
20:59:36 <stefanh> justin: some recoverable, some not
21:00:20 <stefanh> ekr: incompatible sdp: no of m-lines does not match for example
21:00:49 <stefanh> adambe: reading some parts out of the spec to clarify
21:01:36 <stefanh> Jonathan: is this for debugging code or to help apps recovers
21:01:48 <stefanh> s/recovers/recovery/
21:02:01 <stefanh> Ekr: in some cases the other side's code is broken
21:03:25 <stefanh> Spontaneous errors: some errors just happens - TURN errors, DTLS connection error, ....
21:03:35 <stefanh> not tied to any api call
21:04:38 <stefanh> use a .onerror or something RTCRuntmieError object
21:04:52 <stefanh> with an explannation attribute
21:05:11 <stefanh> What about state: how to distinguish fatal from non-fatal
21:05:22 <stefanh> state needs to change first
21:06:00 <stefanh> the list of runtime errors - only three so far, two and a half so far
21:06:53 <stefanh> Cullen: we need to carefully look through what we have on doohickeys and so on
21:07:05 <stefanh> code need to work in production not only demos
21:07:35 <stefanh> hta: turn and dtls should attach to doohickeys
21:07:56 <stefanh> internal errors could be reported on statechangeerror
21:08:24 <stefanh> justin: specific ice gathering error should be defined
21:08:32 <stefanh> cullen: we should add those
21:08:50 <stefanh> justin: I will add them to my pull request!!
21:09:36 <stefanh> Jonathan: initital failure different from subsequent failure
21:09:45 <stefanh> justin: need to think more about that
21:10:06 <stefanh> jonathan: obviously refresh may fail
21:10:21 <stefanh> cullen: people are keeping two connections active
21:10:37 <stefanh> justin: you want to know why your active connection went down
21:11:08 <stefanh> and we want gathering errors, ice disconnect errors and some more stuff
21:12:39 <dom> Topic: WebRTC schedule
21:12:41 <dom> -> https://www.w3.org/2011/04/webrtc/wiki/images/3/32/Webrtc-plan.pdf HTA slides
21:12:41 <stefanh> hta: discuss "the plan"
21:13:00 <lgombos_> lgombos_ has joined #webrtc
21:13:21 <stefanh> slide 3: assumptions
21:13:38 <stefanh> stop adding stuff after doohickeys
21:14:29 <JonathanLennox> Can the room camera be repointed at Harald?
21:15:18 <stefanh> slide 4: resulting workplan
21:15:35 <stefanh> ...leading to W3C last call in end of September
21:16:38 <stefanh> after resolving bugs till mid September
21:19:01 <stefanh> what has the highest likelihood of causing delay?
21:19:57 <stefanh> Cullen: trickle ICE, FEC stuff, almost all docs we depend on are WG docs on the IETF side, good thing
21:20:48 <stefanh> hta: the w3c chairs would like the rtcweb chairs push more for getting the docs we wait for more visible and get action
21:21:30 <stefanh> Ted: we can make them visible, but not sure we get action. We need to escalate in teh IETF. That is a real risk.
21:22:05 <stefanh> Dom: W3C can reference anything for a last call. Refs must be stabel at CR/PR stage.
21:22:41 <stefanh> ...must be very stable at Rec of course, but that comes later
21:23:34 <stefanh> Ted: always risk for requests for normative changes during IESG review
21:24:05 <stefanh> Sean: recent history show that this can be made to work
21:25:10 <stefanh> hta: word of warning, this is not the end. We will get a lot of input during last call, and we also need to build a test suite
21:25:28 <stefanh> DanB: last call is essentially the first public review
21:25:49 <stefanh> Cullen: I'd like to discuss how we deal with screen sharing.
21:26:07 <stefanh> hta: controversial, put off in a separate document
21:26:24 <stefanh> ekr: there is a proposal from MT and Cullen
21:26:37 <stefanh> ...requested feature
21:27:32 <stefanh> stefanh: separate document?
21:27:35 <stefanh> Ekr: OK
21:27:51 <stefanh> hta: get someone do the respec stuff
21:28:36 <stefanh> cullen: how fast can that happen?
21:28:51 <stefanh> dom, hta: weeks or quicker - depends on the editor
21:29:06 <stefanh> hta: Let's go with this plan.
21:29:19 <stefanh> Thanks for today, see you tomorrow
21:30:18 <Erik> thanks for scribing stefan and adam
21:30:55 <adam> adam has joined #webrtc
21:38:15 <richt> richt has joined #webrtc
21:40:24 <lgombos__> lgombos__ has joined #webrtc
21:40:41 <lgombos> lgombos has joined #webrtc
21:42:31 <JonathanLennox> JonathanLennox has left #webrtc
21:42:40 <Zakim> Zakim has left #webrtc
22:38:03 <mreavy_> mreavy_ has joined #webrtc
23:29:52 <jib> jib has joined #webrtc