[minutes] Dec 13 teleconf

Hi,

The minutes of our teleconf today are available at:
http://www.w3.org/2012/12/13-webrtc-minutes.html

and copied as text below.

Dom

       Web Real-Time Communications Working Group Teleconference

13 Dec 2012

   [2]Agenda

      [2]
http://lists.w3.org/Archives/Public/public-webrtc/2012Dec/0033.html

   See also: [3]IRC log

      [3] http://www.w3.org/2012/12/13-webrtc-irc

Attendees

   Present
          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, [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,
          +91.22.39.14.aakk, Dan_Burnett

   Regrets
   Chair
          HTA, stefanh

   Scribe
          stefanh

Contents

     * [4]Topics
         1. [5]WebRTC States
         2. [6]Candidate Warmup
         3. [7]DTMF
     * [8]Summary of Action Items
     __________________________________________________________

   <hta> check
   [9]http://www.w3.org/2011/04/webrtc/wiki/Teleconferences for
   document links

      [9] http://www.w3.org/2011/04/webrtc/wiki/Teleconferences

   <scribe> scribe: stefanh

   hta: agenda first

   approve minutes from last meeting

   scribe: ok, minutes approved

WebRTC States

   next on the agenda: Justin and states

   <dom> [10]Justin's slides

     [10]
http://www.w3.org/2011/04/webrtc/wiki/File:Telco-2012-12-13-States.pdf

   Justing: continuation of conv in Lyon
   ... capture the discussion in proposed changes
   ... RTCPeerState
   ... could be named signaling state instead
   ... readyState similar to WS really
   ... app gets notified about changes via statechange callback

   <jesup> I agree on name change since it doesn't match the
   "common" cross-api readyState

   Justing: state removed
   ... changed names in sentOffer/Answer
   ... prAnswer missing from eds draft
   ... next slide shows update
   ... no "new" state

   Martin: question on a transtion
   ... list should be updated to make this clearer

   Justin: will fix this and update names

   <jesup> name_change++

   <dom> +1 on rtcsignalingstate and signalingState accessor

   Decided to change name to RTCSignalingState,
   onsignalingstatechange

   <jesup> ekr and hta also agreed with name change

   Justin: carrying on to ICE states
   ... change gathering state name
   ... RTCICEGatheringstate ICEGatheringstate
   ... no explicit callback, find out via null ice callback
   ... can also poll to find out state
   ... moving on to ICEConnection state
   ... prev called ICEstate, to change to ICEconn...state
   ... ICEconnectionstate seems to be preferred

   Everyone seems happy with name changes

   Justing: getting rid of starting state, go directly to new
   state
   ... next slide updated based on disc in Lyon
   ... details of transitions, time-outs,
   ... look at slides

   Justin: when would you change from connected to completed for
   the control side?
   ... updated offer not usable as originally thought

   Cullen: when the candidate list to receive was empty

   Ekr: confusing concept

   Justin: not clear when

   Ekr: is this important?

   Cullen: yes, then you know things are stable (jitter buffers
   can settle and so on)
   ... important to know in JS. Now you know things are as good as
   they will be

   Justin: When swapping from TURN to direct, is this a case

   Cullen: yes, and knowing stats will not get better

   Ekr: I'm not sure we need this

   Cullen: this is another thing
   ... let's discuss if we need to know when ICE state machine is
   done

   Justin: very hard to know at controlling side

   Cullen: fair enough

   Ekr: when can control side abandon candidates is the minimum to
   know

   Cullen: this stuff is very unclear in spec (RFC presumably
   meant)

   Ekr: need to know when we can free up turn server resources

   Tim: is this not when you stop sending indications

   Justin: not strong enough signal for this
   ... no clear way for control side to know other side is done

   Cullen: need to go look in the ICE spec

   Ekr: refering to ICE spec
   ... difficult

   Cullen: nothing in offer saying ICE is done

   Justin: can't solve here
   ...ACTION: sort out if we can know when going to finished

   Ekr: need to solve this

   Martin: Use renogitationneeded and send a new offer

   hta: who can take on this?

   ACTION justin to drive proposal

   <trackbot> Created ACTION-75 - Drive proposal [on Justin Uberti
   - due 2012-12-20].

   (speculation on solutions)

   (between a few people)

   Justin: any other comments?
   ... Question on ICE restart chaning states
   ... ICE restart not described before
   ... proposal to use constraints with createOffer/Answer
   ... get an SDP with new ufrag passwd
   ... signaled, and ICE restarts

   Martin: implicit creation of ufrag passwd in this situation?

   Justin: yes use that as trigger, leaning towards implicit

   Martin: App assumed not to be allowed to change ufrag/passwd,
   but this might not be true

   Ekr: seeems like an othogonal question
   ... prefer explicit indicator
   ... reading the slide: (scribe losing track)

   Justin: setLocal triggers ICE restart on local side

   <martin> ekr: we're continuing the invariant that setRemote
   doesn't do very much

   Ekr: What will happen, will user experience a pause

   <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

   ekr: when can I completely cut over

   justin: unsolved
   ... weird edge cases
   ... original conn can come back up

   martin: go to completed when on the new flows
   ... go to new flow as soon as connected

   justing: will create new slides and examples

   cullen: use make before break to make sure nice experience

   martin: what happens when new flow fails and old one coems back
   ... chanse to revive

   <hta> ACTION: juberti to create a specific example of cutover
   after an ICE restart. [recorded in
   [11]http://www.w3.org/2012/12/13-webrtc-minutes.html#action01]

   <trackbot> Created ACTION-76 - Create a specific example of
   cutover after an ICE restart. [on Justin Uberti - due
   2012-12-20].

   <martin> a truth table with the different states might help

   Ekr: maintaining several connections at the same time
   ... feature needed to have?

   cullen: would be nice, to keep both a WiFi and a 3G connection
   at the same time

   ekr: how does this work with signaling and ice restart?
   ... what are the mechanics

   justin: need to look into ice mobility stuff
   ... keep existing connections during restart
   ... preserve media flows

   <martin> I'd like to recommend that if we want this feature, we
   go to mmusic

   hta: moving toward "nice to have", let's move one

   ekr: trickle ice during connection completed to update

   cullen: would go back to connecting

   hta: ice restart useful for rehydration

   justin: ice restart throws candidates away - gives clean slate

   adambe: if someone told me to use ice restart, i'd use
   updateice
   ... more natural to have ice restart in update

   justing: more natural to do via existing signaling mechs
   ... change name to make this more clear

   adambe: that was my thinking

   Andy: q on ice restart constraint: can media be added in
   conjuction?

   justin: should be possible
   ... should be OK

   Andy: some comments re jsep on that

   justin: now rollback
   ... to make clear: drive signaling state backwards
   ... if other side does not want to do what's in offer
   ... roll back to stable state
   ... also if a new offer meaning that previous should be ignored

   martin: easy to explain and implement
   ... rejection on an offer would often be based on what the
   offer contains, so after setting offer you need to back

   justin: easy to implement. More difficult in a prAnswer case,
   relaed to crypto keys
   ... not clear how media can be decoded with new and old key

   cullen: need to nail down what happens to media during
   transition states
   ... what media is received, what is transmitted

   <martin> it's more than just media, justin's comment about DTLS
   negotiation is an interesting one to think on

   <ekr> I tuned out for a minute. Can you repeat?

   justin: existing and new media descriptions must be handled

   martin: pranswer can be replaced to a stage where is does not
   contain anything

   cullen: when we figurre out what we want to do in non
   provisional cases the provisional ones will be easy

   randell: agree to cullen and marting.
   ... need to cover that version, martin gave one, need more
   ... may not be as hard as i make it up to be

   cullen: do non-prov first

   martin: on offer side prAns does not do a lot
   ... don't worry that much about media

   justin: disagree on this
   ... pranswer has all cap of an answer

   hta: still not fully clear on rollback reqs

   justing: haveRemote / haveLocal to stable rollback
   ... first, do prStuff later

   cullen: would like us to come to prStuff as well
   ... but do basic thing first
   ... and next layer after that

   justin: api
   ... a couple of ways.

   <martin> RTCSessionDescription.ROLLBACK constant might make
   this one easier to write code for

   justin: method, setL/R with session desc "rollback", setL/R
   with null
   ... programming errors could trgger a rollback if we use "null"
   ....conclusion: prefer setL/R with rollback session desc

   cullen: sdp can get out of sync. JS and UA have different
   understanding about what to roll back to

   justin: can supply the sdp we're rolling back to
   ... fragile if wrong sdp is supplied

   dan: i like supplying the sdp rolling back to
   ... the only way to can know is to supply the description
   ... like that idea

   cullen: but you can always get what you rolled back to

   dan: you can find out you rolled back to the wrong state

   hta: equavelent to record the sdp beforehand

   martin: the UA can keep track of the descriptions, app can
   check
   ... which one you'd roll back to
   ... constant on rtcsessiondesc (essentially justin number two)
   ... constant describe type of rollback

   cullen: why not just make a new method

   <jesup> zakim: randell is jesup

   ekr: option two allows rollback without app intervention

   cullen: come around to number two with martins addition

   Jim: can you go back several steps?

   justin: no

   <ekr> recording martins proposal: justin's proposal #2 plus
   explicit accessors for current and expected SDP states

   martin: becomes a bit odd in certain situations

   justin: see what you mean
   ... we may be overdesigning

   martin: lets do basic first, next pranswer

   justin: slide 11 overview o what rollback does

   (refer to slide for details)

   <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.

   cullen: seems good, dislike phrasing "move state back"

   hta: adjust later

   <ekr> I tend to agree with cullen that "one state back" is
   creepy

   <ekr> especially since there are cases we can't roll back from,
   e.g., stable

   cullen: need to roll back to a specific state

   <scribe> ACTION: cullen to use case for rollback [recorded in
   [12]http://www.w3.org/2012/12/13-webrtc-minutes.html#action02]

   <trackbot> Created ACTION-77 - Use case for rollback [on Cullen
   Jennings - due 2012-12-20].

   <martin> that use case might drive us toward a different API
   surface

   justin: last slide
   ... situatins when gathering will be stopped and candidates
   abandoned
   ... can be used for getting pool candidates actually
   ... some things can not be fully rolled back
   ... remove stream for example

   hta: covered this topic
   ... settled on a proposal on local/remote offer state, will
   look at other state later

   switch to candidate warmup session

Candidate Warmup

   martin:

   slides, look at slide 2

   <jesup> justin and martin discussed using this as a way to have
   "warm" candidates ("too cunning" per martin, but interesting)

   <dom> [13]Candidate Warmup slides

     [13]
http://www.w3.org/2011/04/webrtc/wiki/images/f/fd/Telco-2012-12-13-Candidate_warm_up-1.pdf

   martin: prewarmed candidates can make things faster
   ... but you don't always know how many to gather
   ... slide 3: this was proposed in lyon
   ... discussed a bit on the list
   ... not possible to know what m-lines the candidates belong to
   ... pc can look at them and add to remote pool or ignore
   ... reset pool to zero when local desc created
   ... drop part on states

   ekr: (scribe missed some issues)
   ...preference: keep them in the pool but don't generate events
   ... related q: pool, call createLocal, call oncandidate before
   or after

   martin: you never know when the offer will be set

   cullen: when i pool, but not used, can I see them in the stats
   api?

   martin: probably not

   cullen: should be

   hta: yes you would get them

   justin: need to indicate that they are not used

   ekr: interaction pool-creatO-xxx
   ... candidates disappear

   hta: there issues with doing them after create offer

   martin: supress events until after createOffer

   (many agreeing)

   jim: change name of setting

   <fluffy> +1 jim

   martin: great idea
   ... will send an email
   ... no need to change ice states

   <martin> I'm going to go with preGatherCandidates :
   nonNegativeInteger

DTMF

   hta: anyone read DTMF?
   ... ok to insert in spec?

   cullen: no, I don't object, seems workable

   <martin> I just read the proposal. I like it.

   Decision: editors will insert DTMF api in the Editor's draft

   <jesup> jesup read it as well

   Dan: did we decide on not-fifo

   martin: what we have is workable, put it in

   <jesup> Agree with martin we should insert it

   justin: detailed questions on when DTMF would work

   (I think this should go in too)

   hta: canInsertDTMF attribute
   ... can change during session
   ... insertDTMF method on dtmf sender
   ... associated with correct track at creation time

   More discussion needed on stats API

   cullen: you can always create the sender

   dan: can the sender go away?

   justin: no, can't go away even if it can't send
   ... add example to DTMF

   <hta> ACTION: HTA to Add an example to the proposal. [recorded
   in
   [14]http://www.w3.org/2012/12/13-webrtc-minutes.html#action03]

   <trackbot> Created ACTION-78 - Add an example to the proposal.
   [on Harald Alvestrand - due 2012-12-20].

Summary of Action Items

   [NEW] ACTION: cullen to use case for rollback [recorded in
   [15]http://www.w3.org/2012/12/13-webrtc-minutes.html#action02]
   [NEW] ACTION: HTA to Add an example to the proposal. [recorded
   in
   [16]http://www.w3.org/2012/12/13-webrtc-minutes.html#action03]
   [NEW] ACTION: juberti to create a specific example of cutover
   after an ICE restart. [recorded in
   [17]http://www.w3.org/2012/12/13-webrtc-minutes.html#action01]

   [End of minutes]

Received on Thursday, 13 December 2012 17:44:39 UTC