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]