Web Real-Time Communications Working Group Teleconference

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

<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> Justin's slides

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 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 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> Candidate Warmup slides

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