15:56:00 <RRSAgent> RRSAgent has joined #webrtc
15:56:00 <RRSAgent> logging to http://www.w3.org/2015/09/10-webrtc-irc
15:56:06 <Zakim> Zakim has joined #webrtc
15:57:51 <vivien> RRSAgent, make logs public
15:59:46 <vivien> Agenda: https://www.w3.org/2011/04/webrtc/wiki/September_9_-_10_2015#Sept_10
16:00:27 <vivien> Meeting: WebRTC F2F
16:00:42 <vivien> Chairs: Harald, Stefan, ErikL
16:00:54 <RRSAgent> I have made the request to generate http://www.w3.org/2015/09/10-webrtc-minutes.html vivien
16:00:57 <sherwinsim> Can you guys hear us?
16:01:00 <Erik_L> Erik_L has joined #WebRTC
16:01:17 <sherwinsim> It seems you guys cannot hear us
16:01:21 <sherwinsim> as in the room
16:01:24 <sherwinsim> but we can hear you
16:03:09 <burn> burn has joined #webrtc
16:06:24 <DrAlex> DrAlex has joined #webrtc
16:06:28 <adamR> adamR has joined #webrtc
16:08:48 <sherwinsim> sherwinsim has joined #webrtc
16:09:08 <jesup> started getting static when people talk in the room
16:09:31 <sherwinsim> yep I hear it too
16:09:35 <vivien> sherwinsim, FYI all remote speakers are muted in WebEx don't forget to unmute yourself if you want to talk and even better use "q+" on IRC to indicate you want to talk
16:10:04 <jesup> still static-y  correlated to someone talking
16:10:14 <victor_pascual> victor_pascual has joined #webrtc
16:10:16 <mreavy|mac> static for me too from the room -- jan-ivar was clear (no static)
16:10:28 <jesup> was good initially
16:10:33 <sherwinsim> probably originating from Bernards end
16:11:01 <mreavy|mac> I think that's likely
16:11:36 <mreavy|mac> can you guys talk again?
16:11:40 <mreavy|mac> bernard was clear
16:11:47 <vivien> RRSAgent, draft minutes
16:11:47 <RRSAgent> I have made the request to generate http://www.w3.org/2015/09/10-webrtc-minutes.html vivien
16:11:48 <mreavy|mac> it's gone for me -- the static
16:11:50 <jesup> it's good now
16:11:55 <sherwinsim> it went away
16:12:50 <jesup> jib joining caused it to start again
16:13:21 <mathieu> mathieu has joined #webrtc
16:13:28 <stefanh> stefanh has joined #webrtc
16:13:40 <tedh> tedh has joined #webrtc
16:14:01 <dom> dom has joined #webrtc
16:14:50 <Varun> Varun has joined #webrtc
16:15:05 <Varun> Varun has left #webrtc
16:15:06 <ShijunS> ShijunS has joined #webrtc
16:15:30 <varun> varun has joined #webrtc
16:15:42 <jesup> Still happening with jib gone this time
16:16:06 <dom_> dom_ has joined #webrtc
16:16:13 <DanD> DanD has joined #webrtc
16:16:15 <dom_> scribenick: dom_
16:16:33 <dom_> Topic: error reporting for pc
16:16:34 <jib> jib has joined #webrtc
16:17:02 <Shishir-CTXS> Shishir-CTXS has joined #webrtc
16:17:03 <dom_> peter: initiql intention of onerror was to signal dtls errors
16:17:16 <dom_> ... now covered by the new connection state
16:17:20 <vivien> -> https://www.w3.org/2011/04/webrtc/wiki/images/1/14/WebRTC_1.0_objects_at_2015_f2f_%282%29.pdf slides
16:17:40 <jesup> static continues,  though we can hear the mic.  Room speakers will need to speak up.  Really more distortion than static per se
16:17:58 <dom_> ... PR 92 offers warning / fatalerror event that would report other type of errors
16:18:12 <dom_> justin: these errors would be not actionable by the app
16:18:14 <vivien> (reviewing PR 292 on slides 13)
16:18:20 <vivien> s/PR 92/PR 292/
16:18:25 <dom_> ... only point would be logging and we already have entry points for that
16:18:30 <vivien> s/slides/slide/
16:18:38 <dom_> ... it would be just free form text
16:19:00 <dom_> mathieu: some times things don't work with no indication as to what is not working
16:19:24 <dom_> ... I wonder if such a mechanism could not help detect these issues
16:19:38 <dom_> martin: you would still get in a failed state
16:19:59 <dom_> ekr: we get reports from people "things are busted"
16:20:25 <dom_> ... it would be nice tho have a hook for the app to be told where things are clearly wrong
16:20:32 <dom_> ... but I don't feel strongly about it
16:21:21 <dom_> ekr: there are e.g. some NSS errors we could bubble up with this
16:21:40 <dom_> ... we could as well bubble them up in the console
16:22:05 <dom_> martin: that's what is done with XHR with CORS errors
16:22:24 <dom_> cullen: debugging idp errors is a nightmare at the moment
16:23:06 <dom_> martin: I don't think the two points (warning/fatalerror) are particularly needed since the pc would go to the failed state
16:23:38 <dom_> justin: it used to be that we didn't have callbacks on some errors; but now we have the right transition states so I don't think we need this
16:25:23 <vivien> dom: I don't feel anybody is pushing for it, so I'd say we drop it
16:25:31 <dom_> mathieu: issue with just reporting in console is only applicable for errors in the development env
16:25:49 <dom_> dom: I'm not hearing much support, and we have plenty of other work to do, suggest to drop
16:26:04 <dom_> hta: show of hands of who want this?
16:26:17 <dom_> [a couple of hands up]
16:26:41 <dom_> RESOLUTION: we drop PR 292 (generic error management)
16:27:09 <dom_> DanB: for the record, the people who raised their hand are people with experience trying to get people to debug their app
16:27:42 <vivien> Topic: SessionDescription accessors
16:27:43 <adambe> adambe has joined #webrtc
16:27:45 <vivien> -> https://www.w3.org/2011/04/webrtc/wiki/images/5/57/SessionDescription_accessors.pdf slides
16:28:02 <dom_> [Justin presenting]
16:28:14 <jesup> I was trying to raise my hand but things moved on before I could.  ANd hard to hear people speaking away from the mic due to distortion and volume
16:28:48 <dom_> justin: this is for getting access to the pending and current remote session description
16:29:19 <dom_> ... currently, you can only get either the current or the pending description
16:29:21 <vivien> q?
16:29:25 <dom_> ... not the 2 simultaneously
16:30:01 <dom_> ... PR #225 proposes to offer both current and pending description, with pending null if none are pending
16:30:48 <jesup> vivien: sure.  I wasn't asking it to be spoken into the room.  I was noting it for the record here since things had already moved on.  I was trying to vote per the request but before I could decipher what was said and type it people had decided.  FYI
16:31:02 <dom_> ... Jan Ivar has an alternative proposal
16:31:05 <ShijunS> ShijunS has joined #webrtc
16:31:19 <dom_> ... stable vs "last-set"
16:32:39 <dom_> ... [review of pros/cons]
16:32:46 <dom_> ekr: I prefer #225
16:32:59 <mreavy|mac> what was decided regarding jan-ivar's suggestion (to add slides)?  I don't see it in the notes and that discussion happened during the worst of the static.
16:33:05 <dom_> cullen: the way to look at this is that we messed un in our initial design
16:33:25 <dom_> ... #225 gets out of our mess with a clearer set of values that can be easily understood
16:33:43 <dom_> hta: anyone who prefers Jan-Ivar model?
16:33:48 <dom_> [no one speaks up]
16:34:45 <dom_> RESOLVED: No change to session description accessors (ie leave 225 as is)
16:35:20 <dom_> Topic: dropped media
16:35:37 <dom_> [martin presenting]
16:36:03 <vivien> @@martin-slides
16:36:30 <vivien> reviewing https://github.com/w3c/webrtc-pc/pull/283
16:36:49 <dom_> Martin: the basic premise is that stuff arrive even though you didn't negotiate it
16:37:03 <dom_> ... for debugging purposes, you want to know when media arises
16:37:35 <dom_> ... you might also want to generate an offer/answer in this case but less important
16:38:28 <dom_> ... it might be that the other side has a defect (e.g. sending media in the wrong codec)
16:38:49 <dom_> ekr: I thought this was about race conditions rather than defects - defects can go to the console
16:39:13 <dom_> ... e.g. receiving media before receiving the answer
16:39:36 <dom_> ... it's likely to happen when you using @@@
16:39:45 <dom_> ... let's use this as our guidign use case
16:40:23 <dom_> s/ign/ing/
16:41:37 <dom_> martin: the PR needs to explains more what to do with the event in case of renegotiation
16:43:42 <dom_> cullen: as long as you receive packets that match your initial offer, you should be able to deal with the received media even if the signaling hasn't closed the looped yet
16:44:20 <dom_> ekr: there are 3 cases: the defect, the race condition, @@@
16:46:22 <dom_> justin: we should fast forforward the content when the stream gets actually created (?)
16:46:37 <dom_> mathieu: why do you care about getting media that early?
16:46:46 <dom_> ... how do you populate the mediastream?
16:47:04 <dom_> cullen: offer/answer is a 2-ways handshake
16:47:39 <dom_> ... imagine a re-offer - the remote media will change as soon as that offer is received, before the answer comes back
16:48:12 <dom_> ekr: this can only genuinely happen when your offer is not behind a NAT
16:49:13 <dom_> cullen: we assume that the ICE and DTLS channels have already been set up
16:49:32 <dom_> ... I agree that the mediastream setup would be tricky
16:50:23 <dom_> alex: so what do you do with the media before the answer has been received?
16:50:45 <dom_> justin: as soon as you have sent the offer, you should be able to play the media
16:51:07 <dom_> alex: how long would you keep up with that un-signalled media?
16:51:25 <dom_> bernard: the answer has also the DLTS fingerprint - how do we manage that?
16:51:40 <dom_> justin: let's keep this as a separate issue
16:52:22 <dom_> ... I think for the renegotiation case, we need to move to a situation where we have a rtpreceiver as soon as you have sent the offer
16:53:32 <dom_> cullen: so we want to close this PR and replace this with an early rtpreceiver
16:53:55 <dom_> justin: there is still the question of what the msid should be
16:54:58 <dom_> ... the question about how to deal with the case where the dtls fingerprint isn't solved yet though
16:55:44 <dom_> ... we shouldn't have different security properties based on whether an event fires
16:56:07 <dom_> ekr: a partially validated state isn't something we want to go in
16:56:21 <dom_> ... we could buffer the data as an acceptable situation
16:56:34 <dom_> ...s/situation/solution/
16:57:09 <dom_> justin: unauthenticated media should not surfaced to the app - it should be either buffered or dropped
16:58:17 <dom_> mathieu: with renegotiation based on changing certificates, how does this impact the buffering of unhandled media?
16:58:48 <dom_> justin: I think it's the same bucket as the initial dtls fingerprinting
16:59:41 <dom_> justin: do we need to deal with errant media?
17:00:02 <dom_> cullen: the ietf spec says that if you're getting rtp that doesn't match your offer, you drop it
17:00:30 <dom_> justin: I want this to be very explicit
17:00:52 <dom_> justin: we also need to determine what happens with SSRC changes
17:00:58 <dom_> ... suggest we punt this to the IETF
17:01:22 <dom_> Topic: ICE pool size
17:01:37 <dom_> cullen: we have had agreement on this for a long time, but without a specific proposal
17:01:55 <vivien> https://github.com/w3c/webrtc-pc/pull/289
17:02:06 <dom_> ... PR 289 proposes to add a new attribute to the pc to define the ICE pool size with a default to 0
17:02:44 <dom_> ... a non-0 value allows to gather ice candidates faster, to the cost of generating more ICE traffic
17:03:09 <dom_> justin: main question is whether you can set this only initially or can change it later
17:03:18 <dom_> ... [reading from jsep]
17:03:32 <dom_> ... so we may need to have this in setConfiguration as well
17:03:41 <dom_> ... in which case this PR is not sufficient
17:04:23 <dom_> peter: what happens if I have 2 transports and set the pool size to 10?
17:04:49 <dom_> justin: there will be 8 candidates that won't be used but will be kept warm
17:05:59 <dom_> hta: the semantics of having candidates in the pool need to be described somewhere
17:06:21 <dom_> ... but beyond that, is the control surface exposed on the right object? is is the right api?
17:07:52 <dom_> mathieu: what happens if you create 3 m-lines and then set the pool size to 1?
17:08:05 <dom_> ekr: sounds like a no-op
17:08:39 <dom_> justin: the only thing needed here is to add the property to setConfiguration
17:09:01 <dom_> cullen: I've added a comment to a PR
17:09:09 <dom_> justin: should we use short or long?
17:09:35 <dom_> hta: I recall the advice is to use long unless there is a specific restriction to the underlying value space
17:10:06 <dom_> Topic: review of CSRC proposal
17:10:59 <virginie> virginie has joined #webrtc
17:11:05 <dom_> [bernard presenting]
17:11:12 <dom_> [review PR 300]
17:12:19 <dom_> martin: the voiceFlag - do we need this?
17:12:45 <dom_> cullen: it is often not very reliable, but wrote it up in case someone want it badly
17:12:59 <dom_> martin: I think we should remove voiceFlag
17:13:45 <dom_> hta: so with the timestamps: we collect this data?
17:13:57 <vivien> Present: Shijun Sun, Bernard Aboba, Adam Roach, Martin Thomson, Erik Rescorla, Justin Uberti, Cullen Jennings, Ted Hardie, @@@Citrix, Peter Thatcher, @@@Google, Varun Singh, Dan Druta, Mathieu Hofman, Alexandre Gouaillard, Alan Johnston, Daniel Burnett, Dominique Hazaël-Massieux, Vivien Lacourba, Stefan Håkansson, Harald Alvestrand, Erik Lagerway
17:14:03 <vivien> On the phone: Adam Bergkvist, Jan-Ivar Bruaroey, Marie Reavy, Randell Jesup, Sherwin Sim, Victor Pascual
17:14:08 <dom_> cullen: the spec proposes a magic value of 10s of collection
17:14:55 <dom_> justin: why are we using these timestamps rather than using the immediate average?
17:15:35 <dom_> bernard: we looked at this in ORTC; the idea with this approach is to avoid having people poll very frequently to get an accurate picture
17:16:08 <dom_> justin: 10s for a real-time display sounds odd
17:16:19 <dom_> cullen: 1s woud work better for you?
17:16:28 <dom_> [agreement that 1s is sensible]
17:17:03 <dom_> hta: audioLevel - is that the latest value?
17:17:14 <dom_> cullen: I'm editing the PR as we speak
17:17:55 <dom_> justin: if there are no csrcs, @@@
17:19:04 <dom_> cullen: we could add a requirement for the browser to compute the audioLevel when not available from the mixer
17:19:21 <dom_> [agreement that this would be a good addition]
17:23:47 <jesup> can someone try leaving and re-entering, and/or check mic hardware there?  THe noise is making it really, really hard to follow remotely
17:33:11 <tedh> tedh has joined #webrtc
17:33:45 <vivien> [break ends]
17:35:25 <dom_> Topic: addmedia and warmup
17:38:21 <hta> The spreadsheet should be here:
17:38:22 <hta> https://docs.google.com/a/google.com/spreadsheets/d/14FSqawzGQCLq9pvd5mCQW5vyB-B-TIpJoHjZbPQcORg/pubhtml
17:38:29 <hta> can someone verify that this works?
17:39:52 <dom_> [Peter reviews use cases worked with the various warmup proposals]
17:40:59 <dom_> ... with createNullMedia, there is no way to know if the other side has stopped except reading the SDP
17:41:12 <dom_> ... not clear either how to deal with 187
17:41:50 <dom_> ... I've also added the race condition use case
17:43:26 <dom_> cullen: 2nd and 3rd feel quite similar
17:43:42 <dom_> ... I suggest we should first decide between 1 vs 2/3
17:43:51 <dom_> ... and then pick between 2 and 3
17:44:18 <dom_> martin: based on the earlier discussion, I'm happy to go with 3
17:44:45 <dom_> ... I don't think there is any signficiant value in patching stuff up
17:45:03 <dom_> ... the early media use case is compelling enough
17:46:19 <dom_> [several people agree 3 is right]
17:46:34 <dom_> hta; we should define addTrack in terms of addMedia if we go with 3
17:46:44 <dom_> s/;/:/
17:47:10 <dom_> mathieu: if you're already receiving video and you addTrack video to send
17:47:32 <dom_> ... you have to create a new receiver, or can you reuse it?
17:47:40 <dom_> ... what's the behavior of addtrack?
17:47:47 <vivien> q?
17:48:33 <dom_> adam: currently addtrack reuses the sender even if the receiver is in use
17:49:25 <dom_> adamB: if we define addTrack in terms of addMedia, how do we deal with the mediastream arguments?
17:50:03 <dom_> hta: addTrack would be defined as addMedia and then replaceTrack
17:50:22 <dom_> martin: I'm a little uncomfortable with the notion of having 2 or 3 ways of doing the same thing
17:50:37 <dom_> hta: I've no problems if they are only shorthands
17:50:54 <dom_> martin: but we need to make sure they have the same semantics
17:51:28 <dom_> peter: it's true that we would have to define how to deal with the streams in addTrack - but doesn't have to be doable in javascript
17:51:44 <dom_> justin: how do you put a track on hold?
17:51:54 <dom_> peter: that's not part of this PR
17:52:25 <dom_> martin: this was initially described as frobing the send/receive attributes
17:53:25 <dom_> ... I'm somewhat unhappy with the abstraction but we need to be able to do that
17:53:52 <dom_> justin: we need to make sure we get in the right direction and this won't crumble when we add these additional use cases
17:54:24 <dom_> cullen: I think we can agree this is the right direction and still need to polish it to address all the use cases
17:54:54 <dom_> stefan: how does this fit with our goal to go to 1.0? we need to set a clear deadline
17:55:44 <dom_> martin: I think we should merge with what we agree on, and do the follow-up in a subsequent PR
17:56:36 <dom_> ... we also need to understand the lifetime of identifiers
17:57:18 <dom_> justin: so we're proceeding with a couple of pull requests; we need to list explicitly the issues that will need to be addressed
17:57:26 <dom_> ... this includes the msid for early media
17:57:39 <dom_> ... what else needs to be addressed?
17:57:56 <dom_> stefan: there is also dealing with the mediastream arguments in addTrack
17:58:28 <dom_> peter: this is only an issue if we need to make addTrack implentable in JavaScript
17:58:48 <dom_> ... we could also set an additional parameter to the dictionary arguments of addMedia
17:59:21 <dom_> mathieu: one concern: "media" is a terrible overloaded term
17:59:49 <dom_> peter: we had a suggestion of RTCSdpMediaSection
18:01:28 <dom_> ... so, we know we don't want addMedia, we want something else TBD
18:01:43 <dom_> ... How do we deal with removeTrack?
18:02:18 <dom_> hta: we remove the track from the sender
18:02:39 <dom_> justin: it would be the equivalent of setting send to false
18:02:59 <dom_> peter: so removeTrack is not sending anymore but still receiving?
18:03:08 <dom_> ... I was kind of hoping we would get rid of it
18:03:36 <dom_> hta: if we define it as replaceTrack(null), then we should define replaceTrack(null) as doing what we  need
18:05:44 <dom_> peter: I'm not sure what's the benefit of removeTrack
18:06:15 <dom_> peter: so addTrack is "send/receive'
18:06:28 <dom_> ... and removeTrack is stop sending?
18:07:41 <dom_> Topic: WebRTC objects
18:07:57 <dom_> [peter presenting updated pull request for connectionState]
18:08:38 <vivien> -> https://docs.google.com/presentation/d/1ywVYamOdAh2N4H2uutdQoxc28yc49qHBbVJqH4xpf74/ Peter's slides WebRTC Objects - recap day 2
18:08:48 <dom_> peter: what state do you get in when all the transports close? should we go back to 'new'?
18:09:05 <dom_> martin: I think we need an additional 'closed' state
18:10:54 <dom_> cullen: we could rename 'new' to mean 'not yet connected' and then use it also for all closed
18:11:22 <dom_> adamR: how about 'idle'?
18:12:36 <dom_> justin: I'd be fine with using 'new'; prefer to 'idle'
18:13:13 <dom_> dom: we could start with 'closed' as websockets?
18:13:18 <dom_> justin: don't like it
18:13:24 <dom_> [coin flip]
18:13:31 <dom_> peter: 'new' it is
18:13:48 <dom_> peter: moving on the PR 273
18:14:54 <dom_> ... propose an enum with the attribute degradationPreference
18:15:05 <dom_> martin: might want to bikeshed on this in the PR
18:16:14 <dom_> peter: on to codec reordering
18:17:55 <AndyH> AndyH has joined #webrtc
18:20:22 <dom_> [agreement this is the right approach]
18:20:40 <dom_> peter: on to rtpsender.getCapabilities
18:21:54 <dom_> ... this would allow to determine whether a browser can e.g. join an existing conference in a given codec
18:22:34 <dom_> ekr: this is better than to go through createOffer but it's a very marginal improvement
18:23:00 <dom_> martin: it might actually help us with the codec preference use case
18:26:55 <dom_> ekr: given that we have RTPSender, this looks good
18:27:59 <dom_> jan-ivar: I think the name getCapabilities() is confusing since we use it for constrainable interfaces
18:28:13 <dom_> martin: I don't think that's a problem
18:28:20 <dom_> ... why is this is on sender?
18:28:26 <jesup> not that it matters to the discussion, but we do have some level of resource reservation for hardware codecs in mobile.  However, it may not be tied properly to the Promise/etc.
18:28:34 <dom_> peter: you want it on receiver too?
18:29:35 <dom_> martin: yes; checking the receiver in general might be better for the use case we described
18:30:24 <dom_> Stefan: we still don't have a proposal for reordering pre-negotiation
18:31:30 <dom_> martin: I can work on a proposal once we have the two proposals for codecs merged
18:31:36 <dom_> Topic: Simulcast
18:31:39 <vivien> -> https://www.w3.org/2011/04/webrtc/wiki/images/a/a7/Simulcast_in_WebRTC.pdf "Simulcast in WebRTC 1.0" slides
18:33:13 <dom_> bernard: based on my understanding, we only talk about simulcast from the perspective of the sender
18:34:13 <dom_> ... we have 3 options: have an option in createOffer (from adamR), use RtpSender.setParameters (from Peter), or stay with what we have (track cloning)
18:35:24 <dom_> ... in the last option, you track clones for each of your variation
18:36:20 <dom_> ... the browser might want to optimize and detect this as a simulcast, but in the dumb case, it would create 3 m-lines
18:36:40 <dom_> ... advantage is that you don't have to change anything in the spec
18:37:27 <dom_> ... you have per-encoding control through the constraints
18:37:52 <dom_> ... some apps are already doing this - not sure their devs are very happy with it
18:38:42 <dom_> varun: if you monitor the tracks, you can adjust
18:38:58 <dom_> alex: I'm not sure that getStats() give you the right info for that at the moment
18:39:33 <dom_> ... having a way to indicate to the browser that you want these tracks to be linked would be better
18:40:12 <dom_> bernard: we said we would get different m-linees; looking at the bundle draft, it wasn't clear whether they could share the same payload type
18:40:58 <dom_> cullen: if they come with different constraintsm they would have to be different payload type; not so for the bitrate
18:42:09 <dom_> cullen: having to have the JavaScript adjust the bitrate over time will interfer with congestion control; doesn't seem good
18:43:18 <dom_> martin: the problem with this option is that we don't have a clear signal from the browser side to properly optimize this
18:43:33 <dom_> [adamR presenting "option A']
18:44:10 <dom_> adamR: all this does is to add a maxSimulcastCount on RtpSender to give the signal
18:44:23 <dom_> martin: this would have to go through setParameters
18:44:27 <dom_> adamR: ok
18:44:49 <dom_> justin: this looks like OfferToReceiveVideo
18:45:19 <dom_> ... it sounds like it brings a lot of implicitness
18:45:34 <dom_> ... it delegates the negotiation to the other side (the SFU)
18:45:48 <dom_> s/... it/Cullen: /
18:46:43 <dom_> adamR: it's fairly simple to spec out
18:47:00 <dom_> ... but it doesn't give a lot of control
18:47:35 <dom_> ... there was also the approach that Harald suggested: always send e.g. 3
18:51:40 <dom_> [Peter presenting Option B]
18:52:10 <dom_> Peter: you use setParameters() to add add more encodings
18:52:34 <dom_> hta: this assume you don't need to indicate simulcast before doing createOffer
18:52:44 <dom_> peter: it doesn't change the SDP
18:52:56 <dom_> cullen: it's not consistent with the IETF documents
18:53:12 <dom_> ... you can't send stuff you haven't negotiated
18:54:28 <dom_> ... if you receive 2 ssrc from the same port, the ietf say discard one of them
18:54:53 <dom_> ... we would need to signal that this is simulcast
18:55:00 <dom_> cullen: this is no longer rtp
18:55:06 <dom_> adamR: nor SDP
18:55:49 <dom_> cullen: I think it's a great API surface, but it needs to interact correctly with SDP
18:56:11 <dom_> peter: I don't want to go there in 1.0
18:56:32 <dom_> bernard: you could trigger onnegotiationneeded when setting this?
18:56:52 <dom_> peter: no other setParameters has this effect
18:57:27 <dom_> justin: backing up a little, what we want is a workable solution for the 1.0 timeframe
18:57:55 <dom_> ... this proposal doesn't have dependencies on unfinished drafts as option A
18:58:17 <dom_> ... it relies on SFU that expect this
18:59:15 <dom_> bernard: how about an hybrid of A and B? you define your number of simulcast count ahead of the negotiation and then use this proposal to avoid the dependencies on the SDP draft
18:59:37 <dom_> cullen: what's blocking the SDP simulcast draft?
19:00:00 <dom_> adamR: there are controversies around overloading the payload type?
19:00:17 <dom_> cullen: could we get this settled by the end of Yokohama?
19:00:22 <dom_> justin: feels unlikely
19:01:31 <dom_> cullen: the API surface looks OK, but not signalling this in SDP is wrong
19:02:07 <dom_> peter: but the hybrid approach would address this right?
19:02:29 <dom_> martin: why not just fix the simulcast draft?
19:02:47 <dom_> justin: it creates a dubious dependency
19:03:28 <dom_> hta: I would object to add a dependency to another unfinished draft
19:03:39 <mathieu> mathieu has joined #webrtc
19:03:42 <dom_> justin; getting simulcast right is complicated
19:03:53 <dom_> s/;/:
19:04:03 <dom_> justin: there are a lot of details that are hard to get right
19:04:12 <dom_> bernard: this has been going on for a decade
19:05:19 <dom_> alex: if we were going for that hybrid approach with an SDP close to the current draft, without putting a hard dependency to the draft to avoid the delay, would that be acceptable?
19:05:28 <dom_> justin: if that's possible yes
19:05:44 <dom_> adamR: but that means this group is starting to define SDP semantics
19:07:13 <dom_> hta: we could define the API surface without depending on the protocol wire
19:08:06 <dom_> ... what's important to me is that you can ship a conformant implementation without @@@
19:10:47 <dom_> justin: it feels like we don't have a mature proposal for 1.0
19:11:05 <dom_> cullen: I think we need this for 1.0
19:11:34 <dom_> ekr: I think we should figure out how far we are to consensus before getting in the in/out discussion
19:12:35 <dom_> bernard: current status (option C) is not completely satisfactory
19:12:49 <dom_> ... option A relies on the MMUSIC draft
19:13:29 <dom_> ekr: is the only problem with C that the browser can't be smart about it?
19:13:49 <dom_> ... its major advantage is that it doesn't require any new SDP
19:14:12 <dom_> ... could we reuse that SDP with the other proposals?
19:14:22 <dom_> bernard: there is a gotcha there
19:14:33 <dom_> ... @@@
19:15:16 <dom_> peter: we could go to an option D where you clone tracks and then frob the framerate scale
19:15:47 <dom_> justin: option C is not compatible with scalable coding, so it's a non-starter for me
19:16:12 <dom_> cullen: agree
19:16:46 <dom_> hta: it's also perfectly possible to define this as an extension spec
19:17:14 <dom_> ... and bake it separately from the spec
19:18:13 <dom_> dom: +1
19:18:33 <dom_> cullen: would not be happy with this given that browsers are shipping something in this space
19:18:52 <dom_> ekr: what are the obstacles on converging?
19:20:07 <dom_> justin: I would be much more confident that we could make progress in a separate spec
19:20:28 <dom_> ... clearly it's nowhere near a slam dunk in terms of consensus
19:22:38 <dom_> ted: do we already know whether an extension spec would go toward a or b today?
19:23:19 <dom_> justin: I would prefer B
19:23:42 <dom_> dom: I think option A is basically optimized for 1.0 shipping
19:24:00 <dom_> ... so if we were going to an extension spec, B would seem the logical focal point
19:26:34 <dom_> justin: B' seems to be the right approach
19:26:41 <mreavy> mreavy has joined #webrtc
19:27:07 <dom_> cullen: B' sound good, but I want this in 1.0
19:27:49 <dom_> stefan: who would object to have it as a separate draft?
19:27:53 <dom_> cullen: I would
19:28:04 <dom_> hta: having a separate draft doesn't prevent bringing in back
19:28:31 <Keith> Keith has joined #webrtc
19:29:59 <dom_> ted: as an rtcweb co-chair, I wanted to ask if requesting MMUSIC to have an interim before the Yokohama meeting so that they can have input before your TPAC meeting
19:30:28 <dom_> [nods]
19:31:06 <dom_> erik: we don't have consensus, which means simulcast is out for now
19:31:19 <dom_> hta: there seems to be consensus on B' being the right starting point
19:33:02 <dom_> cullen: how about we merge something with indications there is no consensus yet?
19:33:53 <dom_> hta: I don't want to wait until this gets decided before we finalize the in/out
19:34:14 <dom_> ... if mmusic says they can have an interim, we could delay till TPAC
19:34:24 <dom_> ... if not, it's out
19:34:51 <dom_> cullen: I think the out decision would have te be made by the the WG, not automatic
19:36:18 <dom_> ekr: we should work on PR, see where the MMUSIC is going, and decide whether the proposal has consensus, there is consensus it's not ready, or there is no consensus, and then make a decision on a call
19:36:41 <dom_> hta: we could say we should schedule a call once we have an answer from MMUSIC
19:38:32 <dom_> hta: we would need a baked proposal 1 week before the call
19:38:39 <jesup> hear
19:38:54 <dom_> ted: there needs to be a 2 weeks advance notice for the MMUSIC interim
19:39:26 <dom_> ... plus the time for logistics, earliest would be 4 weeks
19:40:10 <dom_> erik: so we say it's out?
19:40:24 <dom_> cullen: no, it's not yet decided whether it's in or out
19:41:04 <dom_> danB: it's the same as others: until we have a ready PR, it's not going to be merged
19:41:23 <dom_> erik: so it's undecided
19:42:35 <dom_> stefan: when should we plan to have our a call?
19:42:44 <dom_> dom: let's settle this offline
19:52:38 <Zakim> Zakim has left #webrtc
20:15:27 <tedh> tedh has joined #webrtc
20:31:55 <vivien> [meeting resumes]
20:33:05 <dom> dom has joined #webrtc
20:33:28 <varun> varun has joined #webrtc
20:33:36 <vivien> scribe: varun
20:33:37 <varun> session starting.
20:33:46 <dom> Topic: in and out webrtc 1.0
20:34:15 <varun> stefanh: discussing PRs that are accepted
20:35:36 <varun> stefanh: discussing 291
20:36:05 <varun> petert: for 291, nothing needs to be messaged. confirm?
20:36:42 <varun> stefanh: 271, warmup is part of the transceivers.
20:37:19 <varun> adamR: related to 279, are we deprecating the offerToReceive?
20:37:29 <varun> justinu: yes.
20:37:54 <varun> stefanh: 300, is going address CSRC issues.
20:38:08 <varun> stefanh: 284, review ICE errors offline.
20:39:58 <varun> martint: will read and confirm if 284 looks good.
20:40:02 <mathieu> mathieu has joined #webrtc
20:41:32 <varun> stefanh: we haven't confirmed if we like addMedia as the name of the API
20:42:24 <varun> justinu: there is a distinction if people have reviewed the PR and looks good, and names and nits need to be fixed
20:42:36 <varun> stefanh: RtpSenderInit, in or out?
20:43:00 <varun> petert: has been outdated with transceivers. close PR.
20:43:33 <varun> stefanh: are we done? i.e., no more features to be added.
20:45:12 <varun> cullen: are we done? we are need diagnostics and stats to be added.
20:45:35 <varun> janivar: PR 301 is still needed.
20:46:32 <varun> ericr: not overly worried, if we are missing some information with getStats.
20:46:59 <varun> burn: can we make the decision: better error reporting and stats is not considered new features, just simple enhancements
20:47:25 <dom> dom has joined #webrtc
20:47:36 <varun> Topic: Media capture
20:48:20 <varun> dom: Mediacapture went to LC. some comments are still pending.
20:48:34 <varun> dom: l18n looked okay
20:48:54 <varun> dom: comments on error reporting was raised.
20:49:07 <burn> Actually, I said better error reporting and conformance statements (not stats per se) are not considered new features
20:50:18 <varun> dom: got comments from Privacy WG, not entirely sure if this LC or not. therefore still waiting for clarification.
20:50:41 <varun> dom: TimedText WG, input was to clarify scope
20:51:07 <varun> dom: Also got input from Audio WG.
20:51:38 <varun> AdamR: volunteered to write the audio output...
20:52:31 <varun> topic: how to handle new constraint extensions.
20:52:37 <vivien> -> https://www.w3.org/2011/04/webrtc/wiki/images/f/f3/Constraints_handling.pdf slides
20:52:48 <RRSAgent> I have made the request to generate http://www.w3.org/2015/09/10-webrtc-minutes.html vivien
20:52:59 <varun> stefanh: discussion about registry if this is the right way forward or not.
20:54:17 <varun> stefanh: recapping requirements
20:56:46 <varun> ericr: why are we using meeting time to discuss this.
20:57:14 <varun> martint: this is largely a management problem, it depends where you want to document this.
20:57:29 <varun> cullen: how would this work?
20:57:48 <varun> martint: find the right venue to get this done.
20:58:41 <varun> ericr: 4 people want this, and they will figure out what they want.
20:59:07 <varun> cullen: what if they do not want to come to this organization.
20:59:22 <varun> dom: we could use company prefixes
21:00:05 <varun> cullen: but we want other people to also be able to use the same constraints.
21:00:36 <varun> cullen: I am okay for setting the bar as specification needed, but someone should make this proposal.
21:01:55 <varun> ericr: registries are needed(?) when there are volume of people wanting to reserve a code point or implement something
21:02:19 <varun> cullen: we know that we do not want to have collision in the namespace
21:03:03 <varun> dom: there is a clear IPR process for W3C, but not the same outside it.
21:03:45 <varun> dom: let's just do what we have been doing for other W3C process for example, attributes, etc. We could just follow that. i.e., make it specification needed.
21:04:13 <varun> hta: Perhaps we need to go through the process of: do we need a registry? is IANA appropriate?
21:05:00 <varun> dom: it was not clear if the registry has complete list or list of what needs to be done to be compliant
21:05:53 <varun> ericr: the good thing about using a registry is that it lists all the attributes in one place. and you can see the links of the documents, that define them.
21:06:31 <varun> martint: we have several documents that use the constraints, e.g., depth, screen capture, etc
21:07:02 <varun> burn: I wrote a draft that will have all this information.
21:07:26 <varun> ericr: I would like the chairs to resolve this.
21:07:44 <varun> hta: show of hands for 1) registry or no registry. 2) IANA or not IANA.
21:08:39 <varun> burn: the registry document says: specification needed not necessarily a w3c recommendation.
21:08:57 <varun> ericr: w3c recommendation is a high bar.
21:09:40 <jesup> I agree with ekr
21:10:03 <sherwinsim> No registry
21:10:04 <varun> hta: asking the question (1) registry or not registry: 8 vs 5
21:10:09 <jib> I voted we do not need registry
21:11:57 <varun> hta: we have to decide, we don't seem to have consensus.
21:12:16 <ggb> ggb has joined #WebRTC
21:12:35 <varun> dom: there is an alternative, that chairs can make a decision. and those who feel strongly can object
21:13:27 <varun> dom: let's take the formal vote
21:14:05 <varun> cullen: we might have to get a Yes/No question. so the question would have to be framed that way
21:14:32 <varun> hta: so a PR will be created that will add the registry and the vote will be to accept the PR
21:15:33 <varun> topic: Timed Media WG synchronization of work
21:16:10 <varun> dom: we could decide to move some of our work, all of our work, or none of our stuff. Related to media capture, media capture from element, screen capture. etc
21:16:14 <vivien> -> https://lists.w3.org/Archives/Public/public-media-capture/2015Sep/0006.html "Timed Media WG discussion" email from Dom
21:16:39 <varun> dom: is there any opinions?
21:17:40 <varun> mathieu: I see potential for that group to take on work related to recording but not really clear if something from here should move.
21:17:59 <varun> martint: capture from element could move
21:18:44 <varun> cullen: Cisco cannot join timed media WG because of IPR issues, so I would recommend not moving screen capture to that group.
21:19:08 <varun> s/ericr:/ekr:/r
21:21:00 <varun> dom: what would happen to the work is started there, if there is interest to do it here ...
21:21:21 <varun> hta: is there anyone here who expects to be working in Timed Media WG?
21:21:36 <varun> hta: --- no one raised hands ---
21:21:37 <jib> what was the result of that hand-raising?
21:21:49 <varun> topic: WebRTC NV
21:22:13 <vivien> -> https://www.w3.org/2011/04/webrtc/wiki/images/2/2c/WebRTC_NV.pdf  slides
21:22:19 <varun> hta: this is the new charter text, during the recaharter process.
21:23:10 <varun> hta: what comes next: predict the stumbling blocks so that we do not stumble.
21:24:12 <varun> hta: 1.0 and NV are going to interoperate.
21:24:46 <varun> hta: SDP is not required. However, it must expose everything for SDP to be created.
21:25:29 <varun> ekr: I dont think that this is really true: i.e., being able to do SDP via NV.
21:26:02 <varun> @jib: vote IIRC.
21:26:11 <varun> @jib: formal vote IIRC.
21:26:42 <varun> hta: what are the contentious issues.
21:27:07 <varun> bernard: non-mux, parallel forking.
21:27:39 <varun> cullen: is this something we would need an API or what would be the resolution?
21:28:06 <varun> bernard: it was tricky not necessarily contentious.
21:29:00 <varun> bernard: modes of SVC.
21:30:43 <varun> ekr: PERC
21:31:55 <varun> ekr: people may ask for pluggable congestion control for datachannels
21:32:58 <varun> ekr: so something to think about are application replaceable components, since the design of ORTC looks like something that can be glued together.
21:33:38 <varun> hta: codec version control?
21:33:44 <varun> ekr: what is it?
21:34:56 <varun> ekr: we are under the impression that we will enable vc-x when we are ready
21:35:37 <varun> ekr: hence, I believe the expectation is to have pluginnable codec.
21:36:06 <varun> martint: this is similar to font
21:36:22 <varun> justinu: fonts are not executable...
21:36:32 <varun> martint: font files are turing complete.
21:37:26 <varun> petert: getStats() might be contentious
21:38:43 <varun> ekr: the amount of control that you can have on the unsecured client side. that needs to be re-considered?
21:39:48 <varun> hta: we want to do simple additions, but should we dream bigger?
21:39:58 <jesup> FYI: pluggable codecs are quite doable.  Hardest is dealing with negotiation aspects and config and packetization, but the pluggable codec could provide a JS module that handles some of this to the browser, or we just define some APIs at the plug interface for handling that.  Not every possible codec is doable, but most should be.
21:40:19 <varun> ekr: we have done a lot of work for v1.0, I believe v1.1 should be a relatively quick turnaround.
21:40:24 <tedh> tedh has joined #webrtc
21:40:54 <varun> juberti: v1.1 is not the end, there will be v1.2, v1.5, ...
21:41:42 <varun> ekr: reason to do NV is to get rid of things that were problematic to do in v1.0.
21:43:08 <varun> adambe: perhaps, yes. I dont see it on the screen
21:43:30 <jesup> I have a warning about low bandwidhth/cpu/etc instead of video
21:43:42 <adambe> same here
21:44:00 <adambe> it tires to reload now and then
21:44:16 <jib> same here
21:44:31 <varun> burn: people have requested extensions. Some of the extensions are fundamental. When we started WebRTC it was for real-time communication. Perhaps we need to revisit this from those use-cases
21:45:08 <varun> hta: we got a use-case to playback things faster than real-time, for media processing. However, we should be cognizant about the goals of the WG.
21:45:36 <varun> hta: "We (chairs) need to make a plan to make a plan to execute a plan".
21:46:53 <varun> hta: running ahead of time, doing slides from 15xx session
21:47:09 <varun> topic: capture from element (no slides)
21:47:47 <vivien> https://github.com/w3c/mediacapture-fromelement
21:48:09 <varun> Issue #11
21:49:08 <varun> martint: we were running a timer, when the item would get the canvas. This made the graphics people unhappy, because it was doing extra draws.
21:50:50 <varun> hta: if nothing happens in the canvas, what is the timecode on the frame when something happens.
21:52:02 <varun> martint: we get the timecode when we get the data. i.e., we have a flag on the canvas. when the flag changes, it pulls the frame and gets that timecode.
21:52:28 <varun> mathieu: the screencapture does the same thing, so there shouldnt be an issue.
21:52:48 <varun> martint: exactly, except screencapture runs at the framerate.
21:53:15 <varun> martint: there is an interesting bit here. when the origin is not clean, it will not capture anything.
21:54:02 <varun> mathieu: what happens when there are multiple draws in a single render loop.
21:54:46 <varun> martint: in a JS code, you have several draws or a promise that does micro tasks. But this thing only calls when it is in steady state.
21:55:14 <varun> martint: if you want something more complex then you need to manually do frame capture.
21:55:31 <varun> discussing issue #12
21:55:56 <jesup> Capturing my comment: This is better than the original spec.  Also, it's similar to a screencapture - you don't want to generate no-difference frames
21:56:19 <varun> martint: in the main spec, when capturing from the video element, the tracks would appear or disappear based on when they are played.
21:56:31 <jesup> (that was to issue #11)
21:56:52 <varun> martint: i.e., if you had multiple audio tracks, you'd get a copy of those tracks and not the mixture of those.
21:59:17 <varun> martint: explaining the diff...
21:59:53 <varun> burn: if the stream is paused. would there be a paused?
22:00:50 <varun> martint: Yes, if 10s of mute, then there is no data for that. However, there is mute flag which would mean that there is no data for that period.
22:01:20 <varun> martint: explaining what happens when you do seek into those mute periods.
22:02:03 <varun> mathieu: then there is a way to plug mediastreams into peerconnection.
22:02:16 <burn> I understood martin to say that 10s of mute will turn into 10s of silence/black/etc. in the capture
22:03:04 <varun> @burn: was that due to the flag or actual silence data/black screen.
22:03:30 <varun> correct my notes if needed.
22:04:12 <burn> it would match the user experience of n seconds of silence/black
22:04:38 <varun> martint: I would like someone to have a look at this. Andreas is implementing most of this.
22:05:49 <jib> https://docs.google.com/presentation/d/1oraNTbn4XMCiWlJ-O7iJ5DwT1U0ycT3plJq00pToFHc/edit?usp=sharing
22:06:38 <vivien> Topic: getStats
22:06:49 <vivien> scribe: burn
22:08:09 <burn> jib:  dictionaries have copy semantics, so what you get back is base class and not deeper object
22:10:55 <burn> ... second issue is that getter is legacy tech.  recommendation is to use maplike which give you keys that are useful for looking up other stuff
22:11:34 <burn> ... this change would be breaking, but now would be a good time to make the change
22:11:46 <burn> cullen: which version of webidl contains maplike?
22:12:00 <burn> jib:  es6 has maplike.  it's already in webidly.
22:12:06 <burn> webidl
22:12:43 <burn> hta: compatibility with getter interface is easy.  just define a legacy getter.
22:12:45 <burn> jib:  agreed
22:13:28 <burn> varun:  how much effort would this take for the browsers to support this?  Don't want incompatbility.
22:14:02 <burn> jib:  we already have binding code.  in PR 301 we have support for it.  For FF should be easy
22:14:09 <vivien> -> https://heycam.github.io/webidl/#idl-maplike maplike in the webidl editors' draft
22:14:38 <burn> hta: don't know about maplike in Link
22:15:36 <burn> hta:  effort is small.  does group like this?  specifically users of getStats.  What do you think of this API change?
22:16:03 <burn> varun:  we already have two code branches, so if you can converge that would help.  maplike is fine if all support it.
22:16:15 <burn> mathieu:  definietly seems easier for enumeration
22:16:46 <burn> cullen:  this is a problem area for us too (the changing implementations)
22:17:00 <burn> martin:  we accept patches
22:17:17 <burn> jib:  adapter.js could polyfill better here
22:17:35 <burn> justin:  hopefully adapter.js will get smaller . . .
22:18:45 <burn> hta:  looks like we should accept maplike.  see 3 approaches on webidl: 1. webidl should fix dictionaries. 2. replace dictionary with interface 3. the proposal from jib, to define an idl type that is the union of all idl types
22:19:07 <burn> jib: one webidl expert said the union type was a good idea
22:19:34 <burn> jib:  could be done with a typedef
22:20:11 <burn> hta:  doesn't solve problem.  can't have one-line typedef that says this dictionary and all sub-dictionaries.  that union would currently have something like 30 units.
22:20:32 <burn> cullen: how would it work to add the 31st?
22:20:44 <burn> hta:  yes, that wouldn't be included automatically
22:20:59 <burn> jib:  being able to return a union of all the classes sounds like a good thing.
22:21:44 <burn> hta: suggest going with object solution but note that we would like webidl support for the descendent dictionary union
22:21:46 <jesup> I'm in favor of this PR (no surprise)
22:21:51 <burn> jib: that's what 301 does
22:22:07 <burn> hta:  everyone okay with object?
22:22:13 <burn> (no objectiotns)
22:23:33 <burn> erik:  what do we want to do for tpac?
22:23:47 <burn> justin:  let's figure out who has what work to do.  peter do you have anything?
22:24:57 <burn> peter:  i have some slides showing a possible path from where we are to a model where you can control everything without peerconnection.  could be input for 1.1.
22:25:24 <burn> cullen:  what will happen as these issues resolve?  what happens after last call comments are resolved
22:25:53 <burn> dom:  we will ask the WG to review it.  Hopefully this will happen within a few weeks.
22:26:33 <burn> hta:  hope for a gUM revision that is "finished" that the group can review in a few weeks and go to CR before TPAC
22:27:29 <peter> peter has joined #WebRTC
22:27:35 <peter> https://docs.google.com/presentation/d/1508OJ_fhHjAkxxvM2_efa1EMsMQPi51zc2zHZ6kksvE/edit#slide=id.gba167d382_0_5
22:28:05 <burn> dom:  for those of you with google docs, spreadsheets, etc please send a pdf of them for archives
22:29:18 <burn> (peter shows slides 1 - 3)
22:29:48 <burn> peter:  iceTransport  would have gather and start methods
22:29:59 <burn> ekr: how do you bind multiple ice transports in a single context
22:30:07 <burn> peter:  on the last slide
22:30:39 <burn> Then for dtlsTransport, there are start and stop methods
22:30:48 <burn> ekr:  will you show params for these later?
22:30:52 <burn> peter:  maybe
22:31:08 <burn> hta:  on iceTranport, where is pool size?
22:31:24 <burn> mathieu:  why can't you just start gathering and make that the pool size
22:31:34 <burn> cullen:  sounds like a great config option
22:31:58 <burn> hta:  goal of option in 1.0 is to make a pool that transports can pull from.
22:32:22 <burn> peter:  ortc has a way to do this
22:32:57 <burn> ekr: let's say i have an ice transport and put a dtls transport on top of it.  what's the behavior we can expect?
22:33:15 <burn> peter:  dtlsTransport would know the state of ICE
22:33:42 <burn> justin:  start doesn't mean send, it just means start working
22:34:12 <burn> ekr:  is the model such that the dependencies between them are automatically managed?
22:34:15 <burn> bernard:  yes
22:35:05 <burn> peter:  rtpSender - setTransport handles bundle/unbundle
22:35:42 <burn> mathieu:  what about rtptransciever?
22:35:53 <burn> peter:  not needed here because there is no SDP
22:36:29 <burn> peter: send starts the sender.  for RTPReceiver, you have a receive() method
22:36:46 <burn> hta: are these always connecetd to a transport but you can change it?
22:36:49 <burn> peter:  yes
22:37:30 <burn> cullen: if i have transports over different interfaces, can I move a stream with no interruption?
22:37:35 <burn> bernard:  sholud be able to
22:37:46 <burn> ekr: would you do it as two separate transports?
22:37:59 <burn> bernard:  if ICE is as capable as we want, no?
22:38:52 <burn> Peter:  RTP example.  gather ice candidates, start transports, the send and receive
22:39:06 <burn> justin:  something like 10 methods to provide all this control
22:40:07 <burn> jib:  don't see promises here. was that intentional?
22:40:09 <burn> peter:  yes
22:40:24 <burn> ekr:  what must be synchronous?
22:40:58 <burn> ... seems like some state info is missing
22:41:08 <burn> justin:  state info is already (still) here from 1.0
22:42:23 <burn> peter:  sctpTransport + DataChannel - a dataTransport is an SCTPTransport.  Need to be able to get and signal SctpCapabilities.  Can have more than one association.
22:43:12 <burn> adamb:  regarding promises, how does a track get returned for receiver.receive ?
22:43:50 <burn> justin:  you don't get media until O/A finishes, but track exists from addTrack as today
22:44:04 <burn> jib:  how do you learn of failures?
22:44:09 <burn> bernard:  they all have onerror
22:44:43 <burn> peter:  dataChannel example.  create and start ice, dtls, sctp,.  datachannel itself just like today
22:45:43 <burn> peter:  (very busy dictionary slide) want more info on ice candidates and codecs is primary change
22:45:57 <burn> adambe:  why can't current dictionaries look like this?
22:46:04 <burn> ... (today)
22:46:42 <burn> peter:  i first tried to create this, but I thought it might conflict with current object use for iceCandidate
22:47:00 <burn> ... if it's safe to add these, then I'm happy to :(
22:47:13 <burn> hta:  could just make all of them readonly, existing ones too.
22:47:50 <burn> martin:  making these interfaces would be terrible.
22:48:43 <burn> ... I have a PR that will remove the interface and replace it with the dictionary.  We could have rules for where we look for this info.
22:48:47 <burn> peter:  I will make a PR.
22:50:03 <burn> ... (and a few other things slide) there would be a getStats and onerror on everything.  Need RTCDTMFSender, something for identity, and a way to say that iceTransports belong together and need to be checked in a certain order.
22:50:40 <burn> martin:  do you add them or does it act as a factory?
22:50:55 <burn> ekr:  you should be pacing your gathering and checks
22:51:30 <burn> justin:  this allows grouping for different sessions as needed.
22:52:01 <burn> hta: two different ways to do this. (missed these)
22:52:27 <burn> peter:  with optional index can decouple creation and checking order
22:52:57 <burn> justin:  this provides freezing control but not necessarily global pacing.  also provides grouping for bandwidth estimation purposes.
22:53:19 <burn> cullen: if global pacing is useful in needs to apply across the browser and not just here
22:53:44 <burn> ekr:  yes and no.  we don't do it that way.  we pace individual PCs and then have a global circuit breaker
22:54:56 <burn> justin: global pacing the browser needs to enforce overall.  this API provides local context and control.
22:55:14 <burn> jib: you had signaling in your example,  is theer onnegotiaionneeded?
22:55:26 <burn> justin:  up to the app to do itself if/when it wants to.
22:55:43 <burn> martin:  you could make your own SDP and O/A if you cared to
22:56:17 <burn> cullen:  might need info to negotiate what codec details need to be set
22:56:30 <burn> peter:  codec capability info contains all of this.
22:57:35 <burn> ... there is a preferredPayloadType to make it easier to figure out which payload type to choose
22:58:26 <burn> bernard:  very useful when you have capabilities and not settings to exchange.  when you call receive you need to know what payload type the other side is going to choose.
22:59:22 <burn> martin:  this dictionary is very close to the setting object structure.  why don't you just call this payloadtype so you can pass it in to the setter.
22:59:34 <burn> ... ssrc?
22:59:46 <burn> peter:  if you have mid you don't need ssrc
23:00:26 <burn> ekr:  does this support the combinatorial explosion of profiles, fec parameters, etc.?
23:00:38 <burn> peter:  there is no good way to express that
23:01:37 <burn> martin:  implementatnios will support listing some subset of capabilities down the road.  there are many variations of possible capabilities
23:01:45 <burn> ekr:  what are the defaults?
23:02:09 <burn> peter:  don't know
23:03:22 <burn> ekr:  are these dictionaries special in some way or can I synthesize them myself?
23:03:45 <burn> martin:  can you just change values before sending it to the browser?
23:04:00 <burn> peter:  if the values are consistent with the capabilities, then that's fine
23:05:08 <burn> ekr:  if they were interfaces and constructed there wolud be a disincentive to mess with the values.  We will see apps that will hardcode h.264 and vp8 in the list of codec capabilities.
23:05:16 <burn> ... this would be harder with interfaces.
23:06:47 <burn> jib:  since you have onerror, instead of having a method that has an interface that takes a bunch of attributes, just have a bunch of attributes that are read at the end of the event loop
23:07:08 <burn> ... we didn't have onerror before, so it's the presence of that handler that would make this feasible.
23:08:17 <burn> hta: we are at the end of our session.  We resolved some things and are going to encourage people to work hard on over the coming weeks, not months.  Chairs will take responsibilty for moving the registry decision onward.
23:08:30 <tedh> tedh has joined #webrtc
23:08:55 <burn> stefan:  do you all have time to put into all of this over the coming weeks?  It seems that there is a short list of people who have to do all this.  Martin, Justin, Peter in person.
23:09:03 <burn> Peter:  No problem.
23:09:41 <burn> justin:  is there a list of which areas people need help with so others can volunteer to help?
23:10:02 <burn> martin:  yes, a list of important items with whose responible would be really helpful.
23:10:09 <burn> justin:  is travis still busted?
23:10:30 <burn> dom:  I fixed the link checker bug, but I'm wokring on something less brittle.
23:11:05 <burn> ekr: can you restart travis?
23:11:07 <burn> dom:  yes
23:11:36 <burn> ... i will look into this.  ignore travis for the moment.
23:12:38 <burn> dom:  tpac registration.  don't forget.   you have to rejoin the group if you haven't. (your company)
23:13:07 <burn> stefan:  thanks to Microsoft for hosting.
23:13:40 <vivien> [meeting adjourned]
23:13:46 <vivien> RRSAgent, draft minutes
23:13:46 <RRSAgent> I have made the request to generate http://www.w3.org/2015/09/10-webrtc-minutes.html vivien
23:34:16 <jesup> jesup has left #webrtc
23:47:39 <adamR> adamR has joined #webrtc