15:55:59 <RRSAgent> RRSAgent has joined #webrtc
15:55:59 <RRSAgent> logging to http://www.w3.org/2011/10/05-webrtc-irc
15:56:00 <hta> zakim, aaaa is me
15:56:02 <Zakim> +hta; got it
15:56:04 <rillian> 604.728 is me, Ralph Giles for Mozilla
15:56:21 <Zakim> + +44.122.375.aacc
15:56:27 <burn> zakim, aabb is Ralph_Giles
15:56:29 <Zakim> +Ralph_Giles; got it
15:56:29 <francois> Meeting: Web Real Time Communications Working Group
15:56:52 <burn> zakim, aacc is Neil_Stratford
15:56:53 <Zakim> +Neil_Stratford; got it
15:56:58 <Zakim> + +46.1.07.14.aadd
15:57:04 <francois> Agenda: http://lists.w3.org/Archives/Public/public-webrtc/2011Sep/0099.html
15:57:05 <stefanh> Zakim, aadd is stefanh
15:57:05 <Zakim> +stefanh; got it
15:57:13 <burn> zakim, I am Dan_Burnett
15:57:13 <Zakim> ok, burn, I now associate you with Dan_Burnett
15:57:30 <rillian> Zakim, I am Ralph_Giles
15:57:30 <Zakim> ok, rillian, I now associate you with Ralph_Giles
15:57:52 <hta> zakim, i am Harald Alvestrand
15:57:55 <francois> zakim, code?
15:57:55 <Zakim> I don't understand 'i am Harald Alvestrand', hta
15:57:58 <Zakim> the conference code is 932782 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), francois
15:58:08 <hta> zakim, i am Harald_Alvestrand
15:58:08 <Zakim> sorry, hta, I do not see a party named 'Harald_Alvestrand'
15:58:09 <Zakim> +francois
15:58:14 <stefanh> Zakim, I am Stefan Håkansson
15:58:17 <francois> zakim, mute me
15:58:19 <Zakim> I don't understand 'I am Stefan Håkansson', stefanh
15:58:25 <Zakim> francois should now be muted
15:58:30 <hta> hehe. robots ain't easy :-)
15:58:39 <Zakim> + +1.408.562.aaee
15:58:45 <francois> ack me
15:58:49 <Zakim> + +1.403.244.aaff
15:59:10 <fluffy> fluffy has joined #webrtc
15:59:32 <fluffy> Hi All
15:59:41 <stefanh> Hi Cullen
15:59:50 <francois> zakim, hta is Harald_Alvestrand
15:59:52 <Zakim> +Harald_Alvestrand; got it
16:00:05 <stefanh> Zakim, stefanh is Stefan Håkansson
16:00:05 <Zakim> I don't understand 'stefanh is Stefan Håkansson', stefanh
16:00:08 <francois> zakim, stefanh is Stefan_Håkansson
16:00:08 <Zakim> +Stefan_Håkansson; got it
16:00:15 <francois> zakim, who is on the phone?
16:00:19 <Zakim> +??P66
16:00:21 <Zakim> On the phone I see Harald_Alvestrand, Ralph_Giles, Dan_Burnett, Neil_Stratford, Stefan_Håkansson, francois, +1.408.562.aaee, +1.403.244.aaff, ??P66
16:00:52 <burn> zakim, ??P66 is Tim_Panton
16:00:57 <fluffy> +1.403.244.aaff is fluffy is Cullen Jennings
16:00:57 <Zakim> + +1.425.580.aagg
16:01:06 <Zakim> + +972.3.645.aahh
16:01:09 <Zakim> +Tim_Panton; got it
16:01:12 <burn> zakim, aaff is Cullen_Jennings
16:01:20 <Zakim> +Cullen_Jennings; got it
16:01:20 <burn> zakim, aagg is Dan_Druta
16:01:22 <ceyrigno> ceyrigno has joined #webrtc
16:01:24 <Zakim> + +34.38.83.aaii
16:01:29 <Zakim> + +46.1.07.14.aajj
16:01:30 <DanD> DanD has joined #webrtc
16:01:31 <Zakim> +Dan_Druta; got it
16:01:54 <DanRomascanu> DanRomascanu has joined #webrtc
16:02:05 <Zakim> + +44.208.144.aakk
16:02:08 <francois> zakim, who is making noise?
16:02:12 <Zakim> +??P84
16:02:15 <richt> zakim, aakk is me
16:02:17 <DanRomascanu> this is brutal
16:02:25 <burn> zakim, aahh is DanRomascanu
16:02:25 <rillian> thank you
16:02:35 <Zakim> +richt; got it
16:02:41 <Zakim> francois, listening for 10 seconds I heard sound from the following: francois (16%)
16:02:52 <Zakim> +DanRomascanu; got it
16:02:58 <Zakim> + +1.314.529.aall
16:03:03 <Zakim> +[Mozilla]
16:03:13 <richt> Present+ Rich_Tibbett
16:03:18 <juberti> juberti has joined #webrtc
16:03:44 <Zakim> + +1.425.894.aamm
16:04:28 <francois> zakim, who is on the phone?
16:04:31 <Zakim> -Tim_Panton
16:04:42 <Zakim> - +34.38.83.aaii
16:04:46 <Zakim> On the phone I see Harald_Alvestrand, Ralph_Giles, Dan_Burnett, Neil_Stratford, Stefan_Håkansson, francois, +1.408.562.aaee, Cullen_Jennings, Dan_Druta, DanRomascanu,
16:04:51 <Zakim> ... +46.1.07.14.aajj, richt, ??P84, +1.314.529.aall, [Mozilla], +1.425.894.aamm
16:05:24 <francois> zakim, aaee is Mani_Mahalingam
16:05:24 <Zakim> +Mani_Mahalingam; got it
16:05:33 <juberti> zakim, aamm is juberti
16:05:33 <Zakim> +juberti; got it
16:05:50 <francois> zakim, aajj is Adam_Bergkvist
16:05:50 <Zakim> +Adam_Bergkvist; got it
16:06:25 <francois> zakim, ??P84 is perhaps Christophe_Eyrignoux
16:06:25 <Zakim> +Christophe_Eyrignoux?; got it
16:06:27 <rillianbis> rillianbis has joined #webrtc
16:07:26 <francois> zakim, aamm is Justin
16:07:26 <Zakim> sorry, francois, I do not recognize a party named 'aamm'
16:07:49 <francois> zakim, who is on the phone?
16:07:49 <Zakim> On the phone I see Harald_Alvestrand, Ralph_Giles, Dan_Burnett, Neil_Stratford, Stefan_Håkansson, francois, Mani_Mahalingam, Cullen_Jennings, Dan_Druta, DanRomascanu,
16:07:52 <Zakim> ... Adam_Bergkvist, richt, Christophe_Eyrignoux?, +1.314.529.aall, [Mozilla], juberti
16:07:55 <juberti> zakim, juberti is Justin_Uberti
16:07:55 <Zakim> +Justin_Uberti; got it
16:08:27 <francois> zakim, francois is Francois_Daoust
16:08:27 <Zakim> +Francois_Daoust; got it
16:08:35 <adambe> adambe has joined #webrtc
16:08:53 <francois> zakim, [Mozilla] is Tim_Terriberry
16:08:53 <Zakim> +Tim_Terriberry; got it
16:09:13 <rillianbis> hi derf!
16:09:38 <derf> Hi rillianbis.
16:10:19 <francois> Chair: Harald
16:10:38 <francois> Agenda: http://lists.w3.org/Archives/Public/public-webrtc/2011Sep/0099.html
16:11:31 <francois> Scribe: Francois_Daoust
16:11:34 <francois> Scribenick: francois
16:11:48 <francois> zakim, mute me
16:11:48 <Zakim> Francois_Daoust should now be muted
16:12:02 <rillianbis> Harald: Agenda sent out on the 27th
16:12:06 <rillianbis> reviewing items
16:12:20 <francois> i/harald/scribenick:rillianbis/
16:12:28 <francois> RRSAgent, draft minutes
16:12:28 <RRSAgent> I have made the request to generate http://www.w3.org/2011/10/05-webrtc-minutes.html francois
16:12:32 <rillianbis> since then, we've added low-level javascript api proposal
16:12:48 <Mani> Mani has joined #webrtc
16:12:56 <francois> RRSAgent, make logs public
16:13:01 <rillianbis> cullen: overview of the changes to the draft
16:13:12 <rillianbis> primary set of changes was around separating the ICE state machine a bit
16:13:27 <rillianbis> Want feedback on the overall model
16:13:47 <rillianbis> ICE state machine checks candidates, and can start using some while still waiting for other candidates
16:14:00 <rillianbis> at the same tim eyou have have the negotiation with the other endpoint going on
16:14:07 <rillianbis> codecs, ICE parameters, etc
16:14:18 <rillianbis> separated those two aparet
16:14:32 <rillianbis> and tried to update the text and semantics around when things change state
16:14:43 <rillianbis> second change:
16:14:52 <rillianbis> want to redo how we do the data channela nd teh data api
16:14:59 <rillianbis> commented out what was in the previous draft
16:15:03 <rillianbis> since it didn't have agreement
16:15:12 <rillianbis> will replace it based on discussion today and on the list going forward
16:15:17 <rillianbis> those are the major changes
16:15:38 <rillianbis> Adam: had a discussion on the mailing list about confusing text
16:15:48 <francois> s/Scribenick: francois/Scribenick: rillianbis/
16:16:10 <rillianbis> about how you can create a stream from another stream, and if you disable tracks in the parent they affect the derived streams
16:16:30 <rillianbis> the usecase was to clone streams e.g. to send a copy of a stream somehwere else
16:16:45 <rillianbis> but you might want different attributes, e.g. to mute the copy you're uploading
16:17:03 <francois> s/Scribe: Francois_Daoust/Scribe: Ralph_Giles/
16:17:11 <rillianbis> so when you fork a stream, it's better if you create a new stream which is a peer of the original, without any parent/child relationship
16:17:18 <rillianbis> this is easier to understand
16:17:33 <rillianbis> that was teh first step
16:17:47 <fluffy> I'm getting IM from people that bridge is busy and they can't join. 
16:17:50 <rillianbis> the second was to be able to create a new stream that contained components gathered from multiple other streams
16:17:52 <francois> i/cullen: overview/Topic: Changes made to the editors draft/
16:17:58 <francois> RRSAgent, draft minutes
16:17:58 <RRSAgent> I have made the request to generate http://www.w3.org/2011/10/05-webrtc-minutes.html francois
16:18:11 <rillianbis> e.g. to combine all the audio tracks from multiple incoming streams and record a single file with all the conversation audio
16:18:29 <rillianbis> has implications wrt sync, but we'll take that as a separate discussion
16:19:42 <rillianbis> harald: next item
16:19:43 <francois> zakim, mute me
16:19:43 <Zakim> Francois_Daoust was already muted, francois
16:20:02 <rillianbis> Assuming people are ok with non-inherentance
16:20:12 <rillianbis> shall we talk about the data channel api for a moment
16:20:23 <rillianbis> the main thing going on is the deletion of that part of the spec
16:20:38 <rillianbis> but the part that has been happening is that eric (sp?)
16:20:43 <anant> anant has joined #webrtc
16:20:51 <rillianbis> has suggested how you could define a protocol for this
16:20:53 <Zakim> + +1.408.421.aann
16:20:54 <Zakim> - +1.408.421.aann
16:20:55 <Zakim> +??P69
16:21:02 <rillianbis> and multiplex multiple streams over the channel
16:21:17 <rillianbis> most of this is happening at the IETF, but what implication does this have for the API
16:21:43 <rillianbis> someone else: there is a need to have multiple channels
16:21:52 <rillianbis> so it's nice not to do that at the application lelvel
16:21:54 <burn> zakim, ??P69 is Tim_Panton
16:21:54 <Zakim> +Tim_Panton; got it
16:22:04 <rillianbis> and also signal reliable vs unreliable
16:22:06 <francois> i/Adam: had a discussion/Topic: Discussion on specific items/
16:22:08 <stefanh> s/someone else/justin/
16:22:26 <francois> s/lelvel/level/
16:22:31 <rillianbis> cullen: can we just have a data channel, which you add like an audio or video stream
16:22:43 <Zakim> + +1.610.889.aaoo
16:22:55 <rillianbis> regardless of whether it's reliable or not, I care about realtime/low-latency data transmission
16:23:04 <rillianbis> that's the important distinction
16:23:20 <rillianbis> of course if the library does that form me, that's great
16:23:26 <rillianbis> but can always build something
16:23:37 <rillianbis> justin: agree
16:23:44 <rillianbis> randell jesup also agrees
16:24:23 <rillianbis> someone else: requirements address low latency, reliability
16:24:40 <rillianbis> harald: requirements are strict on congestion control
16:24:46 <rillianbis> that means we have to throw data away
16:24:58 <rillianbis> so a tradeoff we have to be aware of is that reliable will be slow
16:25:20 <rillianbis> tim terriberry: we can't assume the endpoint supports data
16:25:41 <rillianbis> so adding a data stream needs to be able to fail, we should reuse the a/v stream api for that
16:26:10 <rillianbis> someone else: you don't even know if the other side supports data right now
16:26:22 <rillianbis> harald: in the absence of a draft
16:26:45 <rillianbis> the group is drifting to having a data channel you can add just like a media stream
16:26:59 <rillianbis> justin: yes, the other side has a data stream show up just like a/v
16:27:01 <fluffy> +1 what Justin said
16:27:11 <rillianbis> and you can have mulitiple such data streams with different properties
16:27:42 <francois> s/mulitiple/multiple/
16:27:54 <rillianbis> question: thoughts on peer streams vs peer tracks
16:28:08 <rillianbis> cullen(?): just make them exactly like a mediastream as much as possible
16:28:22 <rillianbis> one issue is that tracks are SSRC identified, and demuxed that way
16:28:29 <rillianbis> while the data stream my have internal muxing
16:29:02 <rillianbis> the lowest unit of a/v transmission is the track, which is an assymmetry
16:29:23 <rillianbis> question: how do you create data streams?
16:29:38 <rillianbis> it's strange if the peerconnection is the factory?
16:29:53 <rillianbis> harald: could have an .addData() method
16:30:03 <tpanton> tpanton has joined #webrtc
16:30:05 <rillianbis> right now we don't have a method of having tracks in a media stream
16:30:21 <rillianbis> so we don't have a symmetric operation of creating data tracks
16:30:38 <rillianbis> right now getUserMedia just make a stream appear
16:30:47 <rillianbis> and we can add streams to that
16:31:02 <rillianbis> it would be something similar to it
16:31:08 <rillianbis> getUserMedia must be async
16:31:14 <rillianbis> but getDataStream could be sync
16:31:39 <rillianbis> Harald: people have argued, we should just have what's effectively capture keyboard and have that be a stream
16:31:48 <rillianbis> Next agenda point:
16:32:02 <francois> Topic: Glare resolution
16:32:22 <rillianbis> Basic issue is that if we're using browsers with SDP to negotiate
16:32:27 <rillianbis> ignore SIP, etc. for now
16:32:33 <rillianbis> if we're using offer/answer
16:32:45 <rillianbis> and if you and the other side both send offers at the same time (glare)
16:32:50 <rillianbis> SDP doesn't have a way to resolve that
16:32:54 <rillianbis> both sides need to retry
16:33:06 <rillianbis> the way I characterized glare in sip on the IETF thread
16:33:10 <rillianbis> was sort of wrong
16:33:21 <rillianbis> but the issue is if we're using SDP we need to handle glare
16:33:41 <rillianbis> if we want to be able to gateway to sip we need to handle it in a way that's compatible with sip's handling
16:33:50 <rillianbis> and the way sip does it isn't necessarily optimal
16:34:01 <rillianbis> one question here is, will the sip approach change?
16:34:23 <rillianbis> will we invent a backwards-compatibile glare resolution which can be used for any SDP protocol
16:34:44 <rillianbis> the other question is if we want to be able to gateway to SIP wrt to glare handling
16:34:51 <rillianbis> either way we have to deal with glare somewhere
16:35:03 <rillianbis> So, that sets the stage for discussion
16:35:09 <rillianbis> (that was cullen)
16:35:22 <rillianbis> Tim Terriberry: what API implications are there?
16:35:37 <rillianbis> your glare resolution had a magic number, do we need to expose that?
16:35:40 <anant> anant has joined #webrtc
16:35:48 <rillianbis> cullen: I don't think that has api implications
16:36:07 <rillianbis> the only implication is that things might take longer than you think
16:36:13 <rillianbis> adding a stream will always be async
16:36:19 <rillianbis> because there's some back and forth there
16:36:33 <rillianbis> someone else: if you throw these SDP messages away
16:36:44 <rillianbis> if you find a glare, it would be better to reuse the message
16:36:46 <rillianbis> just a thought
16:36:59 <rillianbis> cullen: I think that would be an attempt to resolve this in in a better way
16:37:13 <rillianbis> one side backs down, and that would be a faster way to do that
16:37:19 <rillianbis> but I don't think it affects the api
16:37:47 <rillianbis> I expect to see some drafts or other evolution of the email threads about how we can do glare resolution better, how we can map it
16:37:58 <rillianbis> it's not as bad as I originally made it sound
16:38:08 <rillianbis> harald: no specific comments?
16:38:15 <rillianbis> one question for cullen:
16:38:27 <rillianbis> if we go with this number thing to do faster resolution, woiuld that still work with sip?
16:38:52 <rillianbis> cullen: yes. this problem exists in sip as well, so anyone using SDP offer/answer would move to this
16:39:06 <rillianbis> it would have to be an mmusic draft in the IETF
16:39:22 <rillianbis> if you didn't have the number, you'd fall back to something which was compatible with the way older sip devices did it
16:39:31 <rillianbis> but if you had the number it would resolve the glare faster
16:39:49 <rillianbis> maybe even if only one side uses the new resolution it might go faster
16:40:21 <rillianbis> This matters because there's a common metaphor of people starting with voice, and adding video. That escalation is a really common case when you have glare
16:40:28 <rillianbis> I wonder if this is premature optimization
16:40:53 <rillianbis> jesup: I wonder if we lock ourselves in to glare when we're switching modes, or if there's been an interface changes
16:40:58 <rillianbis> which affects bandwidth
16:41:11 <rillianbis> cullen: good questions
16:41:28 <rillianbis> interfaces changes tend to be one sided, so they don't result in glare
16:41:39 <rillianbis> changes to network are more of a problem
16:41:51 <rillianbis> e.g. congestion causes them to drop video
16:42:09 <rillianbis> we need to design algorithms so both sides don't try to do that at the same time
16:42:36 <rillianbis> cisco telepresense is designed so the two ends aren't likely to switch within a few 100 ms
16:42:48 <rillianbis> that's by design, but so far it hasn't been a issue
16:43:01 <rillianbis> Harald: Cullen will work more on the glare problem
16:43:08 <rillianbis> we have implementation feedback
16:43:14 <rillianbis> js argument to getUserMedia
16:43:25 <rillianbis> tim's note on json hints for mediastreams
16:43:34 <rillianbis> seems to me these are all reasonable things to do
16:43:41 <rillianbis> modulo suggested modifications
16:43:48 <rillianbis> want to keep getusermedia async
16:43:50 <rillianbis> any other comments?
16:44:17 <rillianbis> jesup: As far as the async nature of getUserMedia, it's still async in anant's proposal
16:44:23 <rillianbis> but it's async in a different way
16:44:28 <rillianbis> you get a stream right away
16:44:35 <rillianbis> but it's inactive until you get an event
16:44:40 <francois> i/we have implementation/Topic: Changes to getUserMedia/
16:44:55 <rillianbis> tommy and anant were talking about and forth about what the most appropriate design is
16:45:09 <rillianbis> Harald: Tommy and Anant will work out a proposal
16:45:16 <rillianbis> Adam: I also got into that discussion
16:45:24 <rillianbis> So I think that will continue on the mailing list
16:45:27 <rillianbis> it's a good discussion
16:45:37 <rillianbis> Harald: the proposal will actually change the interface
16:45:52 <rillianbis> to the mediastreamevent and will require that you have a listener on that
16:46:06 <rillianbis> before it was possible to use MediaStreams without using an event listener
16:46:21 <rillianbis> Adam: Right, you'll have a stream in a state where you can't use it
16:46:34 <rillianbis> if we make the track list immutable it will help us in the future
16:46:49 <rillianbis> I will make it a lot easier
16:46:57 <rillianbis> Harald: you might not get away with that
16:47:15 <rillianbis> in the case of remote streams, you'll have tracks popping up which weren't there before
16:47:31 <rillianbis> Adam: right now you have all the tracks, but they're empty
16:47:42 <rillianbis> Harald: how is that communicated?
16:47:50 <rillianbis> Adam: with addStream signalling
16:48:09 <rillianbis> harald: but what you're connecting to doesn't use addStream, they just appear
16:48:29 <rillianbis> Need some kind of gateway to make them look like a peerconnection
16:48:48 <rillianbis> Harald: The change to getUserMedia is non-controversial
16:48:58 <rillianbis> but the change to MediaStream is controversial
16:49:05 <rillianbis> Tim: I think the issue harald is describing
16:49:22 <rillianbis> is that if we want to make the mediastream a representation of an RTP CNAME
16:49:41 <rillianbis> we have to account for the possibility that a new track is added
16:49:55 <rillianbis> Cullen: I don't think we have a very good definition of a track
16:50:42 <rillianbis> Can't have everything in a peerconnection be synchronized
16:50:54 <rillianbis> jesup: can't have that; they might come from different sources
16:51:14 <rillianbis> the feeds could be coming from five different devices
16:51:29 <rillianbis> Cullen: if you have a gateway
16:51:41 <rillianbis> it may want to tell you that the five streams aren't synchronize
16:51:43 <rillianbis> d
16:52:03 <rillianbis> jesup: those streams are inherently unsynchronized
16:52:22 <rillianbis> cullen: trying to syncronize them introduces latency
16:52:31 <rillianbis> and delays them all if one loses a packet
16:52:54 <rillianbis> someone else: application asks for video and audio at the same time with getUserMedia, so it can add video later if it wants to 
16:53:03 <francois> s/syncronize/synchronize/
16:53:37 <rillianbis> jesup: User may have accepted audio only, so escalating to video requires asking the user again
16:53:53 <rillianbis> so you can't assume you don't have to call getuserMedia again.
16:54:12 <rillianbis> Harald: we're running out of time, can someone take an action item to write down
16:54:23 <rillianbis> what the media stream is and write to the list
16:54:28 <rillianbis> Tim Terriberry: I can do that
16:54:37 <rillianbis> Harald: Ok, you got it Tiem
16:54:49 <rillianbis> topic: Plans for moving to FPWD by Oct 18
16:54:51 <francois> Topic: Plans to move to FPWD
16:54:52 <francois> ack me
16:55:10 <rillianbis> francois: It's a good signal to the rest of the community
16:55:19 <rillianbis> to other groups that we're making progress
16:55:27 <rillianbis> it doesn't have to be complete
16:55:42 <rillianbis> it's a good idea to flag sections which we're still discussion
16:55:47 <rillianbis> apart from that 
16:55:52 <rillianbis> that only thing missing is an abstract
16:56:17 <rillianbis> action item: editors to add an abstract before the next draft
16:56:17 <trackbot> Sorry, couldn't find user - item
16:56:34 <rillianbis> francois: we need a resolution that the group agrees to publish a draft
16:56:49 <rillianbis> DanD: can do that on the list
16:57:02 <rillianbis> francois: no, it has to be explicit
16:57:14 <burn> s/DanD/Dan Burnett/
16:57:24 <rillianbis> Harald: I think it's a good idea
16:57:25 <francois> s/no, it has to be explixit/yes, it just has to be archived/
16:57:33 <rillianbis> No objection
16:57:39 <rillianbis> I'll send a note to the list
16:57:57 <rillianbis> Inserted agenda point (3 minutes left)
16:58:11 <rillianbis> Are some people ok to stay late
16:58:14 <rillianbis> (some people are)
16:58:19 <fluffy> fluffy has joined #webrtc
16:58:21 <rillianbis> Topic: low level api
16:58:43 <rillianbis> Neil: based on our experince with phono, we'd like to see
16:58:49 <rillianbis> the bare minimum in the browser
16:59:07 <rillianbis> and do the rest of sdp in javascript
16:59:18 <francois> zakim, mute me
16:59:18 <Zakim> Francois_Daoust should now be muted
16:59:22 <rillianbis> Cullen: I think the only thing it would take to convince me this was a good thing
16:59:39 <rillianbis> is a clear idea that this was mapping to an existing signaling only gateway
16:59:49 <rillianbis> my concerns would be the complexity of the js
16:59:58 <rillianbis> and getting that right
17:00:11 <rillianbis> if it were just audio, I'd be for that
17:00:26 <rillianbis> but the complexity of the parameters with video are complicated
17:00:38 <rillianbis> e.g. the number of macroblock per second the decoder can process
17:00:52 <rillianbis> there are a bunch of different variables you have to negotiation
17:00:57 <rillianbis> negotiate
17:01:16 <rillianbis> and many codec-specific constraints
17:01:28 <rillianbis> where's the best place to do that negotiation, browser, or javascript?
17:01:36 <rillianbis> next year, if a better video codec comes out
17:01:51 <rillianbis> I want websites written in a basic way
17:01:56 <rillianbis> to be able to take advantage of that
17:02:11 <rillianbis> jesup: since the parameters are codec-specific
17:02:17 <rillianbis> some of them map to each other
17:02:29 <rillianbis> but when a new codec comes out, there's not prebuilt mapping
17:02:33 <rillianbis> js can use
17:02:46 <rillianbis> cullen: the last time I looked at this, this was the part which was hard
17:02:57 <rillianbis> and I think that's what we need to look at to figure out what to do
17:03:15 <rillianbis> jesup: there's no guarantee websites will upgrade
17:03:29 <rillianbis> cullen: e.g. most prevelent jquery is the first one that really worked
17:03:49 <rillianbis> so many people pick a version and never upgrade
17:04:02 <rillianbis> Neil: so we need to prove we have no data in the javascript?
17:04:12 <rillianbis> Cullen: we need to talk about the tradeoffs
17:04:24 <rillianbis> let's look at a new video codec, because that's the most complicated case
17:04:37 <rillianbis> justin: I'd like to look at RTP, encryption
17:04:48 <rillianbis> I like the flexibility this approach provides
17:05:09 <rillianbis> but I'm concerned it makes it impossible for anyone but experts to do this
17:05:30 <rillianbis> and if it *is* done in the browser, experts can improve the chances of iteroper
17:06:17 <rillianbis> My concern is specifically that at the API if we have an opaque blob generated by the browser
17:06:32 <rillianbis> we'll have a better chance of interoperability than if that blob is generated by a web applicaiton
17:06:41 <rillianbis> because there are fewer things to test
17:06:51 <francois> s/applicaiton/application/
17:07:04 <rillianbis> Neil: We could just test/certify the js libraries
17:07:27 <rillianbis> Neil: do browsers support downloadable or 3rd party codecs? that raises the same issue
17:07:42 <rillianbis> Tim: Safari sort of does, in a limited way, but that's the only one
17:07:56 <rillianbis> jesup: this has been considered out of scope
17:08:31 <rillianbis> Cullen: downloading a codec wouldn't be enough, you'd need to also download the negotiation logic for the codec
17:08:54 <rillianbis> Harald: With the addition of downloaded codecs, we have *three* moving pieces that need to know about each other
17:09:09 <rillianbis> Tim: Regardless of the intents of this group to make an api for experts only
17:09:14 <rillianbis> people will use it
17:09:23 <rillianbis> we've seen with video codecs
17:09:28 <rillianbis> that users love starship consoles
17:09:38 <rillianbis> and if you give them knobs to tweak they will tweak them
17:09:51 <rillianbis> regardless of whether it's a good idea or not
17:10:10 <rillianbis> Neil: but giving the flexibility to those who want them is a good idea, surely?
17:10:35 <rillianbis> Cullen: I like that js can do absolutely anything, but I also want things to be as simple as possible
17:10:51 <rillianbis> someone else: can't do both easy and expert interfaces in the same API
17:11:02 <hta> someone else = Justin
17:11:22 <rillianbis> jesup: I don't have a problem with a layered api to do that
17:11:36 <rillianbis> cullen: if you think the javasscript can't do it with the sdp,
17:11:45 <rillianbis> I think that's why we say "offer answer"
17:11:57 <rillianbis> I think it would be hard to find something you couldn't do by modifying the SDP
17:12:29 <rillianbis> Tim D(?): We think it's safer to manipulate the SDP than to have an actual API?
17:12:36 <rillianbis> Cullen: well, they'd use a library
17:12:49 <burn> s/Tim D(?)/Tim Panton/
17:13:00 <rillianbis> jesup: Anything that exposes the encryption keys to js
17:13:09 <rillianbis> means your media isn't secure
17:13:20 <rillianbis> SRTP-DES is a problem because of this
17:13:28 <rillianbis> Harald: this is covered by the security draft
17:13:44 <rillianbis> To close up the discussion, we don't have consensus for one or the other here
17:14:10 <rillianbis> It occurs to me...
17:14:22 <rillianbis> Can I ask you and Cullen to take the action item
17:14:25 <rillianbis> to figure out this issue
17:14:38 <rillianbis> justin: The other thing I'd like to understand is
17:14:40 <Zakim> -Ralph_Giles
17:14:46 <burn> s/ask you and Cullen/ask Neil and Cullen/
17:15:10 <rillianbis> sorry, I fell off the call
17:16:26 <francois> [scribe dropped of the call, some exchanges missed]
17:16:38 <francois> scribenick: francois
17:17:16 <francois> Cullen: glad to work with people on this. Doable to do an API on this. It's a trade-off to reach. Complicated cases would need to be mapped to SDP.
17:17:31 <francois> ... You're re-inventing an alternative to SDP here, make no mistake.
17:17:56 <francois> ... Watched this several times, and it's not a good path to follow.
17:18:16 <francois> DanBurnett: is it reinventing SDP or allowing Web developers who do not know SDP to use it?
17:18:53 <francois> Cullen: I can't tell how it's different, but I think you're right.
17:19:05 <francois> ??1: In general, the difference is in the intelligence of the client.
17:19:33 <burn> s/who do not know SDP to use it/who may or may not be experts in codec negotiation to develop alternatives/
17:19:51 <burn> s/??1/Tim Panton/
17:19:52 <francois> Harald: let's take the discussion to the list, Neil and Cullen to drive the discussion.
17:20:01 <Zakim> +Ralph_Giles
17:20:24 <rillianbis> I just want to inform the group of the of the IETF audio working group
17:20:27 <francois> Topic: Liaison with other WG
17:20:39 <francois> s/I just want/Stefan: I just want/
17:21:13 <rillianbis> there was another proposal which was Mozilla proprietary extension to Media streams which could solve this
17:21:23 <rillianbis> and I think there wasn't good progress on this
17:21:38 <rillianbis> we are hoping to have a joint session with the audio working group
17:21:43 <rillianbis> to discuss this furthere
17:21:47 <rillianbis> any questions?
17:21:55 <rillianbis> comments on Tim?
17:22:05 <rillianbis> Tim: That sounds like an accurate summary
17:22:10 <francois> [Remember to register for TPAC: http://www.w3.org/2002/09/wbs/35125/TPAC2011/  Deadline 14 October]
17:22:17 <rillianbis> wrt TPAC, I think the others are relatively open
17:22:25 <rillianbis> should I plan of sticking around for those?
17:22:35 <rillianbis> Dan Burnett: depends an what you want to attend
17:22:56 <rillianbis> ??: Is there anything you'd recommend, Dan?
17:23:11 <rillianbis> Dan B: the plenary on wednesday is a good way to find out what the hot topics are
17:23:29 <rillianbis> We're doing potentially the html speech working group on Thursday
17:23:58 <francois> [On Thursday/Friday: HTML WG, DAP, HTML Speech XG are meeting]
17:24:00 <rillianbis> and ultimately there might be a need to mix Interactive Voice Response applicaitons 
17:24:12 <rillianbis> with this group
17:24:35 <rillianbis> ??: Next liason point
17:24:41 <rillianbis> Rich: Device apis
17:24:46 <rillianbis> Media Capture api: no work for a year
17:24:53 <rillianbis> hope at TPAC we'll prune this
17:24:58 <rillianbis> and over to WebRTC for getUserMedia
17:25:04 <rillianbis> still got HTML Media Capture
17:25:08 <rillianbis> but that's not able getting objects
17:25:13 <rillianbis> but prerecorded audio vidoe
17:25:19 <rillianbis> also web intents, discovery
17:25:20 <derf> s/able/about/
17:25:28 <rillianbis> which may be of interest
17:25:31 <rillianbis> meeting friday
17:25:41 <rillianbis> if there's stuff from webrtc which might find a home in dap
17:25:45 <rillianbis> we'd welcome that
17:25:49 <francois> s/meeting friday/meeting Thursday and Friday/
17:26:02 <rillianbis> Harald: we're at the end of the agenda
17:26:04 <francois> ack me
17:26:05 <rillianbis> only 1.5 hours
17:26:11 <rillianbis> any other business
17:26:22 <rillianbis> francois: anyone planning to attend remotely?
17:26:30 <rillianbis> need to schedule if we need a polycom
17:26:41 <rillianbis> justin: I'm hoping to attend in person
17:26:46 <rillianbis> but if now, I'd like to call in
17:27:00 <rillianbis> ??: I find it very difficult to have remote participants in f2f meetings
17:27:18 <rillianbis> It's ok to have in the room, but I don't think we should assume that's an option
17:27:27 <burn> s/??/Dan Burnett/
17:27:27 <francois> s/??:/DanBurnett:/
17:27:46 <rillianbis> jesup: what worked at the last IETF meeting was having someone take comments from IRC and speak them at the mic
17:27:56 <rillianbis> which helps a lot with those issues
17:28:13 <rillianbis> francois: If you think you'll attend remotely, let me know by next Wednesday
17:28:38 <rillianbis> Harald: Let's close the meeting
17:28:41 <rillianbis> Thanks all!
17:28:41 <Zakim> -Cullen_Jennings
17:28:43 <Zakim> -Tim_Panton
17:28:44 <Zakim> -Adam_Bergkvist
17:28:44 <Zakim> -Harald_Alvestrand
17:28:46 <Zakim> -richt
17:28:46 <Zakim> -Justin_Uberti
17:28:46 <Zakim> -Stefan_Håkansson
17:28:47 <burn> s/that's an option/that's a good option for participants/
17:28:47 <Zakim> -Francois_Daoust
17:28:48 <Zakim> -Neil_Stratford
17:28:50 <Zakim> -DanRomascanu
17:28:52 <Zakim> - +1.610.889.aaoo
17:28:52 <francois> Zakim, list attendees
17:28:54 <Zakim> -Mani_Mahalingam
17:28:56 <Zakim> -Ralph_Giles
17:28:58 <Zakim> -Dan_Druta
17:29:01 <Zakim> As of this point the attendees have been +47.41.44.aaaa, +1.604.728.aabb, Dan_Burnett, +44.122.375.aacc, Ralph_Giles, Neil_Stratford, +46.1.07.14.aadd, +1.408.562.aaee,
17:29:03 <Zakim> ... +1.403.244.aaff, Harald_Alvestrand, Stefan_Håkansson, +1.425.580.aagg, +972.3.645.aahh, Tim_Panton, Cullen_Jennings, +34.38.83.aaii, +46.1.07.14.aajj, Dan_Druta,
17:29:06 <Zakim> ... +44.208.144.aakk, richt, DanRomascanu, +1.314.529.aall, +1.425.894.aamm, Mani_Mahalingam, Adam_Bergkvist, Christophe_Eyrignoux?, Justin_Uberti, Francois_Daoust, Tim_Terriberry,
17:29:09 <Zakim> ... +1.408.421.aann, +1.610.889.aaoo
17:29:11 <Zakim> - +1.314.529.aall
17:29:13 <Zakim> -Dan_Burnett
17:29:15 <Zakim> -Tim_Terriberry
17:29:16 <francois> RRSAgent, draft minutes
17:29:16 <RRSAgent> I have made the request to generate http://www.w3.org/2011/10/05-webrtc-minutes.html francois
17:29:17 <Zakim> -Christophe_Eyrignoux?
17:29:19 <Zakim> UW_(WebRTC)12:00PM has ended
17:29:21 <Zakim> Attendees were +47.41.44.aaaa, +1.604.728.aabb, Dan_Burnett, +44.122.375.aacc, Ralph_Giles, Neil_Stratford, +46.1.07.14.aadd, +1.408.562.aaee, +1.403.244.aaff, Harald_Alvestrand,
17:29:26 <Zakim> ... Stefan_Håkansson, +1.425.580.aagg, +972.3.645.aahh, Tim_Panton, Cullen_Jennings, +34.38.83.aaii, +46.1.07.14.aajj, Dan_Druta, +44.208.144.aakk, richt, DanRomascanu,
17:29:33 <Zakim> ... +1.314.529.aall, +1.425.894.aamm, Mani_Mahalingam, Adam_Bergkvist, Christophe_Eyrignoux?, Justin_Uberti, Francois_Daoust, Tim_Terriberry, +1.408.421.aann, +1.610.889.aaoo
17:29:42 <rillianbis> Sorry about dropping out there at the end. 
17:30:17 <rillianbis> We just moved office and our phones aren't working yet. Ran out of credit on my mobile.
17:30:31 <rillianbis> francois: thanks for the help with corrections
17:31:44 <Mani> Mani has left #webrtc
19:32:43 <Zakim> Zakim has left #webrtc
20:38:14 <francois> RRSAgent, bye
20:38:14 <RRSAgent> I see 1 open action item saved in http://www.w3.org/2011/10/05-webrtc-actions.rdf :
20:38:14 <RRSAgent> ACTION: item to editors to add an abstract before the next draft [1]
20:38:14 <RRSAgent>   recorded in http://www.w3.org/2011/10/05-webrtc-irc#T16-56-17