19:50:00 <burn> zakim, who's here?
19:56:00 <burn> zakim, this is webrtc
19:56:00 <Zakim> ok, burn; that matches UW_WebRTC()4:00PM
19:56:00 <burn> zakim, who's here?
19:56:00 <Zakim> On the phone I see +1.407.421.aaaa
19:56:00 <Zakim> On IRC I see mreavy, Zakim, silvia, martin, burn, stefanh, lgombos, christer, tuexen, jeffh, derf, decadance, j_a, Josh_Soref, timeless, richt, slightlyoff, trackbot, ed, heath,
19:56:00 <Zakim> ... schuki
19:56:00 <burn> zakim, aaaa is Dan_Burnett
19:56:00 <Zakim> +Dan_Burnett; got it
19:56:00 <burn> zakim, I am Dan_Burnett
19:57:00 <Zakim> ok, burn, I now associate you with Dan_Burnett
19:57:00 <Zakim> + +49.441.6.aabb
19:57:00 <Zakim> + +46.1.07.14.aacc
19:58:00 <tuexen> zakim, aabb is tuexen
19:58:00 <Zakim> +tuexen; got it
19:58:00 <Zakim> + +1.403.244.aadd
19:58:00 <stefanh> zakim, aacc is me
19:58:00 <Zakim> +stefanh; got it
19:58:00 <Zakim> + +91.22.39.14.aaee
19:58:00 <fluffy> zakim, aadd if fluffy
19:58:00 <Zakim> I don't understand 'aadd if fluffy', fluffy
19:58:00 <Zakim> +[IPcaller]
19:58:00 <Zakim> + +1.858.651.aaff
19:58:00 <fluffy> zakim, aadd is me
19:58:00 <Zakim> +fluffy; got it
19:59:00 <Zakim> + +1.940.735.aagg
19:59:00 <martin> zakim, aaff is me
19:59:00 <Zakim> +martin; got it
19:59:00 <Zakim> + +358.405.60aahh
19:59:00 <Zakim> +Jim_Barnett
20:00:00 <Zakim> + +1.630.423.aaii
20:00:00 <stefanh> agenda proposal: http://lists.w3.org/Archives/Public/public-webrtc/2013Sep/0005.html
20:01:00 <Zakim> + +1.831.426.aajj
20:01:00 <Zakim> + +33.2.31.26.aakk
20:01:00 <Zakim> + +61.2.809.0.aall
20:01:00 <silvia> zakim, aall is me
20:01:00 <Zakim> +silvia; got it
20:02:00 <silvia> zakim, mute me
20:02:00 <Zakim> silvia should now be muted
20:02:00 <Zakim> + +358.942.72aamm
20:02:00 <Zakim> + +1.561.923.aann
20:02:00 <Zakim> + +44.190.881.aaoo
20:02:00 <Zakim> -[IPcaller]
20:02:00 <jesup> trouble getting into the bridge
20:02:00 <tuexen> zakim, mute me
20:02:00 <Zakim> tuexen should now be muted
20:02:00 <Zakim> - +1.831.426.aajj
20:02:00 <Zakim> +Dan_Druta
20:02:00 <Zakim> + +46.1.07.14.aapp
20:02:00 <Zakim> + +1.650.275.aaqq
20:02:00 <Zakim> + +1.831.426.aarr
20:02:00 <hta1> zakim, aaqq is me
20:02:00 <Zakim> +hta1; got it
20:02:00 <gmandyam> Stefan, Giri Mandyam present on phone and IRC as an observer
20:02:00 <matthew> zakim, aarr is me
20:02:00 <Zakim> +matthew; got it
20:03:00 <Zakim> + +1.610.889.aass
20:03:00 <Zakim> +[Mozilla]
20:03:00 <jesup> zakim: aass is me
20:03:00 <Zakim> + +1.425.893.aatt
20:03:00 <jesup> zakim, aass is me
20:03:00 <Zakim> +jesup; got it
20:03:00 <Zakim> +[IPcaller]
20:04:00 <ekr> zakim, who is here?
20:04:00 <Zakim> On the phone I see Dan_Burnett, tuexen (muted), stefanh, fluffy, +91.22.39.14.aaee, martin, +1.940.735.aagg, +358.405.60aahh, Jim_Barnett, +1.630.423.aaii, +33.2.31.26.aakk, silvia
20:04:00 <Zakim> ... (muted), +358.942.72aamm, +1.561.923.aann, +44.190.881.aaoo, +46.1.07.14.aapp, Dan_Druta, hta1, matthew, jesup, [Mozilla], +1.425.893.aatt, [IPcaller]
20:04:00 <Zakim> On IRC I see Dini, ekr, AndyH, Jim, Richard, DanD, jesup, matthew, adambe, hta1, gmandyam, Mary, fluffy, mreavy, Zakim, silvia, martin, burn, stefanh, lgombos, christer, tuexen,
20:04:00 <Zakim> ... jeffh, derf, decadance, j_a, Josh_Soref, timeless, richt, slightlyoff
20:04:00 <stefanh> scribenick: adambe
20:04:00 <martin> zakim, [IPcaller] is me
20:04:00 <Zakim> +martin; got it
20:04:00 <ekr> zakim, [Mozilla] is me
20:04:00 <Zakim> +ekr; got it
20:04:00 <christer> zakim: aahh is me
20:05:00 <adambe> stefanh: I posten a link to the slides
20:05:00 <adambe> ... we should go throug the minutes from the last meeting
20:05:00 <adambe> ... (walkes us through the agenda)
20:05:00 <Zakim> -martin.a
20:05:00 <stefanh> mintes from last meeting: http://lists.w3.org/Archives/Public/public-webrtc/2013Feb/0026.html
20:05:00 <adambe> ... last meeting minutes are from February in Boston
20:06:00 <adambe> ... can we approve the minutes?
20:06:00 <adambe> .. ok, they are approved
20:06:00 <adambe> ... next thing, implications of the IETF decisions
20:06:00 <Zakim> + +1.908.541.aauu
20:06:00 <adambe> ... juberti will talk us through the unified plan
20:06:00 <ekr> He doesn't sound any more dalek-like than usual
20:07:00 <Zakim> -matthew
20:07:00 <adambe> ... I was asked to talk about what will be the next version of JSEP
20:07:00 <adambe> stefanh: do we have any slides?
20:07:00 <adambe> juberti: no slides (short notice)
20:08:00 <Zakim> +[IPcaller]
20:08:00 <martin> zakim, [IPcaller] is me
20:08:00 <Zakim> +martin; got it
20:08:00 <adambe> juberti: it has been pointed out that we need normative behavior for createOffer/Answer/setLocal...
20:08:00 <adambe> ... I've talked to fluffy about it
20:08:00 <Zakim> +??P29
20:09:00 <Zakim> + +1.908.559.aavv
20:09:00 <adambe> ... and we will have a new version in two weeks
20:09:00 <adambe> ... (of the JSEP draft)
20:09:00 <Zakim> + +33.6.85.56.aaww
20:09:00 <matthew> my SIP-to-PSTN call was terrible, but SIP directly sounds great
20:10:00 <matthew> and martin, i think you associated my [IPcaller] with you
20:10:00 <adambe> hta1: do you see any other blockers
20:10:00 <adambe> ... ?
20:11:00 <Zakim> + +1.267.934.aaxx
20:11:00 <adambe> ... there are some issues that needs to be clarified in the unified plan before they can go into JSEP
20:11:00 <adambe> ... these issues are minor
20:12:00 <burn> zakim, who's on the phone?
20:12:00 <Zakim> On the phone I see Dan_Burnett, tuexen (muted), stefanh, fluffy, +91.22.39.14.aaee, martin, +1.940.735.aagg, +358.405.60aahh, Jim_Barnett, +1.630.423.aaii, +33.2.31.26.aakk, silvia
20:12:00 <adambe> ... and shouldn't block a release of a useful JSEP draft
20:12:00 <Zakim> ... (muted), +358.942.72aamm, +1.561.923.aann, +44.190.881.aaoo, +46.1.07.14.aapp, Dan_Druta, hta1, jesup, ekr, +1.425.893.aatt, +1.908.541.aauu, martin.a, ??P29, +1.908.559.aavv,
20:12:00 <Zakim> ... +33.6.85.56.aaww, +1.267.934.aaxx
20:12:00 <adambe> ekr: (scribe didn't get this)
20:12:00 <JeromeMarcon> +33.6.85.56.aaww = JeromeMarcon
20:12:00 <ekr> adambe: I was saying we need some way to indicate which flows are first class and which ones were bundle only
20:12:00 <martin> zakim, aaww is JeromeMarcon
20:12:00 <Zakim> +JeromeMarcon; got it
20:12:00 <adambe> thanks
20:13:00 <Zakim> +??P5
20:13:00 <jesup> still here
20:13:00 <matthew> no, martin was first
20:14:00 <adambe> stefanh: juberti, do you see any API changes as a result of this work
20:14:00 <adambe> juberti: not really
20:14:00 <matthew> i was on via SIP-to-PSTN with a caller id of 831-426-xxxx, then i dropped and reconnected with SIP direct after martin
20:14:00 <adambe> ... we're nailing down unspecified stuff
20:14:00 <matthew> if only there were some sort of identifier that an IP caller could be known by
20:15:00 <juberti> Zakim, aatt is pthatcher
20:15:00 <Zakim> +pthatcher; got it
20:15:00 <adambe> stefanh: no more questions?
20:15:00 <adambe> hta1: we're looking forward to a new draft
20:15:00 <adambe> fluffy: nothing further to add
20:15:00 <Dini> Zakim, aann is Dini
20:15:00 <Zakim> +Dini; got it
20:15:00 <adambe> ... we have been focusing on the big stuff
20:16:00 <adambe> ... roll-back, rehydration will not be finished in the upcoming release
20:16:00 <Zakim> +dom
20:16:00 <adambe> stefanh: next thing that was decided on the IETF meeting is that SDES is out
20:17:00 <adambe> ... no changes to the API
20:17:00 <adambe> juberti: on consequence, what do we need to expose regarding the certificate
20:18:00 <burn> zakim, martin is Matthew_Kaufmann
20:18:00 <Zakim> +Matthew_Kaufmann; got it
20:18:00 <adambe> ekr: I can take an action to come up with a proposal
20:18:00 <burn> zakim, nick matthew is Matthew_Kaufmann
20:18:00 <Zakim> ok, burn, I now associate matthew with Matthew_Kaufmann
20:18:00 <ekr> action, ekr to come up with a proposal for access to DTLS meta-data
20:19:00 <matthew> zack, nick matthew is Matthew_Kaufman
20:19:00 <matthew> nice. autocorrected.
20:19:00 <ekr> action: erescorla to come up with a proposal for DTLS meta-data
20:19:00 <trackbot> Error finding 'erescorla'. You can review and register nicknames at <http://www.w3.org/2011/04/webrtc/track/users>.
20:19:00 <matthew> zakim, nick matthew is Matthew_Kaufman
20:19:00 <Zakim> ok, matthew, I now associate you with Matthew_Kaufmann
20:19:00 <dom> action: eric to come up with a proposal for DTLS meta-data
20:19:00 <trackbot> Created ACTION-86 - Come up with a proposal for dtls meta-data [on Eric Rescorla - due 2013-09-10].
20:19:00 <ekr> dom: thanks
20:20:00 <adambe> hta1: stefanh, it's your turn to talk about transport related APIs
20:20:00 <burn> zakim, martin.a is Martin_Thomson
20:20:00 <stefanh> http://lists.w3.org/Archives/Public/public-webrtc/2013Sep/att-0006/Transport_related_API_needs.pdf
20:20:00 <Zakim> +Martin_Thomson; got it
20:20:00 <adambe> stefanh: yes, I'll post a link to the slides
20:20:36 <RRSAgent> RRSAgent has joined #webrtc
20:20:36 <RRSAgent> logging to http://www.w3.org/2013/09/03-webrtc-irc
20:20:40 <burn> zakim, nick martin is Martin_Thomson
20:20:40 <Zakim> ok, burn, I now associate martin with Martin_Thomson
20:22:09 <adambe> stefanh: we've set up a wiki page called "transport control" were we gather information
20:23:11 <adambe> ... example of control: pause/resume
20:23:17 <adambe> ... priority
20:23:28 <matthew> http://www.w3.org/2011/04/webrtc/wiki/Transport_Control
20:23:34 <tuexen> tuexen has joined #webrtc
20:23:44 <ekr> matthew: thanks
20:23:58 <adambe> ... (is going through the list on the wiki)
20:24:28 <martin> q+
20:24:51 <adambe> ... people want to set bitrate/bandwidth
20:24:55 <fluffy> q+
20:25:10 <adambe> ... last thing is to disable bundle
20:25:20 <adambe> juberti: I don't see anything about simulcast
20:25:36 <adambe> stefanh: that's a good input
20:26:02 <adambe> ... we are now allowing two tracks in the same stream that use the same source
20:26:22 <adambe> ... the app can configure the tracks to have different resolutions
20:26:30 <adambe> juberti: that won't work for layerd codecs
20:26:59 <adambe> ... the tracks will get different ids
20:27:06 <adambe> stefanh: that's good input
20:27:17 <adambe> ... please send this input to the list
20:27:33 <hta1> q?
20:27:51 <adambe> jesup: we need some relation between the tracks
20:31:10 <hta1> Martin: What happens if we want to control everything that's part of the SDP? How do we rule them out of scope or bring them in scope if you want them to be inside?
20:31:32 <hta1> scribenick hta1
20:32:01 <hta1> q?
20:32:12 <hta1> ack Martin_Thomson
20:32:13 <dom> scribenick: hta1
20:32:55 <martin> I'm concerned that some of the things in the SDP offer are not reflective of the capabilities of the browser.  If we want to permit some of these alterations, then it's going to be difficult to discover browser capabilities just through an SDP offer.
20:32:56 <jesup> q+
20:33:06 <juberti> q+
20:33:26 <matthew> i think there's two problems. 1) why is ptime (for instance) not on this list (how did it get to be out of scope) and 2) how for things that can be set to values other than what is in the offer can we know what are valid values? (example is if i create an offer and it has ptime 30, i have no info about whether or not ptime 5 is valid)
20:33:54 <matthew> (valid as input for setlocaldescription)
20:33:55 <adambe> adambe has joined #webrtc
20:34:40 <hta1> cullen: need to consider what we need to manipulate, and providing API surfaces to avoid SDP munging if possible.
20:34:42 <stefanh> q?
20:35:09 <juberti> agreed
20:35:17 <Cow_woC> Cow_woC has joined #webrtc
20:35:20 <hta1> ... example: ptime - opus has the minptime and maxptime parameters, which could be managed by sdp munging.
20:35:23 <martin> ptime is interesting for large BDP, because it might offer some latency benefits
20:35:30 <burn> ack fluffy
20:36:17 <hta1> hta: suggest to start with the bandwidth issue.
20:36:56 <martin> q+
20:36:57 <hta1> jesup: bandwidth bug has had no action in ages, because we have had other issues.
20:37:13 <hta1> ... initial bandwidth and target bandwidth are different issues.
20:37:38 <hta1> jesup: starting bandwidth is important for fast start.
20:38:10 <hta1> s/jesup/juberti/
20:38:46 <hta1> cullen: fast ramp-up will get pushback from the transport people at ietf.
20:39:42 <ekr> q+
20:40:22 <hta1> juberti: starting and minimum are other interesting bandwidth - quality below minimum may want to disconnect
20:40:33 <stefanh> +1 to juberti
20:40:48 <martin> justin, do you regard minimum as a "if you go below X, don't bother" sort of setting?
20:41:01 <matthew> i believe comment 22 now applies. having the application be in control of how bandwidth is allocated to its streams is a great idea.
20:41:39 <hta1> randell: application guessing is guaranteed to be an imperfect guess. there is no great solution.
20:41:46 <hta1> q+
20:41:52 <hta1> ack jesup
20:41:53 <martin> jesup, disagree about the last mile being the determining factor
20:41:56 <martin> q-
20:42:21 <Cow_woC> (Sorry for joining late, how far down the agenda are we? Did we reach "V2 API discussions: How to handle"?)
20:42:40 <tuexen> tuexen has joined #webrtc
20:42:59 <ekr> zakim, who is here?
20:42:59 <Zakim> On the phone I see Dan_Burnett, tuexen (muted), stefanh, fluffy, +91.22.39.14.aaee, Matthew_Kaufmann, +1.940.735.aagg, +358.405.60aahh, Jim_Barnett, +1.630.423.aaii,
20:43:02 <hta1> juberti: we can't prevent people from writing bad apps. they will set the values to what they believe they can use.
20:43:03 <Zakim> ... +33.2.31.26.aakk, silvia (muted), +358.942.72aamm, Dini, +44.190.881.aaoo, +46.1.07.14.aapp, Dan_Druta, hta1, jesup, ekr, pthatcher, +1.908.541.aauu, Martin_Thomson, ??P29,
20:43:03 <Zakim> ... +1.908.559.aavv, JeromeMarcon, +1.267.934.aaxx, ??P5, dom
20:43:03 <Zakim> On IRC I see tuexen, Cow_woC, adambe, RRSAgent, dom, dan, jib, makkes, JeromeMarcon, pthatcher, juberti, li_li, Markus_Isomaki, s_cazeaux, Dini, ekr, AndyH, Jim, Richard, DanD,
20:43:07 <Zakim> ... jesup, matthew, hta1, gmandyam, Mary, fluffy, mreavy, Zakim, silvia
20:43:34 <jib> zakim, I am aaxx
20:43:34 <Zakim> +jib; got it
20:43:46 <hta1> juberti: what we should not do for 1.0 is to manage the bandwidth up or down based on packet loss. This shoudl be within the runtime.
20:43:46 <ekr> q?
20:43:53 <fluffy> q?
20:44:23 <Cow_woC> silvia: Thank you.
20:44:37 <hta1> jesup: api should allow to set bandwidth allocation between flows, current bandwidth should be exposed, but not to exceed available.
20:45:01 <hta1> juberti: basically agree.
20:45:31 <tuexen> q?
20:45:47 <fluffy> q+
20:45:49 <stefanh> ack juberti
20:46:26 <hta1> ekr: we should not allow the application to generate more bandwidth than it would normally be entitled to.
20:46:47 <Cow_woC> hta1: What about being able to specify (what we believe) to be the minimum bandwidth usage? Meaning, I am starting a 1080p video chat. I don't want the video to start at 50kb/s because the users will get blurry/choppy video. Alternatively, find a way to get the vendors to scale up bandwidth usage *much* faster.
20:46:48 <martin> it would be bad if an app could start sending at 100Mbps
20:46:48 <jesup> hta1: Right, you can only reallocate bits among flows (or reduce total bits), not increase the number of bits (in my proposal)
20:47:04 <hta1> ... you shouldn't be able to set initial bandwidth so that you can generate high traffic before we know that it arrives.
20:47:37 <martin> jesup's bug is https://www.w3.org/Bugs/Public/show_bug.cgi?id=15861
20:47:44 <matthew> martin: that depends on how you define "bad". there's whole communities of folks who'd love such a capability.
20:47:51 <Cow_woC> Question: How do we get 1080p video chat to start smooth/sharp within 3 seconds as opposed to 1 minute which it is now?
20:48:27 <matthew> cow_woc: run 1080p worth of data traffic for 5 minutes before you want to make a call
20:48:41 <jesup> Cow_woC: that's an issue of the congestion algorithm: it can be more agressive at the start of a call
20:48:43 <matthew> (to the same destination you'll be calling or called from, of  course)
20:48:43 <Cow_woC> matthew: That's a non-solution as far as I'm concerned :)
20:49:25 <hta1> Cow_woC: you wishing it does not make it possible, unfortunately.
20:49:35 <jesup> You also do *rough* packet-train guestimate to help guide the starting rate.
20:49:41 <hta1> q?
20:49:42 <matthew> if we care about that shared medium, we should be TCP-friendly.
20:49:42 <Cow_woC> jesup: Fine, how do I mandate that? Right now I have no way to guarantee that my users will get a good experience nor any guarantee that the problem will ever be fixed for any given vendor. I'm looking for the specification to mandate something here to ensure a decent user experience.
20:49:47 <jesup> s/also/also can/
20:50:00 <ekr> q-
20:50:15 <matthew> and TCP-friendly isn't compatible with an international 4k video call starting instantly at full resolution
20:50:25 <hta1> juberti: might want to let the initial BW control the initial bandwidth estimate.
20:50:27 <ekr> Cow_woC: the problem is that this is not compatible with the stability of the Interet
20:50:41 <jesup> Cow_woC: We can't mandate the internet (or a congestion algorithm) will produce a specific result
20:51:12 <jesup> Please join RMCAT :-)
20:51:16 <Cow_woC> ekr, matthew: I don't want to break the internet :) but the question then is... how come I can download a 1GB file from Dropbox at crazy speeds? The download speed ramps up almost instantaneously. If HTTP uploads/downloads can do that, why can't WebRTC?
20:51:33 <ekr> It doesn't ramp up almost instantaneously.
20:51:41 <ekr> It actually takes a number of RTTs.
20:51:47 <martin> hta: we should treat application input as "what the app desires", but there needs to be a hard limit that is determined by our algorithms, and that's what RMCAT is for
20:51:51 <jesup> Cow_woC: and the current ramp-up is a low slower than it *needs* to be
20:51:56 <jesup> s/low/lot/
20:52:01 <Cow_woC> ekr: It's on the order of 3 seconds, not 5 minutes like matthew mentioned... Clearly WebRTC has a problem.
20:52:16 <hta1> q+
20:52:18 <hta1> q-
20:52:19 <hta1> q?
20:52:24 <ekr> Cow_woC: moreover, rate control on video streams has to have a lot more hysterisis than data
20:52:27 <martin> jesup, whether ramp-up is too slow or not is probably subject to conjecture
20:52:32 <juberti> q+
20:52:38 <ekr> because of the way that video works
20:52:52 <Cow_woC> jesup: Fair enough. Is there anything we can do on the specification level to ensure all implementations are more aggressive on this end?
20:52:58 <ekr> Cow
20:53:07 <ekr> _woC: yes, join the RMCAT WG
20:53:16 <jesup> Cow_woC: File bugs with Chrome and Mozilla, and join RMCAT
20:53:41 <matthew> i didn't say it would take 5 minutes.. but i did say that 5 minutes of stream would be sufficient :)
20:53:43 <hta1> cullen: sending for 10 seconds at full HD bandwidth is unacceptable on a shared network.
20:53:48 <ekr> cullen++
20:53:51 <Cow_woC> matthew: In my experience, it is at least 1 minute.
20:54:29 <jesup> I *think* the current impl doesn't ramp as fast as it can at the start; after you've established an idea of the max rate you want to ramp slowly when going past that
20:54:35 <hta1> cullen: ramp-up is one of the reasons why applications want to send early media.
20:54:46 <hta1> q?
20:54:52 <hta1> ack fluffy
20:55:38 <hta1> q+
20:56:22 <jesup> hta1: reasonable.
20:56:43 <hta1> hta: proposal - set the bandwidth as a constraint on PeerConnection. It's simple, it gets ut out the door, we can extend stuff later.
20:56:54 <jesup> And the other layer of objects makes some sense, but may be more work to specify
20:57:04 <ekr> hta1: that works for me
20:57:34 <martin> stefanh: everyone wants max, but there are mixed views on min and initial values
20:57:42 <jesup> hta1: It is
20:57:45 <hta1> stefanh: min bandwidth can also be useful, and simple.
20:57:58 <hta1> justin: 1.0 with max sounds good. mixed views on whether initial is useful.
20:58:01 <jesup> hta1: It's meant to solve the general problem with multiple streams
20:58:12 <hta1> topic switch: codecs
20:58:20 <juberti> what do you suggest that min bandwidth would do on a peerconnection?
20:58:47 <juberti> if the estimated bandwidth drops below the minimum, what happens?
20:58:55 <hta1> cullen: about codecs - people have been adding codecs, which is obviously bogus. the valid operations are removing and reordering codecs.
20:59:24 <hta1> ... the question is if we need a specific API surface for this.
21:00:03 <Cow_woC> +q
21:00:05 <hta1> ... the people who say they need this have not been able to describe (to cullen) compelling use cases for this.
21:00:08 <hta1> q-
21:00:17 <juberti> q-
21:00:20 <fluffy> q?
21:00:40 <ekr> Cow_woC: start speaking
21:00:41 <Cow_woC> Sorry guys, I'm new to this system.
21:00:56 <dom> Cow_woC, are you on the call?
21:00:57 <Cow_woC> If bandwidth drops below minimum, I propose triggering a callback
21:01:02 <Cow_woC> Sorry, only on IRC
21:01:17 <hta1> OK, then you cannot participate in the verbal discussion.
21:01:27 <martin> ack Cow_woC
21:01:38 <juberti> q+
21:01:44 <martin> q+
21:01:47 <hta1> q+
21:01:49 <Cow_woC> I made a proposal a few weeks ago, asking for "fence conditions". You register min/max bandwidth and a callback gets invoked if this condition is violated. The callback then modifies the fence conditions and the process continues.
21:02:09 <Zakim> +[Mozilla]
21:02:15 <adam> adam has joined #webrtc
21:02:30 <hta1> justin: case heard is that people can't do SWB so only want to offer WB or narrowband.
21:02:31 <ekr> zakim, [Mozilla] is adam
21:02:31 <Zakim> +adam; got it
21:02:59 <Cow_woC> q-
21:03:01 <hta1> ... use case is where there are browsers on both sides, running the same app, and app dev wants to control the codec
21:03:27 <hta1> cullen: we may want to configure the session for real low latency.
21:03:49 <hta1> justin: controlling music mode vs speech mode is a poster child.
21:04:24 <adambe> Cow_woC: are you able to join the call (find phone info in this mail http://lists.w3.org/Archives/Public/public-webrtc/2013Sep/0005.html)
21:04:59 <hta1> martin: stats API could be an useful place to expose what the congestion control algorithm currently thinks is available.
21:05:09 <fluffy> +1 Martin
21:05:36 <Cow_woC> adambe: Trying now.
21:05:41 <Cow_woC> adambe: (thank you!)
21:05:46 <hta1> hta: sdp munging can't control Opus music / speech mode. We need API surface to control it.
21:05:52 <jesup> hta1: we were planning on something like that
21:06:07 <martin> it sort of can: music mode can be achieved with a=max-ptime=5
21:06:17 <hta1> justin: punting these features to 2.0 may be the simplest thing to do here.
21:06:23 <martin> But it's hard to know if doing that it possible...
21:07:30 <hta1> zakim, who is making noise?
21:07:36 <martin> zakim, who is noisy?
21:07:41 <Zakim> hta1, listening for 10 seconds I heard sound from the following: pthatcher (35%)
21:07:55 <Zakim> martin, listening for 10 seconds I heard sound from the following: stefanh (58%), Jim_Barnett (4%)
21:08:37 <Zakim> +[IPcaller]
21:08:47 <hta1> justin: suggest punting all the codec control things to post-1.0
21:09:05 <hta1> cullen: strong desire for controlling silence suppression.
21:09:20 <hta1> justin, randell: we already have that.
21:09:39 <hta1> cullen: reorder or remove codecs - don't do it in the 1.0 timeframe.
21:10:44 <hta1> justin: agc is a topic that we need to consider. it's not really a transport control thingy.
21:11:38 <hta1> justin: bundle, bandwidth should be global constraints on the peer connection.
21:11:40 <jesup> justin: agc, AEC, noise suppression are all more getUserMedia issues than peerconnectionissues, IMHO
21:12:34 <hta1> cullen: see a need for priority. should be a property on the mediastreamtrack.
21:13:00 <hta1> justin: mst is the wrong place, since it doesn't really connect to the transport. We don't have a good place to set this property.
21:13:15 <silvia> if we can get bandwidth limitations into global constraints, that would be a good step forward
21:13:48 <matthew> comment 22 definitely applies now. there should be an object that reflects the transport separately from the object that represents the media, then we could talk about prioritization APIs on that transport object.
21:14:13 <hta1> cullen: priority should reflect into DSCP levels.
21:14:29 <hta1> justin: relative priority may be good enough for version 1.
21:14:39 <martin> matthew, yes.  This applies to bandwidth, priority, and all sorts of stuff.
21:14:57 <Cow_woC> matthew: Agreed.
21:15:55 <matthew> the problem with the "v2 API discussion" is that there shouldn't be this v1 API
21:16:06 <matthew> so clearly the numbering is wrong
21:16:08 <Cow_woC> matthew: :)
21:16:21 <Zakim> -silvia
21:18:11 <hta1> stefanh: people want priorities on tracks.
21:18:20 <ekr> q+
21:18:30 <juberti> -q
21:18:30 <martin> q
21:18:31 <fluffy> q?
21:18:33 <martin> q-
21:18:38 <hta1> q-
21:18:43 <DanD> q+
21:19:16 <jesup> ekr++
21:19:29 <hta1> ack ekr
21:19:57 <adam> zakim, who is noisy?
21:20:02 <hta1> ekr: priorities don't sound too hard. and they're useful.
21:20:10 <Zakim> adam, listening for 10 seconds I could not identify any sounds
21:20:24 <hta1> dand: priorities sounds like apps developers need it in the first release.
21:20:32 <juberti> q
21:20:34 <juberti> q+
21:20:41 <juberti> -q
21:20:43 <DanD> q-
21:21:12 <ekr> no objection
21:21:23 <stefanh> no objection!
21:21:37 <burn> publish!
21:21:47 <hta1> hta: suggest making the current editor's draft the WD.
21:21:59 <hta1> No objections noted.
21:23:29 <ekr> q+
21:23:33 <hta1> stefanh presents v2 discussion - chairs reserve right to move discussion to wiki  or separate list.
21:24:27 <matthew> the people working on the "v1" should have better self-control and keep working on it, instead of reading the other messages
21:24:27 <hta1> cullen: no benefit in starting the v2 discussion on this mailing list.
21:25:05 <hta1> stefanh: don't want to push people away
21:25:16 <Cow_woC> q+
21:25:20 <christer> christer has left #webrtc
21:25:20 <hta1> cullen: we have formed a new group in the W3C, we should be pushing them in that direction.
21:25:55 <matthew> the discussions might have gone even better if the people working on the current abomination would refrain from responding to those messages, too
21:26:10 <burn> the people working on "v2" should have better self-control and stop working on it, instead of generating lots of messages :)
21:26:10 <hta1> ekr: use case discussions about what we are sad about in the current api are good to have.
21:26:49 <hta1> ... we can have endless debates on which dot version things should be in.
21:27:00 <fluffy> q?
21:27:08 <hta1> ... triage between v1 and v2 features seems completely appropriate for this group.
21:27:10 <dom> ack ekr
21:27:13 <dom> ack Cow_woC
21:27:19 <matthew> i don't care which list we have the conversations on, because we'll just follow the one that works for us
21:27:48 <hta1> cow_woc: be careful not to make architectural decisions in 1.0 that prevent certain features in version 2.
21:28:10 <matthew> feels like we've already made those decisions
21:28:13 <Cow_woC> q-
21:28:16 <fluffy> q+
21:28:19 <matthew> for some value of "we"
21:28:19 <hta1> ... if v1 makes too many promises you can't remove those promises in v2.
21:28:23 <hta1> q+
21:28:56 <Cow_woC> q+
21:29:20 <hta1> cullen: all proposals claim that v1 can be built on top of v2. I don't want to be back to discussing low level APIs.
21:29:31 <fluffy> q-
21:30:01 <burn> cow_woc, I agree that v1 must not prevent a v2, and to that extent it's important to have joint discussions.  Officially, there is likely to be no official v2 work in this group until v1 is closer to done, regardless of where proposals leading to v2 are developed.
21:30:27 <martin> hta, that's a very strange statement to make: old applications should be able to use new features ???
21:30:37 <hta1> hta: worried about losing some properties, such as future-proofing of applications.
21:30:44 <ekr> martin: why is that strange?
21:30:57 <martin> because those features weren't requested, perhaps?
21:31:00 <Zakim> -pthatcher
21:31:04 <ekr> For instance, I would like browsers to automatically use VP9 if it was added
21:31:08 <burn> btw Cow_woC, who are you?  I can't hear well on the call.
21:31:08 <ekr> Or HEVC
21:31:26 <Cow_woC> q-
21:31:36 <matthew> "v1" won't be done until there is a complete specification of what comes out and goes in at all the SDP API interfaces. the likelyhood of that being complete in the next 2-3 years is nil. so why not start on the next one now?
21:31:39 <Cow_woC> burn: Sorry, calling on Skype.
21:31:44 <hta1> Cow_woC: <not able to capture that argument>
21:31:45 <hta1> q-
21:31:48 <martin> if I write an application, I would have expected that the application continue to work as written, without surprising changes.  New codecs are something that I might have left in the hands of the browser, in which case, no problem.
21:31:59 <Zakim> - +358.405.60aahh
21:32:20 <martin> I was thinking about new features of a different nature than just codecs.
21:32:27 <Zakim> -??P29
21:32:27 <ekr> martin: well, I would expect that for instance, BUNDLE would work if introduced later
21:32:31 <matthew> 2 minutes over. leaving.
21:32:34 <burn> Cow_woC, who are you?  We need it for the minutes as well. (sorry if I missed it)
21:32:40 <martin> bye
21:32:40 <ekr> burn: cow_woc is Gili
21:32:43 <Cow_woC> hta1: I was trying to say that a proposal was made a few months ago that SDP should be an "opaque token" instead of the specification promising the use of SDP or explaining what's inside it. This prevents v2 from changing the meaning of SDP or removing it altogether.
21:32:49 <hta1> stefanh: what I hear now is that we should limit discussion related to v2 and focus on finalizing version 1.
21:32:57 <Cow_woC> ekr: Yes, that's right.
21:33:08 <martin> ekr, I would hope that the browser wouldn't add bundle if I had been successfully using it without.
21:33:16 <Zakim> -Martin_Thomson
21:33:22 <ekr> martin: Hmm… That's not what I would have expected
21:33:22 <Zakim> -Matthew_Kaufmann
21:33:24 <Zakim> -[IPcaller]
21:33:25 <Zakim> -dom
21:33:25 <Zakim> - +1.940.735.aagg
21:33:27 <Zakim> - +46.1.07.14.aapp
21:33:28 <Zakim> -fluffy
21:33:28 <Zakim> -jib
21:33:28 <Zakim> - +1.908.541.aauu
21:33:29 <dom> Zakim, list attendees
21:33:30 <Zakim> -JeromeMarcon
21:33:30 <Zakim> As of this point the attendees have been +1.407.421.aaaa, Dan_Burnett, +49.441.6.aabb, +46.1.07.14.aacc, tuexen, +1.403.244.aadd, stefanh, +91.22.39.14.aaee, +1.858.651.aaff,
21:33:30 <Zakim> ... fluffy, +1.940.735.aagg, +358.405.60aahh, Jim_Barnett, +1.630.423.aaii, +1.831.426.aajj, +33.2.31.26.aakk, +61.2.809.0.aall, silvia, +358.942.72aamm, +1.561.923.aann,
21:33:30 <ekr> Would you be sad if it added AES-GCM?
21:33:31 <Zakim> ... +44.190.881.aaoo, Dan_Druta, +46.1.07.14.aapp, +1.650.275.aaqq, +1.831.426.aarr, hta1, matthew, +1.610.889.aass, +1.425.893.aatt, jesup, ekr, +1.908.541.aauu, +1.908.559.aavv,
21:33:31 <Zakim> ... +33.6.85.56.aaww, +1.267.934.aaxx, JeromeMarcon, pthatcher, Dini, dom, Matthew_Kaufmann, Martin_Thomson, jib, adam, [IPcaller]
21:33:31 <Zakim> -Jim_Barnett
21:33:31 <Zakim> -stefanh
21:33:33 <dom> RRSAgent, draft minutes
21:33:33 <RRSAgent> I have made the request to generate http://www.w3.org/2013/09/03-webrtc-minutes.html dom
21:33:35 <Zakim> -Dini
21:33:35 <Zakim> -adam
21:33:35 <Zakim> -Dan_Druta
21:33:35 <Zakim> - +358.942.72aamm
21:33:36 <Zakim> - +1.630.423.aaii
21:33:37 <Zakim> -tuexen
21:33:38 <Zakim> -jesup
21:33:38 <Zakim> -Dan_Burnett
21:33:40 <Zakim> - +44.190.881.aaoo
21:33:40 <Zakim> -ekr
21:33:41 <AndyH> AndyH has left #webrtc
21:33:51 <Zakim> - +91.22.39.14.aaee
21:34:05 <Zakim> - +33.2.31.26.aakk
21:34:07 <Zakim> -??P5
21:34:09 <Zakim> -hta1
21:35:53 <mreavy> mreavy has left #webrtc
21:38:56 <juberti> juberti has joined #webrtc
21:39:09 <Zakim> disconnecting the lone participant, +1.908.559.aavv, in UW_WebRTC()4:00PM
21:39:11 <Zakim> UW_WebRTC()4:00PM has ended
21:39:11 <Zakim> Attendees were +1.407.421.aaaa, Dan_Burnett, +49.441.6.aabb, +46.1.07.14.aacc, tuexen, +1.403.244.aadd, stefanh, +91.22.39.14.aaee, +1.858.651.aaff, fluffy, +1.940.735.aagg,
21:39:11 <Zakim> ... +358.405.60aahh, Jim_Barnett, +1.630.423.aaii, +1.831.426.aajj, +33.2.31.26.aakk, +61.2.809.0.aall, silvia, +358.942.72aamm, +1.561.923.aann, +44.190.881.aaoo, Dan_Druta,
21:39:13 <Zakim> ... +46.1.07.14.aapp, +1.650.275.aaqq, +1.831.426.aarr, hta1, matthew, +1.610.889.aass, +1.425.893.aatt, jesup, ekr, +1.908.541.aauu, +1.908.559.aavv, +33.6.85.56.aaww,
21:39:13 <Zakim> ... +1.267.934.aaxx, JeromeMarcon, pthatcher, Dini, dom, Matthew_Kaufmann, Martin_Thomson, jib, adam, [IPcaller]
21:40:13 <jesup> jesup has left #webrtc
21:41:39 <jib> jib has joined #webrtc
22:00:14 <ekr> ekr has joined #webrtc
22:04:47 <ekr> ekr has joined #webrtc
22:18:07 <UW_WebRTC> UW_WebRTC has joined #webrtc
22:18:51 <UW_WebRTC> UW_WebRTC has left #webrtc
22:25:36 <ekr> ekr has joined #webrtc
22:26:47 <hta1> hta1 has left #webrtc
23:04:19 <jib> jib has joined #webrtc
23:38:21 <Zakim> Zakim has left #webrtc
23:52:21 <lgombos> lgombos has joined #webrtc
23:53:25 <lgombos> lgombos has joined #webrtc