15:46:03 <RRSAgent> RRSAgent has joined #webrtc
15:46:03 <RRSAgent> logging to http://www.w3.org/2012/12/13-webrtc-irc
15:46:05 <trackbot> RRSAgent, make logs world
15:46:06 <Zakim> Zakim has joined #webrtc
15:46:07 <trackbot> Zakim, this will be RTC
15:46:07 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
15:46:08 <trackbot> Meeting: Web Real-Time Communications Working Group Teleconference
15:46:09 <trackbot> Date: 13 December 2012
15:53:08 <dom> fluffy, I'm trying to that the conf code fixed
15:53:29 <fluffy> thanks dom
15:53:54 <burn> burn has joined #webrtc
15:54:39 <jesup> jesup has joined #webrtc
15:55:47 <DanD> DanD has joined #webrtc
15:56:48 <stefanh> stefanh has joined #webrtc
15:56:55 <martin> martin has joined #webrtc
15:56:58 <dom> dom has changed the topic to: dom looking into the conf code problem
15:57:09 <stefanh> @dom: thanks!
15:57:31 <amy> amy has joined #webrtc
15:57:41 <fluffy> I can set up an alternative bridge if people want me too
15:57:41 <dom> Zakim, this will be RTC
15:57:41 <Zakim> I do not see a conference matching that name scheduled within the next hour, dom
15:58:22 <dom> Zakim, this will be 9782
15:58:22 <Zakim> I do not see a conference matching that name scheduled within the next hour, dom
15:58:24 <fluffy> ok -
15:58:38 <adambe> adambe has joined #webrtc
15:59:34 <ekr> ekr has joined #webrtc
15:59:53 <ekr> what is the actual duration of this conference call. I see "Thursday, December 13, 16:00-17:30 UTC (10:00am-11:00am Boston local)"
16:00:07 <Milan_Patel> Milan_Patel has joined #webrtc
16:00:12 <stefanh> should be 11am-1230 boston local
16:00:23 <ekr> OK.
16:00:28 <hta> hta has joined #webrtc
16:00:43 <JeromeMarcon> JeromeMarcon has joined #webrtc
16:00:43 <stefanh> dom, any instructions?
16:00:48 <hta> waiting for update?
16:00:53 <adambe> is 9782 the right conf code?
16:01:03 <dom> adambe, there is a bug I'm looking into
16:01:17 <adambe> dom: k, thanks
16:01:22 <dom> stefanh, hta, we can either proceed with a different code, or wait a bit more to get the right one
16:01:26 <dom> which do you prefer?
16:01:32 <dan_romascanu> dan_romascanu has joined #webrtc
16:01:43 <stefanh> i prefer start now with a different code
16:01:51 <dom> ok, let's do that then
16:01:53 <dom> Zakim, room for 25?
16:01:56 <Zakim> ok, dom; conference Team_(webrtc)16:01Z scheduled with code 26631 (CONF1) for 60 minutes until 1701Z; however, please note that capacity is now overbooked
16:02:16 <dan_romascanu> we cannot enter the conference
16:02:24 <dom> all, please use 26631 as conf code instead
16:02:33 <amy> amy has left #webrtc
16:02:39 <gmandyam> gmandyam has joined #webrtc
16:02:40 <Zakim> Team_(webrtc)16:01Z has now started
16:02:47 <Zakim> +hta
16:02:54 <hta> I am the first participant on 26631#
16:03:06 <Zakim> +??P30
16:03:09 <Zakim> +stefanh
16:03:09 <dom> Zakim, ??P30 is me
16:03:09 <Zakim> +dom; got it
16:03:17 <Zakim> + +46.1.07.14.aaaa
16:03:17 <Zakim> +jesus|laptop
16:03:26 <Zakim> + +1.408.902.aabb
16:03:31 <Zakim> +Milan_Patel
16:03:32 <Zakim> +Dan_Druta
16:03:43 <Zakim> + +972.9.957.aacc
16:03:43 <Zakim> +??P36
16:03:47 <Zakim> +[IPcaller]
16:03:50 <fluffy> Zakim, aacc is me
16:03:50 <Zakim> +fluffy; got it
16:03:56 <Zakim> +gmandyam
16:04:04 <dan_romascanu> +972.9.957.aacc
16:04:06 <fluffy> Zakim, aabb is me
16:04:06 <Zakim> +fluffy; got it
16:04:18 <dom> Zakim, aacc is dan_romascanu
16:04:19 <Zakim> sorry, dom, I do not recognize a party named 'aacc'
16:04:21 <gmandyam> Giri Mandyam from Qualcomm Innovation Center
16:04:25 <Zakim> + +1.650.678.aadd
16:04:26 <jib> jib has joined #webrtc
16:04:33 <Zakim> +[Mozilla]
16:04:42 <ekr> zakim, who is here?
16:04:42 <Zakim> On the phone I see hta, dom, stefanh, adambe, jesuslaptop, fluffy.a, Milan_Patel, Dan_Druta, fluffy, ??P36, [IPcaller], gmandyam, +1.650.678.aadd, [Mozilla]
16:04:45 <Zakim> On IRC I see jib, gmandyam, dan_romascanu, JeromeMarcon, hta, Milan_Patel, ekr, adambe, martin, stefanh, DanD, jesup, burn, Zakim, RRSAgent, fluffy, mreavy, tuexen, richt,
16:04:46 <Zakim> ... Josh_Soref_, Dweezahr, danielfi_, hiro, heath, trackbot, schuki, dom
16:04:46 <dan_romascanu> aacc is me
16:04:51 <ekr> zakim, aadd is ekr
16:04:51 <Zakim> +ekr; got it
16:04:57 <richt> richt has left #webrtc
16:05:06 <stephane> stephane has joined #webrtc
16:05:13 <stefanh> agenda: http://lists.w3.org/Archives/Public/public-webrtc/2012Dec/0033.html
16:05:16 <tuexen> zakim, ??P36 is me
16:05:16 <Zakim> +tuexen; got it
16:05:20 <Zakim> + +33.6.85.56.aaee
16:05:21 <jesup> zakim, who is on the call
16:05:21 <Zakim> I don't understand 'who is on the call', jesup
16:05:29 <fluffy> @dan, try that with Zakim, before it
16:05:30 <ekr> zakim, who is here?
16:05:30 <Zakim> On the phone I see hta, dom, stefanh, adambe, jesuslaptop, fluffy.a, Milan_Patel, Dan_Druta, fluffy, tuexen, [IPcaller], gmandyam, ekr, [Mozilla], +33.6.85.56.aaee
16:05:31 <martin> * I'm either ??P36 or [IPcaller]
16:05:33 <Zakim> On IRC I see stephane, jib, gmandyam, dan_romascanu, JeromeMarcon, hta, Milan_Patel, ekr, adambe, martin, stefanh, DanD, jesup, burn, Zakim, RRSAgent, fluffy, mreavy, tuexen,
16:05:33 <Zakim> ... Josh_Soref_, Dweezahr, danielfi_, hiro, heath, trackbot, schuki
16:05:36 <dom> Zakim, who's on the call?
16:05:36 <Zakim> On the phone I see hta, dom, stefanh, adambe, jesuslaptop, fluffy.a, Milan_Patel, Dan_Druta, fluffy, tuexen, [IPcaller], gmandyam, ekr, [Mozilla], +33.6.85.56.aaee
16:05:58 <martin> zakim, I am [IPcaller]
16:05:58 <Zakim> ok, martin, I now associate you with [IPcaller]
16:06:16 <dan_romascanu> zakim - i am on the phone - +972 ... aacc
16:06:17 <JeromeMarcon> aaee is me
16:06:20 <Josh_Soref_> Josh_Soref_ has changed the topic to: conference Team_(webrtc)16:01Z scheduled with code 26631 (CONF1) for 60 minutes until 1701Z
16:06:26 <dom> Zakim, aaee is JeromeMarcon
16:06:26 <Zakim> +JeromeMarcon; got it
16:06:27 <juberti> juberti has joined #webrtc
16:06:35 <dom> Zakim, aacc is dan_romascanu
16:06:35 <Zakim> sorry, dom, I do not recognize a party named 'aacc'
16:06:39 <Zakim> + +1.267.934.aaff
16:06:39 <Josh_Soref> Josh_Soref has changed the topic to: conference Team_(webrtc)16:01Z scheduled with code 26631 (CONF1) for 60 minutes until 1701Z
16:06:41 <juberti> Zakim, who's here
16:06:42 <Zakim> juberti, you need to end that query with '?'
16:06:44 <AndyHutton> AndyHutton has joined #webrtc
16:06:46 <jesup> zakim, jesuslaptop is me
16:06:47 <Zakim> +jesup; got it
16:07:04 <dan_romascanu> what do you mean I do not recognize?
16:07:07 <Zakim> +Jim_Barnett
16:07:20 <jesup> That was weird... Thanks whomever set my name that way at the MediaCap telco ;-)
16:07:30 <Zakim> + +1.972.999.aagg
16:07:30 <hta> check http://www.w3.org/2011/04/webrtc/wiki/Teleconferences for document links
16:07:43 <Zakim> + +44.190.881.aahh
16:07:46 <Zakim> + +1.425.893.aaii
16:07:55 <juberti> Zakim, aaii is juberti
16:07:55 <Zakim> +juberti; got it
16:07:59 <Jim> Jim has joined #webrtc
16:08:04 <Zakim> + +33.7.88.18.aajj
16:08:53 <stefanh> Josh, are you volonteering?
16:09:16 <dom> Zakim, who's noisy?
16:09:27 <Zakim> dom, listening for 10 seconds I heard sound from the following: hta (37%), fluffy.a (10%)
16:10:31 <stefanh> scribe: stefanh
16:10:41 <stefanh> hta: agenda first
16:10:53 <stefanh> approve minutes from last meeting
16:11:03 <stefanh> ....ok, minutes approved
16:11:05 <Zakim> + +91.22.39.14.aakk
16:11:25 <stefanh> next on the agenda: Justin and states
16:11:25 <dom> -> http://www.w3.org/2011/04/webrtc/wiki/File:Telco-2012-12-13-States.pdf Justin's slides
16:11:57 <dom> i/stefanh: next/Topic: WebRTC States
16:12:13 <stefanh> Justing: continuation of conv in Lyon
16:12:23 <Zakim> +??P53
16:12:24 <stefanh> ....capture the discussion in proposed changes
16:12:37 <stefanh> ...RTCPeerState
16:12:48 <stefanh> ....could be named signaling state instead
16:13:07 <stefanh> ...readyState similar to WS really
16:13:22 <timpanton> timpanton has joined #webrtc
16:13:26 <stefanh> ...app gets notified about changes via statechange callback
16:13:27 <jesup> I agree on name change since it doesn't match the "common" cross-api readyState
16:13:35 <stefanh> ...state removed
16:13:52 <stefanh> ....changed names in sentOffer/Answer
16:14:03 <stefanh> ...prAnswer missing from eds draft
16:14:21 <AdamRoach> AdamRoach has joined #webrtc
16:14:21 <stefanh> ...next slide shows update
16:14:28 <stefanh> ...no "new" state
16:14:50 <stefanh> Martin: question on a transtion
16:15:06 <stefanh> ....list should be updated to make this clearer
16:15:21 <stefanh> Justin: will fix this and update names
16:15:36 <jesup> name_change++
16:16:04 <dom> +1 on rtcsignalingstate and signalingState accessor
16:16:15 <stefanh> Decided to change name to RTCSignalingState, onsignalingstatechange
16:16:25 <jesup> ekr and hta also agreed with name change
16:16:40 <stefanh> Justin: carrying on to ICE states
16:16:51 <stefanh> ...change gathering state name
16:17:40 <stefanh> ...RTCICEGatheringstate ICEGatheringstate
16:18:01 <stefanh> ...no explicit callback, find out via null ice callback
16:18:15 <stefanh> ...can also poll to find out state
16:18:17 <dom> Zakim, who's noisy?
16:18:28 <Zakim> dom, listening for 10 seconds I heard sound from the following: hta (29%), fluffy.a (5%), juberti (63%), +91.22.39.14.aakk (65%)
16:18:32 <dom> Zakim, mute aakk
16:18:33 <Zakim> +91.22.39.14.aakk should now be muted
16:18:35 <vidhya> vidhya has joined #webrtc
16:18:37 <stefanh> ...moving on to ICEConnection state
16:18:59 <stefanh> ...prev called ICEstate, to change to ICEconn...state
16:19:16 <stefanh> ....ICEconnectionstate seems to be preferred
16:19:55 <stefanh> Everyone seems happy with name changes
16:20:15 <stefanh> Justing: getting rid of starting state, go directly to new state
16:20:28 <stefanh> ...next slide updated based on disc in Lyon
16:20:46 <stefanh> ...details of transitions, time-outs,
16:20:57 <stefanh> ...look at slides
16:21:30 <stefanh> Justin: when would you change from connected to completed for the control side?
16:22:09 <stefanh> ...updated offer not usable as originally thought
16:22:23 <stefanh> Cullen: when the candidate list to receive was empty
16:22:42 <stefanh> Ekr: confusing concept
16:22:55 <stefanh> Justin: not clear when
16:23:03 <stefanh> Ekr: is this important?
16:23:31 <stefanh> Cullen: yes, then you know things are stable (jitter buffers can settle and so on)
16:24:06 <stefanh> ....important to know in JS. Now you know things are as good as they will be
16:24:36 <stefanh> Justin: When swapping from TURN to direct, is this a case
16:24:57 <stefanh> Cullen: yes, and knowing stats will not get better
16:25:07 <stefanh> Ekr: I'm not sure we need this
16:25:28 <stefanh> Cullen: this is another thing
16:25:52 <stefanh> ...let's discuss if we need to know when ICE state machine is done
16:26:01 <Josh_Soref> Zakim, where is +91?
16:26:01 <Zakim> country code 91 is India
16:26:05 <stefanh> Justin: very hard to know at controlling side
16:26:22 <stefanh> Cullen: fair enough
16:26:43 <stefanh> Ekr: when can control side abandon candidates is the minimum to know
16:27:25 <stefanh> Cullen: this stuff is very unclear in spec (RFC presumably meant)
16:27:56 <stefanh> Ekr: need to know when we can free up turn server resources
16:28:28 <stefanh> Tim: is this not when you stop sending indications
16:28:41 <stefanh> Justin: not strong enough signal for this
16:28:59 <stefanh> ...no clear way for control side to know other side is done
16:29:31 <stefanh> Cullen: need to go look in the ICE spec
16:29:48 <stefanh> Ekr: refering to ICE spec
16:30:05 <stefanh> ...difficult
16:30:19 <stefanh> Cullen: nothing in offer saying ICE is done
16:30:33 <stefanh> Justin: can't solve here
16:30:59 <stefanh> ...ACTION: sort out if we can know when going to finished
16:31:15 <stefanh> Ekr: need to solve this
16:31:34 <stefanh> Martin: Use renogitationneeded and send a new offer
16:31:45 <stefanh> hta: who can take on this?
16:32:08 <stefanh> ACTION justin to drive proposal
16:32:08 <trackbot> Created ACTION-75 - Drive proposal [on Justin Uberti - due 2012-12-20].
16:32:09 <Zakim> +Dan_Burnett
16:32:16 <burn> zakim, I am Dan_Burnett
16:32:16 <Zakim> ok, burn, I now associate you with Dan_Burnett
16:32:51 <stefanh> (speculation on solutions)
16:33:03 <stefanh> (between a few people)
16:33:23 <stefanh> Justin: any other comments?
16:33:51 <stefanh> ....Question on ICE restart chaning states
16:34:09 <stefanh> ...ICE restart not described before
16:34:31 <stefanh> ...proposal to use constraints with createOffer/Answer
16:34:59 <stefanh> ...get an SDP with new ufrag passwd
16:35:09 <stefanh> ....signaled, and ICE restarts
16:35:51 <stefanh> Martin: implicit creation of ufrag passwd in this situation?
16:36:17 <stefanh> Justin: yes use that as trigger, leaning towards implicit
16:36:56 <stefanh> Martin: App assumed not to be allowed to change ufrag/passwd, but this might not be true
16:37:08 <stefanh> Ekr: seeems like an othogonal question
16:37:22 <stefanh> ...prefer explicit indicator
16:37:50 <stefanh> ...reading the slide: (scribe losing track)
16:38:14 <stefanh> Justin: setLocal triggers ICE restart on local side
16:38:32 <martin> ekr: we're continuing the invariant that setRemote doesn't do very much
16:38:37 <stefanh> Ekr: What will happen, will user experience a pause
16:39:13 <martin> justin: we don't dump the existing flows, but we bring up the new candidate pairs to create a replacement flow, when that's ready, we use the new one
16:39:35 <stefanh> ekr: when can I completely cut over
16:39:48 <stefanh> justin: unsolved
16:40:18 <stefanh> ...weird edge cases
16:40:30 <stefanh> ...original conn can come back up
16:40:55 <stefanh> martin: go to completed when on the new flows
16:41:11 <stefanh> ...go to new flow as soon as connected
16:41:30 <stefanh> justing: will create new slides and examples
16:41:50 <stefanh> cullen: use make before break to make sure nice experience
16:42:21 <stefanh> martin: what happens when new flow fails and old one coems back
16:42:29 <stefanh> ..chanse to revive
16:42:48 <hta> action juberti: create a specific example of cutover after an ICE restart.
16:42:48 <trackbot> Created ACTION-76 - Create a specific example of cutover after an ICE restart. [on Justin Uberti - due 2012-12-20].
16:42:49 <martin> a truth table with the different states might help
16:43:01 <stefanh> Ekr: maintaining several xxx
16:43:10 <stefanh> ...feature needed to have?
16:43:18 <hta> xxx = connections at the same time.
16:43:35 <stefanh> cullen: would be nice, to keep both a WiFi and a 3G connection at the same time
16:43:54 <stefanh> ekr: how does this work with signaling and ice restart?
16:44:18 <stefanh> ...what are the mechanics
16:44:35 <stefanh> justin: need to look into ice mobility stuff
16:44:50 <stefanh> ...keep existing connections during restart
16:44:59 <stefanh> ....preserve media flows
16:45:23 <martin> I'd like to recommend that if we want this feature, we go to mmusic
16:45:25 <stefanh> hta: moving toward "nice to have", let's move one
16:45:52 <stefanh> ekr: trickle ice during connection completed to update
16:46:06 <stefanh> cullen: would go back to connecting
16:46:21 <stefanh> hta: ice restart useful for rehydration
16:46:30 <fluffy> fluffy has joined #webrtc
16:46:50 <stefanh> justin: ice restart throws candidates away - gives clean slate
16:47:19 <stefanh> adambe: if someone told me to use ice restart, i'd use updateice
16:47:33 <stefanh> ...more natural to have ice restart in update
16:47:52 <stefanh> justing: more natural to do via existing signaling mechs
16:48:05 <stefanh> ...change name to make this more clear
16:48:15 <stefanh> adambe: that was my thinking
16:48:41 <stefanh> Tim: q on ice restart constraint: can media be added in conjuction?
16:48:51 <stefanh> justin: should be possible
16:49:02 <martin> s/Tim/Andy/
16:49:26 <stefanh> justin: should be OK
16:49:42 <stefanh> Andy: some comments re jsep on that
16:49:49 <stefanh> justin: now rollback
16:50:06 <stefanh> ...to make clear: drive signaling state backwards
16:50:19 <stefanh> ...if other side does not want to do what's in offer
16:50:39 <stefanh> ...roll back to stable state
16:51:07 <stefanh> ...also if a new offer meaning that previous should be ignored
16:51:27 <stefanh> martin: easy to explain and implement
16:52:01 <stefanh> ...rejection on an offer would often be based on what the offer contains, so after setting offer you need to back
16:52:36 <stefanh> justin: easy to implement. More difficult in a prAnswer case, relaed to crypto keys
16:52:56 <stefanh> ...not clear how media can be decoded with new and old key
16:53:18 <stefanh> cullen: need to nail down what happens to media during transition states
16:53:30 <stefanh> ...what media is received, what is transmitted
16:53:46 <martin> it's more than just media, justin's comment about DTLS negotiation is an interesting one to think on
16:54:02 <ekr> I tuned out for a minute. Can you repeat?
16:54:17 <stefanh> justin: existing and new media descriptions must be handled
16:54:37 <stefanh> martin: pranswer can be replaced to a stage where is does not contain anything
16:55:19 <stefanh> cullen: when we figurre out what we want to do in non provisional cases the provisional ones will be easy
16:55:41 <stefanh> randell: agree to cullen and marting.
16:56:05 <stefanh> ....need to cover that version, martin gave one, need more
16:56:18 <stefanh> ...may not be as hard as i make it up to be
16:56:44 <stefanh> cullen: do non-prov first
16:57:01 <stefanh> martin: on offer side prAns does not do a lot
16:57:10 <stefanh> ...don't worry that much about media
16:57:24 <stefanh> justin: disagree on this
16:57:40 <stefanh> ...pranswer has all cap of an answer
16:57:56 <stefanh> hta: still not fully clear on rollback reqs
16:58:35 <stefanh> justing: haveRemote / haveLocal to stable rollback
16:58:49 <stefanh> ...first, do prStuff later
16:59:13 <stefanh> cullen: would like us to come to prStuff as well
16:59:20 <stefanh> ...but do basic thing first
16:59:30 <stefanh> ...and next layer after that
16:59:44 <stefanh> justin: api
17:00:33 <stefanh> ...a couple of ways.
17:00:39 <martin> RTCSessionDescription.ROLLBACK constant might make this one easier to write code for
17:01:15 <stefanh> ...method, setL/R with session desc "rollback", setL/R with null
17:01:53 <stefanh> ...programming errors could trgger a rollback if we use "null"
17:02:12 <stefanh> ....conclusion: prefer setL/R with rollback session desc
17:02:55 <stefanh> cullen: sdp can get out of sync. JS and UA have different understanding about what to roll back to
17:03:13 <stefanh> justin: can supply the sdp we're rolling back to
17:03:33 <stefanh> ...fragile if wrong sdp is supplied
17:03:52 <stefanh> dan: i like supplying the sdp rolling back to
17:04:09 <stefanh> ...the only way to can know is to supply the description
17:04:16 <stefanh> ...like that idea
17:04:33 <stefanh> cullen: but you can always get what you rolled back to
17:04:49 <stefanh> dan: you can find out you rolled back to the wrong state
17:05:12 <stefanh> hta: equavelent to record the sdp beforehand
17:05:49 <stefanh> martin: the UA can keep track of the descriptions, app can check
17:06:05 <stefanh> ...which one you'd roll back to
17:06:42 <stefanh> ....constant on rtcsessiondesc (essentially justin number two)
17:06:57 <stefanh> ...constant describe type of rollback
17:07:09 <stefanh> cullen: why not just make a new method
17:07:23 <jesup> zakim: randell is jesup
17:07:41 <stefanh> ekr: option two allows rollback without app intervention
17:08:10 <stefanh> cullen: come around to number two with martins addition
17:08:33 <stefanh> Jim: can you go back several steps?
17:08:37 <stefanh> justin: no
17:08:51 <ekr> recording martins proposal: justin's proposal #2 plus explicit accessors for current and expected SDP states
17:09:24 <stefanh> martin: becomes a bit odd in certain situations
17:09:35 <stefanh> justin: see what you mean
17:09:52 <stefanh> ...we may be overdesigning
17:10:20 <stefanh> martin: lets do basic first, next pranswer
17:10:35 <stefanh> justin: slide 11 overview o what rollback does
17:10:57 <stefanh> (refer to slide for details)
17:11:15 <martin> proposal is to go with option #2 for rollback: set{Local,Remote}Description(new RTCSessionDescription({type:'rollback'})) and expose new attributes that show the whole set of four descriptions that could be in effect: both the stable+pending  and local+remote descriptions.
17:11:42 <stefanh> cullen: seems good, dislike phrasing "move state back"
17:11:54 <stefanh> hta: adjust later
17:12:10 <ekr> I tend to agree with cullen that "one state back" is creepy
17:12:24 <ekr> especially since there are cases we can't roll back from, e.g., stable
17:12:44 <stefanh> cullen: need to roll back to a specific state
17:12:57 <stefanh> ACTION cullen: use case for rollback
17:12:58 <trackbot> Created ACTION-77 - Use case for rollback [on Cullen Jennings - due 2012-12-20].
17:13:06 <martin> that use case might drive us toward a different API surface
17:13:16 <stefanh> justin: last slide
17:13:49 <stefanh> ....situatins when gathering will be stopped and candidates abandoned
17:14:12 <stefanh> ...can be used for getting pool candidates actually
17:14:35 <stefanh> ...some things can not be fully rolled back
17:14:48 <stefanh> ...remove stream for example
17:15:01 <stefanh> hta: covered this topic
17:15:27 <stefanh> ...settled on a proposal on local/remote offer state, will look at other state later
17:15:44 <stefanh> switch to candidate warmup session
17:15:54 <stefanh> martin:
17:15:58 <ekr_> ekr_ has joined #webrtc
17:16:02 <stefanh> slides, look at slide 2
17:16:05 <dom> Topic: Candidate Warmup
17:16:10 <jesup> justin and martin discussed using this as a way to have "warm" candidates ("too cunning" per martin, but interesting)
17:16:32 <dom> -> http://www.w3.org/2011/04/webrtc/wiki/images/f/fd/Telco-2012-12-13-Candidate_warm_up-1.pdf Candidate Warmup slides
17:16:34 <stefanh> ...prewarmed candidates can make things faster
17:16:47 <stefanh> ....but you don't always know how many to gather
17:16:57 <stefanh> ...slide 3: this was proposed in lyon
17:17:20 <stefanh> ...discussed a bit on the list
17:17:47 <stefanh> ...not possible to know what m-lines the candidates belong to
17:18:11 <stefanh> ...pc can look at them and add to remote pool or ignore
17:18:40 <stefanh> ...reset pool to zero when local desc created
17:18:51 <stefanh> ...drop part on states
17:20:00 <stefanh> ekr: (scribe missed some issues)
17:20:21 <stefanh> ...preference: keep them in the pool but don't generate events
17:20:59 <stefanh> ...related q: pool, call createLocal, call oncandidate before or after
17:21:16 <stefanh> martin: you never know when the offer will be set
17:21:56 <stefanh> cullen: when i pool, but not used, can I see them in the stats api?
17:22:20 <stefanh> martin: probably not
17:22:25 <stefanh> cullen: should be
17:22:33 <stefanh> hta: yes you would get them
17:22:47 <stefanh> justin:need to indicate that they are not used
17:23:14 <stefanh> ekr: interaction pool-creatO-xxx
17:23:50 <stefanh> ...candidates disappear
17:24:17 <Zakim> -fluffy
17:24:22 <stefanh> hta: there issues with doing them after create offer
17:24:55 <stefanh> martin: supress events until after createOffer
17:25:09 <stefanh> (many agreeing)
17:25:24 <stefanh> jim: change name of setting
17:25:35 <fluffy> +1 jim
17:25:40 <stefanh> martin: great idea
17:25:51 <stefanh> ...will send an email
17:26:21 <stefanh> ...no need to change ice states
17:26:57 <martin> I'm going to go with preGatherCandidates : nonNegativeInteger
17:27:04 <stefanh> hta: anyone read DTMF?
17:27:15 <stefanh> ...ok to insert in spec?
17:27:35 <stefanh> cullen: no, I don't object, seems workable
17:28:04 <martin> I just read the proposal.  I like it.
17:28:05 <stefanh> Decision: editors will insert DTMF api in the Editor's draft
17:28:09 <jesup> jesup read it as well
17:28:38 <stefanh> Dan: did we decide on not-fifo
17:28:49 <stefanh> martin: what we have is workable, put it in
17:29:13 <jesup> Agree with martin we should insert it
17:29:16 <stefanh> justin: detailed questions on when DTMF would work
17:29:28 <stefanh> (I think this should go in too)
17:29:46 <stefanh> hta: canInsertDTMF attribute
17:29:54 <stefanh> ...can change during session
17:30:15 <stefanh> ...insertDTMF method on dtmf sender
17:30:35 <stefanh> ...associated with correct track at creation time
17:30:56 <stefanh> More discussion needed on stats API
17:31:15 <dom> i/hta: anyone/Topic: DTMF
17:31:20 <dom> RRSAgent, draft minutes
17:31:20 <RRSAgent> I have made the request to generate http://www.w3.org/2012/12/13-webrtc-minutes.html dom
17:31:24 <stefanh> cullen: you can always create the sender
17:31:34 <stefanh> dan: can the sender go away?
17:31:49 <dom> Chair: HTA, stefanh
17:31:52 <stefanh> justin: no, can't go away even if it can't send
17:32:12 <stefanh> justin: add example to DTMF
17:32:21 <stefanh> ACTION add dtmf example
17:32:21 <trackbot> Sorry, couldn't find add. You can review and register nicknames at <http://www.w3.org/2011/04/webrtc/track/users>.
17:32:23 <hta> Action HTA: Add an example to the proposal.
17:32:23 <trackbot> Created ACTION-78 - Add an example to the proposal. [on Harald Alvestrand - due 2012-12-20].
17:32:30 <dom> i/next on the agenda/Topic: WebRTC States
17:32:35 <dom> RRSAgent, draft minutes
17:32:36 <RRSAgent> I have made the request to generate http://www.w3.org/2012/12/13-webrtc-minutes.html dom
17:32:53 <Zakim> -ekr
17:33:09 <Zakim> -gmandyam
17:33:10 <Zakim> -stefanh
17:33:12 <dom> Zakim, list attendees
17:33:12 <Zakim> -adambe
17:33:12 <Zakim> -hta
17:33:12 <Zakim> -Milan_Patel
17:33:12 <Zakim> As of this point the attendees have been hta, stefanh, dom, +46.1.07.14.aaaa, jesus|laptop, +1.408.902.aabb, Milan_Patel, Dan_Druta, +972.9.957.aacc, [IPcaller], fluffy, gmandyam,
17:33:12 <Zakim> ... adambe, +1.650.678.aadd, [Mozilla], ekr, tuexen, +33.6.85.56.aaee, JeromeMarcon, +1.267.934.aaff, jesup, Jim_Barnett, +1.972.999.aagg, +44.190.881.aahh, +1.425.893.aaii,
17:33:13 <Zakim> ... juberti, +33.7.88.18.aajj, +91.22.39.14.aakk, Dan_Burnett
17:33:13 <Zakim> -Dan_Druta
17:33:13 <Zakim> -juberti
17:33:13 <Zakim> -[Mozilla]
17:33:14 <Zakim> -tuexen
17:33:14 <Zakim> -jesup
17:33:14 <Zakim> -Dan_Burnett
17:33:14 <Zakim> -[IPcaller]
17:33:15 <Zakim> -Jim_Barnett
17:33:15 <Zakim> -dom
17:33:15 <Zakim> - +33.7.88.18.aajj
17:33:16 <Zakim> -JeromeMarcon
17:33:16 <Zakim> - +1.972.999.aagg
17:33:17 <dom> RRSAgent, draft minutes
17:33:17 <RRSAgent> I have made the request to generate http://www.w3.org/2012/12/13-webrtc-minutes.html dom
17:33:17 <Zakim> - +44.190.881.aahh
17:33:20 <Zakim> - +1.267.934.aaff
17:36:28 <Zakim> -??P53
17:37:04 <Zakim> - +91.22.39.14.aakk
17:37:32 <jesup> jesup has left #webrtc
17:42:04 <Zakim> disconnecting the lone participant, fluffy.a, in Team_(webrtc)16:01Z
17:42:05 <Zakim> Team_(webrtc)16:01Z has ended
17:42:05 <Zakim> Attendees were hta, stefanh, dom, +46.1.07.14.aaaa, jesus|laptop, +1.408.902.aabb, Milan_Patel, Dan_Druta, +972.9.957.aacc, [IPcaller], fluffy, gmandyam, adambe, +1.650.678.aadd,
17:42:05 <Zakim> ... [Mozilla], ekr, tuexen, +33.6.85.56.aaee, JeromeMarcon, +1.267.934.aaff, jesup, Jim_Barnett, +1.972.999.aagg, +44.190.881.aahh, +1.425.893.aaii, juberti, +33.7.88.18.aajj,
17:42:08 <Zakim> ... +91.22.39.14.aakk, Dan_Burnett
17:43:32 <dan_romascanu> dan_romascanu 972-99 ...
17:43:52 <dan_romascanu> +972.9.957.aacc
17:55:19 <jib> jib has left #webrtc
17:55:52 <tuexen> tuexen has left #webrtc
18:04:48 <ekr> ekr has joined #webrtc
18:09:45 <hta> hta has left #webrtc
19:33:35 <Zakim> Zakim has left #webrtc
20:30:57 <AdamRoach> AdamRoach has left #webrtc
20:31:57 <mreavy> mreavy has left #webrtc
22:00:36 <jeffh> jeffh has joined #webrtc