IRC log of webrtc on 2012-12-13
Timestamps are in UTC.
- 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