W3C home > Mailing lists > Public > public-webrtc@w3.org > November 2012

[minutes] WebRTC F2F Oct 29-30

From: Dominique Hazael-Massieux <dom@w3.org>
Date: Thu, 15 Nov 2012 11:37:06 +0100
Message-ID: <1352975826.7033.183.camel@cumulustier>
To: public-webrtc@w3.org
Hi,

I've just finished compiling and cleaning up the draft minutes of our
F2F meeting two weeks ago at TPAC:
http://www.w3.org/2012/10/29-webrtc-minutes.html
http://www.w3.org/2012/10/30-webrtc-minutes.html

The minutes of the Media Capture Task Force meeting on the afternoon of
October 30th will be send separately to the media capture task force
mailing list.

Please send corrections as needed; text-only copy of the minutes
embedded below.

Dom

       Web Real-Time Communications Working Group F2F

29 Oct 2012

   See also: [2]IRC log

      [2] http://www.w3.org/2012/10/29-webrtc-irc

Attendees

   Present
          andy_hutton, adambe, hta, stefanh, derf, burn,
          dan_druta, richt, anant, dom, juberti, jim, matthew,
          ekr, fluffy, Magnus

   Regrets
   Chair
          Harald, Stefan

   Scribe
          adambe, markus, JimB, martin

Contents

     * [3]Topics
         1. [4]API functionalities missing in PeerConnection API
         2. [5]SDP handling
         3. [6]Implementation status
         4. [7]General error handling principles
         5. [8]Call flows Walk-through
         6. [9]State machines
     * [10]Summary of Action Items
     __________________________________________________________

   <inserted> scribenick: adambe

   hta: the best use of face-to-face time is to be specific
   ...: people pay more attention campared to mailing lists
   ... we've tried to make the agenda specific
   ... we might go with presenters proposal
   ... there also be discussions
   ... we should record off-topic topics and move them to the AOB
   session

   stefanh: fist session is about API functionality we haven't
   addressed yet
   ... this might be the least concrete item on the agenda
   ... what de we need to do now and what can we postpone

API functionalities missing in PeerConnection API

   [11]Stefan's slides

     [11] http://www.w3.org/2011/04/webrtc/wiki/images/1/1e/MoreAPIs.pdf

   stefanh: API topics
   ... width, hegiht sent over a PeerConnection
   ... priority
   ... is media flowing?
   ... how much bandwith is used
   ... how much can be used
   ... how to reject media streams
   ... echo control
   ... one thing missing on the slides
   ... should we support security descriptions

   (a use case is presented)

   scribe: one peer sends video with two different resolutions to
   two other peers
   ... are people ok with this?

   fluffy: we should support this

   burn: you're showing the entrence and the consumer side

   stefanh: yes

   hta: there are multiple ways to achive this reuslt
   ... first question is.. do we need to support this?
   ... the answer is yes
   ... then how should we solve it

   stefanh: this is the most difficult slide in my deck
   ... application knows about the receiving side
   ... or the receiving side could tell the sender
   ... third possibilty is that the app isn't involved

   matthew: even if the receiver is involved the sender needs to
   be involved

   justin: there needs to be some higher limit

   matthew: there might be a lot of contstraints

   fluffy: this is one of the reasons we need constraints

   stefanh: we shouldn't modify the sdp unless we have very good
   reasons

   hta: we currently don't use a speakers queue

   ekr: what do we expect to happen if the receiver asks for a
   different aspect ratio
   ... should the PeerConnection rescale
   ... ?

   justin: the sender might need to chose the closest thing

   hta: we want people to separate the case where you really
   require something compared to the case where you really can't
   live without something

   <matthew> side comment: generally we either need to fully
   specify the SDP the is used to negotiate things like this OR we
   need contraints. unfortunately when there's contraints, we
   *also* need to fully specify the SDP that flows between them...
   unless we choose to have it *only* be an API issue ("direct
   manipulation" vs. "constraint setting")

   stefan: is the sending app or sending PeerConnection informe

   justin: information about the consumer dimensions could be sent
   as a session description

   fluffy: the connection to the video tag is interesting
   ... would it be reasonable to adjust the send size to the
   consumer size?
   ... this was a driver for renegotiation callback

   martin: you don't have the consumer in the initial negotiation

   fluffy: it's not always true

   derf: css also impacts this

   fluffy: a video tag might be specified with a size or not

   stefanh: there could be several video tags that wants to affect
   the sender side

   hta: there's a ultimate fallback video size

   burn: smart browsers might behave differently

   matthew: smart browser decisions must be overidden if the
   developer wants to do something else

   burn: if we have an API then the browser must take input from
   the API into account... otherwise the browser can do its magic

   stefanh: what is the conclusion?
   ... the receiving side can influence, but we also need an API
   to let the developer tweak

   ekr: do we want information from the receiver to bubble back
   all the way to the camera on the sender side?

   burn: a browser can use any valid value in a contraint range

   matthew: if several consumers (local, remote).. who wins?

   ekr: some constrains are enforced when set and some constrains
   seems to be enforced continiously

   burn: we might need a constraints that says "do not change
   video size"

   stefanh: recap on proposed conclusion
   ... receiving side as driver with an API for the app to
   influence

   matthew: there's two ways to implement this

   fluffy: we don't know if we'll use RTCP or SDP to negotiate
   video size

   matthew: even if we go with RTCP we need an API to influence
   how the browser should behave

   stefanh: let's move on
   ... next slide
   ... if the receiver detaches a stream from the consumer.. what
   should happen,
   ... ?

   ekr: what if sender offers something that the receiver doesn't
   want?

   stefanh: we'll get to that in a later slide

   fluffy: we have two operations.. mute (undetectable from the
   sender side) and to say "don't send me packets"

   justin: how do you say that I only want a subset of the offered
   set of streams
   ... we don't have a good way to express that today

   stefanh: next slide
   ... requeseting a certain bandwith
   ... there's an IETF draft talking about this

   DanD: I propose a priority param to addStream()
   ... we can discuss how the priority information should be
   handeled but we should decide on a mechanism to specify the
   intent

   stefanh: addStream() is only called once per stream, it's a
   problem

   DanD: we're the right group to specify the priority intent

   burn: intent means it might not happen

   <martin> hmm...s/constraint/pref/g ?

   <ekr> ?

   <martin> that works too

   <matthew> there's a difference between "preferences" and
   "absolute limits"

   <matthew> i "prefer" 720P, but there's no way i ever want >2560
   horizontal pixels

   <burn> no, constraint != intent

   DanD: at least the browser sholud be able to say that I marked
   you packets in a certain way

   <burn> intent == hint, discussions about hints lead to a
   decision to support both mandatory and optional constraints

   <matthew> if you just go with direct manipulation then the API
   only has "settings", and the difference between "constraint"
   and "preference" is JS code

   <matthew> but the moment you let the two ends talk to each
   other via possibly-unmodified SDP blobs then you need places on
   the monster where it can be poked with a stick

   Göran: we should describe this case in more detail

   scribe: can the network trust the diff-serv code points set by
   the app

   fluffy: in some environment you can't
   ... they might provide information
   ... but a separate request is needed to verify

   Göran: we need more discussion around use cases

   fluffy: I think this should be a topic for the AoB section

   (people agree)

   hta: new topic - Security for Qos flow labels

   ekr: there might be two API surfaces needed: tie constraints to
   media flow, (missed the other one)

   DanD: I wan't a request that should be handeled by the trusted
   environment

   matthew: even if diff-serv cps isn't supported a system may
   enforce priority anyhow (we need to support this case as well)

   hta: new topic for AoB - Control of the DSCP interface

   stefanh: next slide
   ... other side of the same coin
   ... feedback on bw..

   martin: I thin we need generic feedback on constraints set
   ... there might be existing mechanisms
   ... for others we might need to add something

   matthew: e.g., if video has highter priority over slides, the
   app might want to know if the slides can't be sent at all

   stefanh: next slide
   ... sender side pause/resume
   ... we currently have enable/disable on MediaStreamTrack
   ... every consumer is affected
   ... we could have enabel/disable on PeerConnection

   burn: we don't need that since you could clone media streams

   hta: we implemented enable and disable as affecting the
   associasion between a stream and track

   stefanh: next topic, AGC

   fluffy: the text on the slides looks good to me

   <martin> conclusion here was that we don't need to prioritize
   the agc/noise settings, it's not a preference, it's a setting

   <martin> it might also be necessary to change this on the fly

   burn: what happens if you turn AGC on and it's not available

   fluffy: it should be a on/off setting

   derf: I hope there's a way to enumerate settings

   <martin> we need a way to enumerate settings, for sure

   fluffy: we should require that

   <martin> agc/noise is a property of a track

   hta: AGC should be on track level

   stefanh: next topic
   ... rejecting streams

   martin: we need to know if multiple streams are offered
   ... we need basic methods on the session description

   derf: example: you offer me 10k streams.. how do I reject

   DanD: it's not only if your device can do something.. there's
   also a question if your service can support this

   martin: we need to know what you get before you can say what
   you want to accept

   hta: if we have a mechanisms for the receiver to turn off a
   stream at any point.. would it be sufficient to turn it off
   rather than not accepting it?

   matthew: it might be a resource question

   ekr: I interpret it as: you set the remote description and you
   see what streams are offered

   stefanh: is the sending app informed about a rejected streams
   ... ?

   hta: if the use case for rejecting streams is to save resources
   then the sender needs to know

   matthew: it's important how quickly can this be done

   fluffy: can someone send a proposal to the list?

   (I missed to scribe a lot of stuff while I was talking)

   stefanh: next thing - AEC

   fluffy: one param you need is what's going to the speakers

   <martin> new issue that is related to this, and one that I will
   bring up later when we talk about this: SDP describes RTP
   sessions. The one m= section can have multiple tracks. How do
   we learn of these other than just waiting for arrival of
   packets on one of those?

   <hta> adambe said: I sent a proposal to the list with inbound
   and outbound streams as different objects, which might make
   this discussion easier; missed having feedback on that.

   <matthew> another issue that's related to the last slide and
   not yet decided (and different in different implementations) is
   what to offer/send before user consent on a sending device
   occurs. one approach is to say "recvonly" and change to
   "sendrecv" when the consent happens, the other is to say
   "sendrecv" and send muted audio + black video until consent is
   received. recvonly->sendrecv takes the extra round trip to
   enable.

   (scribe is missing a lot of stuff here)

   burn: why do we need API for this?

   fluffy: you might want to turn it off

   burn: could this be a browser control?

   someone: music is a use case where you wan't to turn EC off

   matthew: broadcast is also a use case where you want to turn
   AEC off

   martin: if the browser and user wants differents things, the
   user setting should win

   stefanh: final slide - SDES
   ... wait until RTCWeb has discussed this

   ekr: yes

   stefanh: that was easy
   ... summary slide

   martin: you could get two different tracks - one with AEC and
   one without

   hta: new AoB (MC TF) to topic - Multiple open of camera/mic?

   martin: AGC, NR should be fairly simple

   burn: rather than doing this right now we should sumarize what
   we have decided the last hour and update the summary

   hta: there are things that needs to be discussed and some that
   just can be edited in

   Acoustic Echo Cancellation

   stefanh: we're 15 minutes before schedule

   <markus> coffee break

   <hta> anyone remote actually here?

SDP handling

   [12]Cullen's slides on SDP handling

     [12]
http://www.w3.org/2011/04/webrtc/wiki/images/2/2d/RTCWeb-SDP-API_v6.pdf

   <markus> getting started, markus is the scribe

   <markus> fluffy showing slides

   issues: what SDP do createOffer and createAnswer create and how
   they can be manipulated before passing them back to the browser

   matthew:some changes are ok from SDP syntax perspective but not
   for the browser to act upon

   goals: clear definition of SDP and error handling rules

   how are new ICE candidates added to the set SDP

   Matthew: when I ask which SDP is in use is it the one I have
   set or can it be something slightly different?

   constraints: can be used to enable common use cases, but do not
   solve what can be changed

   burn:constraints can affect what SDP gets generated in the
   first place so it does not need to be modified anymore

   fluffy: the place to define SDP use is in the JSEP draft -
   latest draft has a start

   <AndyHutton> remote audio not working

   matthew:state transitions need to be taken into account, can't
   call everything multiple times

   <matthew> specifically, setRemoteDescription("answer") is
   restricted to only-call-once even though we are saying that
   enforcement of these transitions is up to the JS

   what can be changed between create* and setLocal/Remote

   use cases: remove codec, change bw limit etc.

   justin: enable/disable bundle is one case

   adam:rejecting audio, getting video - is that with munging SDP?

   fluffy:no, if we have explicit API then don't use SDP mungling

   matthew:have a detailed set of cases

   fluffy:grouping of cases:

   fluffy:don't do RTCP mux via settings, not SDP

   matthew:ptime for codecs

   matthew:want to fix it

   matthew:will take my cases to the list

   [several people agree most things being discussed should be
   done via other mechanisms than changing SDP]

   burn: nervous about limiting too much what in SDP can be
   modified

   fluffy:changing SDP on the way between browsers can be done
   flexibly, changing between create* and set* in the same browser
   more limited

   justin:don't understand why there is big difference between
   different manipulation "loops"

   fluffy:positive list of what can be changed is needed, not the
   list of what can't be

   provide a list of changeable things that is *guaranteed* to
   work

   matthew: errors need to be specific on what is wrong

   [argument over what the current spec (JSEP?) says...]

   burn: many kinds of modifications will be needed before sending
   SDP out

   burn:what you send out does not match with what you set with
   setLocal?

   <ekr> who was speaking?

   matthew:jsep-02 has fixed the ice password issue

   fluffy:need to have the use cases that motivate changes

   justin:needs coming up in the future anyway...

   how much and what state does createOffer create? devices with
   HW codecs?

   <matthew> jsep-02 fixed the "createOffer is optional" language,
   though whether or not createOffer creates state is true or not
   is questionable

   <ekr> matthew: though, there's clearly an implication of that
   b/c of the validity window of the offer.

   <ekr> i.e. during the callback.

   <matthew> indeed

   martin:set down the list of things that MUST be possible to
   change

   burn:is everything else MUST reject?

   people have different interpretations...

   explicit list of things that MUST be changeable, explicit list
   of things that MUST not be changed and what falls in between
   the browser need to explicitly error report if it won't support
   it

   <martin> there is a list of things that we MUST be able to
   change; there is a list of things that MUST NOT be able to
   change, which trigger an error; everything else the browser
   MUST either accept or reject with an error

   <matthew> silent failure is incompatible with the assert on the
   2nd slide. either the browser fires an error (invalidating the
   assert) or it is lying to you in order to make that assert.

   [the above three comments (markus, martin, matthew) try to
   record the consensus in the meeting]

   AndyHutton: Configuration/settings? how do they relate to the
   MUST, MUST NOT, ...

   fluffy:start with the list of use cases to get the
   MUST-be-changeable list

   matthew:listing MUST-items...

   [cullen taking notes...]

   adam: we will have APIs for some of these things anyway

   fluffy:if we have an API to control what createO/A gives, is
   that not enough, do we still need to change SDP for those
   "features"

   justin, matthew: there may be cases where SDP change is still
   needed

   fluffy: use cases are still not clear

   burn:do not worry about MUST-list anymore because anything on
   the MUST NOT list can still work...

   still sensing consensus on having three lists: 1. MUST be
   changeable, 2. MUST NOT be changeable, 3. (default) Browser
   MUST give an error if it does not support it

   fluffy:next issue

   when can two different video flows use the same m-line

   Proposal: all codec parameters are the same, "content-label" is
   the same, are in same MediaStream

   (hta, fluffy, martin debate the details)

   next: How does createOffer know to offer receiveOnly flow?

   want to receive video but don't have video camera

   justin has a proposal, mind to write it down here?

   matthew: can you put "send" in SDP before getting user consent?

   or do you first have to use receiveOnly and add sendReceive on
   a separate O/A

   ekr: how do we correlate multiple offered video m-lines to the
   multiple video streams the answerer has

   next topic: how does createOffer decide to offer a data
   channel?

   should OfferToExchangeData constraint be added?

   matthew: data is a great idea, but SCTP is horrible.

   fluffy:take this to the IETF

   tim:SCTP was decided in Feb

   <ekr> matthew: how do you really feel about SCTP?

   DanD:data is easy within a single app, but trapezoid between
   two apps is more difficult

   martin:issues could come also if the other device running the
   "same" app has constraints

   consensus: don't add this constraint

   next: DTMF

   will be discussed tomorrow with a proposal

   next: How long is SDP from createOffer/Answer valid?

   matthew:90 seconds would be an ultimate timeout

   use case: the SDP is sent to the server for modification

   should it be valid beyond the duration of the callback function

   ice candidates etc. time out in matter of 10s of seconds

   hta: time-to-live for the session description?

   matthew:can createOffer be called again after getting the
   modified SDP back from the server?

   matthew:proposes that createAnswer is valid only for the
   duration of callback and no longer

   consensus: it must be valid at least for the duration of the
   callback function

   ACTION: ekr to take follow-up to the list

   slides about rollback and error handling left for now

   (now lunch break until 1:30)

Implementation status

   <fluffy> Cullen is scribing

   HTA is presenting what chrome is doing

   TURN and opus are scheduled to be in M24 all going well

   DTMF is waiting on this group

   Anant has a demo of firefox

   THe demo allows login, gives a list of users, then you can call
   one of the other users

   Have getusermedia, have peerConnection,

   expectation to not have behind a flag in firefox 19

   currently in firefox 18 in nightly builds behind a flag

   have a fairly complete version of the DataChannel

   showed cool file sharing with drag and drop using DataChannel

   THey have DTLS-SRTP

   ICE but no TURN

   prototype of Identity working

   Doing desktop first, then working on mobile

   VP8, opus, and G.711 as codecs

   HTA: There was a test web even 2 days ago

   dom: The idea of these is to get lots people to develop and
   contribute test cases

   … presentation of theory of testing

   … Event led to 404 test cases

General error handling principles

   ScribeNick: JimBarnett

   [13]Anant's slides on error handling

     [13]
http://www.w3.org/2011/04/webrtc/wiki/images/d/d1/TPAC_2012_WebRTC_error.pdf

   Anant: exceptions vs error callbacks. exceptions when you can
   detect error without blocking the main thread. Covers only very
   simple errors. In all other cases, error callback. So as
   policy, favor error callbacks because they don't block the main
   thread.

   Cullen: so lots of functions will do both?

   Anant: yes

   EKR: there's no way to get around exceptions occasionally.

   Tim: what do you do if you pass in something that is not a
   function as the error callback?

   Cullen: there are things that you should never see in
   production code, and those that have to be caught at runtime.
   The former are programming errors. We're interested in input
   errors.

   Anant: what goes in spec is a list of things that must be
   exceptions and what should be callbacks. This will be the
   result of consensus of browser implementations.

   Justin: so programming errors will be exceptions, bad SDP from
   the other side will be an error callback.

   Anant: exceptions will be only for development. They shouldn't
   occur in deployments at runtime. In exceptions should include
   name and message, which all platforms support We should
   standardize the names of exceptions, message can be
   platform-specific, thought should be human readable. stack and
   linenumber are useful where available. We will inherit from
   Error object to make SDPErrorObject.

   ekr: we should create new attribute for SDP error, rather than
   overloading linenumber.

   Anant: yes, having different names helps. We should standardize
   on the ones that need to
   be machine readable. Human-readable ones can be
   platform-specific.

   Dom: W3C policy is to re-use existing names as much as
   possible.

   Anant: we will use same object for error callback and
   exception. So name and message must be present in object passed
   to error callback. As with exceptions, human-readable
   properties can be platform-specific. For SDP errors may want to
   create a new property. Error callbacks should be mandatory. In
   current spec, they're optional. That makes it easy to make
   sloppy errors. If they're mandatory, at least you get an
   exception if you forget to define the error callback. It should
   never be the case that there's an error and nothing happens.

   ... In CreateOffer, exceptions: Invalid_callback,
   invalid_constraints, invalid_state.

   Dom: these can be webIDL type mismatch errors. We don't need to
   specify them separately.

   Anant: we can move invalid state to a callback (for cases where
   app violates the state machine that we define.) So we won't
   need to define any exceptions for (most?) functions. setLocal
   and setRemote can have invalid_sdp as error in callback. Assume
   that the success callback in set remote isn't called until the
   description has been fully applied.

   Cullen: if have setRemote with provisional SDP and then later
   will apply final SDP. Consider the case where are parsing SDP
   and acting on it as you go along. Do you have to roll back? It
   may be hard to do that.

   ekr: setRemote shouldn't generate callback until it's complete
   and in correct state.

   Justin: we need a separate error to signal case that media
   system is hopelessly busted.

   Cullen: we need two kinds of errors. Implementation will know
   whether the situation is
   hopeless or not.

   Harald: Invald SDP indicates that you have been able to
   rollback, so it's not fatal.

   Cullen: when SDP fails a syntax check and no state has been
   changed, as opposed to case where what you thought was a camera
   turns out to be a mouse.

   ekr: there are cases where the error is reversible, but you're
   still screwed.

   Harald: let's put Anant's proposal into the spec, and work out
   some of these details later.

   Anant: we can leave the decision on which errors are fatal to
   the UA. Further discussions of specific error cases on the
   list.

   Dan: are error callbacks mandatory?

   Dom: sloppy programmers can always put in a no-op error
   callback. On the other hand, if we make them mandatory, we will
   have to include them in our examples.

   RESOLUTION: ERROR CALLBACKS ARE MANDATORY. Anant to update
   spec.

   So decided that invalid_state will be a callback no exception

   <dom> [14]Error Types defined in DOM 4

     [14] http://www.w3.org/TR/dom/#error-types-0

   Decided that for SDP, will add a sdpLineNumber

   decided all errors callbacks will not be optional

Call flows Walk-through

   Justin: when you call setLocal that's when UA starts gathering
   ICE candidates. Get callbacks as each candidate is gathered,
   another when all are gathered. If call createOffer before any
   candidates are gathered, it will have just your local address.

   Justin: if you want to do trickle, have to get offer first and
   then gather candidates. So must get getOffer callback before
   all candidates are gathered.

   Cullen: what things can cause gathering to begin? What
   indicates how many candidates to gather? How do you know when
   you're done.

   Matthew: it has to be a settable parameter whether createOffer
   callback can fire before you have enough candidates to produce
   valid SDP. I don't like to get a success callback when the
   offer is not valid yet.

   Cullen: one model is you can decide to wait until SDP is
   complete. Or we can say that you get callback immediately, then
   get another when you have all the candidates.

   Harald: must have ICE candidates to be valid.

   Cullen: but local address suffices for validity.

   Justin: in Jingle can send offer without any candidates and
   it's fine.

   ekr: it won't work with SIP.

   Adam: we should have matching examples and callflows, including
   trickle.

   Stefan: the Chrome implementation seems to work, with and
   without trickle. So it should be our reference.

   Justin: we discussed calling createOffer and setLocal early to
   start allocation, and then add streams later

   Cullen: we don't have mechanism for declaring dummy streams.
   What if had new method: gather n candidates.

   Justin: that's like setLocal with empty m=lines.

   Cullen: calling app has pretty good idea of how many candidates
   it will need. At least an upper bound.

   ekr: two proposals for pre-allocation: - a direct instruction
   to peerconnection, or some sort of dummy SDP via createOffer
   and setLocal.

   Cullen: we have 6 issues to discuss, all at least as big as
   this.

   Harald: I'd like to get an overview of all the questions. for
   this issue, we have two questions: how to know when SDP is
   sendable, and how to do pre-allocation.

   Matthew: what happens with resource reservation? What happens
   when you do all this gathering and find out that the camera
   isn't available any more?

   Cullen: next issue. How does receiving side find out what's in
   the offer, so that it can show the user: Alice is calling and
   she wants audio and video.

   Matthew: when you call setRemote, you have no idea how many
   times onaddstream will be called.

   Cullen: general model is a callback for each structure, and a
   final callback saying that you won't get any more. questions:
   when do you know that you've gotten all mediastreams? When do
   you know you have all the tracks? When do the callbacks fire
   with respect to the setRemote callback?

   ekr: at what point do side effects take effect w.r.t the
   callback? I think it must be before.

   Justin: when does peerconnection.remotestreams get populated?
   When you get a stream, the tracks should be filled in already.

   Matthew: parse them into the array, and then call
   processingcomplete.

   Justin: how about a callback saying the remotestreams value has
   changed? (It would be an array value, so this callback would be
   called only once.)

   Adam: it's more convenient to get the new stream in the
   callback, rather than having to parse the array to see what's
   different.

   Justin: but it's important to know when the changes are
   complete, rather than getting changes one at a time.

State machines

   [15]Justin's slides

     [15]
http://www.w3.org/2011/04/webrtc/wiki/images/f/fa/WebRTC_States_v2.pdf

   <inserted> ScribeNick: martin

   juberti: [presenting on states]

   martin: does back to gathering happen for moving from "relay"
   to "all"?

   juberti: you probably already have all the necessary candidates

   matthew: is there any way to remove candidates?

   juberti: ice restart

   ekr: can we have multiple components with one completed and the
   other one with no candidates

   juberti: we are in checking until all components have resolved

   fluffy: checking encompasses frozen

   matthew: restart doesn't affect active flows

   juberti: yes

   matthew: why not just describe each of the states as they
   relate to the underlying states

   fluffy: this is part of what I prepared for the last call on
   this topic and we rejected that

   hta: there is no harm in playing audio while video is failing
   and restarting
   ... is there any difference betwen connected and completed?

   juberti: middleboxes might require the updated offer that would
   be triggered from the completed transition

   martin: is this application driven or not, can the browser add
   new candidates and contine?

   juberti: restart is required by RFC 5245

   fluffy: the application is going to need to be involved

   juberti: if you get a new NIC (e.g. WiFi) you might just
   trickle that

   hta: transitions to starting are tied to user actions

   martin: how does the new WiFi candidate fit into this?

   juberti: that would trigger a transition to connected

   fluffy: there is an implication that disconnected might
   transition to failed, in the case where you were connected and
   you disconnect then something failed

   juberti: proposes changing name of "starting" to "noo"

   <hta> IceConnectState -> IceConnectionState

   juberti: remove onicegatheringchange, and provide just
   onicecandidate to fire when the gathering state is changed

   derf: propose to rename iceConnectState to iceConnectionState
   or something

   * missed the name conclusion

   ekr: is this same as the other state machine, just with the
   states merged?

   juberti: yes

   <hta> martin, name conclusion was to use IceConnectedState
   rather than IceConnectState (I think - my ears are going)

   matthew: set...(answer) can't be done twice?
   ... why isn't createOffer and createAnswer shown on the
   diagram?

   juberti: once you set...(answer), you may have removed some
   critical state for the offer, which invalidates some of the
   answers

Summary of Action Items

   [End of minutes]

***************************************************************

   [1]W3C

      [1] http://www.w3.org/

       Web Real-Time Communications Working Group Teleconference

30 Oct 2012

   See also: [2]IRC log

      [2] http://www.w3.org/2012/10/30-webrtc-irc

Attendees

   Present
          andy_hutton, adambe, hta, stefanh, derf, burn,
          dan_druta, richt, anant, dom, juberti, jim, matthew,
          ekr, fluffy, Magnus

   Regrets
   Chair
          Harald, Stefan

   Scribe
          DanD, Juberti

Contents

     * [3]Topics
         1. [4]Identity
         2. [5]API for removing streams
         3. [6]DTMF
         4. [7]Other business
         5. [8]What Triggers Candidate Fetching
         6. [9]When is SDP sendable?
         7. [10]Security for QoS labels
     * [11]Summary of Action Items
     __________________________________________________________

   <trackbot> Date: 30 October 2012

Identity

   <dom> ScribeNick: DanD

   ekr presenting
   [12]http://www.w3.org/2011/04/webrtc/wiki/images/f/f2/Idp-issue
   s.pdf

     [12]
http://www.w3.org/2011/04/webrtc/wiki/images/f/f2/Idp-issues.pdf

   ekr: Three proposals on the list
   ... Proposal 1 - Identity provided by gUM (Thomson)
   ... Proposal 2: Prompt user after call (Ohlsson)
   ... Proposal 3 - Site permissions with identity display (EKR)
   ... Proposals 1 and 2 require the user to explicitly assent to
   identity

   fluffy: How does the person answering the call who's calling
   before answering the call?

   ekr: Long term consent

   Mathew: I like to setup the video selection and enable the
   camera and the identity makes it complicated
   ... easy to be done with proposal 1
   ... We need to make sure the browser does not get into the
   address book without user's consent

   hta: I'm not happy with proposal 2
   ... when the green light go on
   ... I have an origin that is not bound to an identity but later
   get's bound

   ekr: Proposal 4 is a hybrid of 1 and 3

   dom: I don't think we should use a null value for a parameter
   with a different meaning as a parameter not being set

   ekr: I'm happy to use a different parameter name for option3

   justin: There's a difference between site having access to the
   camera and site recording

   dom: We're focusing too much on the green light where mobile
   devices don't have a green light; I want to make sure we don't
   build security on top of hardware indicators that are not
   always available

   martin: the idea is to have an indicator in the chrome

   justin: there's confusion about what the green light means

   fluffy: we are adding to the confusion

   ekr: the green light (the indicator) is supposed to be on once
   the camera is accessed

   hta: there is a issue when applications via USB can access the
   green light

   martin: if it's on can drain battery without sending any data

   fluffy: expectation is that when camera goes on light goes on

   ekr: going over the proposed rule

   dom: I'm a little bit confused. if the indicator is in the
   chrome I won't see it if I switch to a different app (on a
   mobile phone); how does that affect the reliability of granting
   access to a camera to a peer

   ekr: we should

   Mathew: will we be able to check for long term permissions?
   ... action on ekr to write something up on tainted streams

   hta: suggest camera access as a topic for the other issues
   later today

API for removing streams

   hta: presenting what "remove" means

   fluffy: we should not look at index

   hta: either we don't remove the streams and you have a fixed
   index

   adam: if we reference it by object even if it's removed from
   the array I can still find it by object reference

   dom: this is what DOM is doing

   hta: in this proposal I have two methods to access: one by
   returning all and iterate another one by name

   fluffy: why are we handing developers indexes when they can get
   them by name

   dom: using index is not a bad thing as long as you don't assume
   that what it refers to is immutable

   adam: I don't think you want to have the sequence because
   developer can store the sequence and can change later
   ... the msid draft has already a proposal how to name things

   hta: we need to decide if we want to get rid of the indexes and
   go with the labels

   Mathew: legacy devices might not label

   Adam: we should go with ID's for both streams and tracks

   hta: we need somebody to write a proposal

   <martin> there seemed to be general agreement with Adam's
   suggestion, namely assigning ids to every stream and track and
   having label used only for human-readable text

   <dom> ACTION: Adam to update APIs to use mutable arrays of
   streams in peerconnection with ids [recorded in
   [13]http://www.w3.org/2012/10/30-webrtc-minutes.html#action01]

   <trackbot> Created ACTION-59 - Update APIs to use mutable
   arrays of streams in peerconnection with ids [on Adam Bergkvist
   - due 2012-11-06].

DTMF

   hta: presenting API requirements

   hta: proposal to have two new functions on RTCPeerConnection

   justin: I like the idea of having the callback with tone and
   duration

   Martin: the proposal was to have a track (something that looks
   like a track)

   hta: what's the factory for that track?

   Martin: you construct it

   hta: now you need to the go from the track to the
   peerConnection

   Martin: you get the track from getUserMedia, you decorate it
   for DTMF and attach to the peerConnection
   ... on the receiving end it's simple

   hta: If I would be to implement where do I reliably place this?

   Fluffy: How do you know to negociate for DTMF?
   ... another one is long tones use cases

   justin: you can emulate this with the proposal

   fluffy: I"m fine with getting rid of the long tones

   Stefanh: I like the proposal. I'd like more control on the
   outgoing part

   burn: I think you can have the DTMF track be created by the
   peerConnection

   justin: I support hta's proposal

   hta: I'll modify the proposal to incorporate burn's suggestion

Other business

   hta: reviewing the collected items for discussion

What Triggers Candidate Fetching

   Mathew: Use case is when a web page displays "call agent" . I
   don't want all the visitors of the page to use my turn servers

   ekr: This should not be a problem

   hta: I don't understand why the use case is not satisfied

   Martin: you want to load the page and show as quickly as
   possible

   justin: we have two mechanisms to control the candidates
   gathering
   ... you can do that now

   Martin: this brings us to changing constraints on the fly

   fluffy: we want to preallocate now were' talking about how to
   do it in the API design

   justin: you would know what you need if you call setLocal

   fluffy: you can optimistically assume two

   Mathew: you got two use cases: the conference model where you
   call in to a conference or the public page. We need to support
   both efficiently

   fluffy: can we try to make a proposal
   ... it's less elegant but should work

   justin: we can do this using setLocal

   fluffy: I have a different proposal. Have a constraint that
   defines the preallocated streams

   ekr: it's fine for me

   hta: is this sort of creating a pool?

   fluffy: yes

   <martin> proposal is to add a new constraint
   preallocateCandidates, which takes an integer value that
   defaults to zero. setting this to any other value through the
   constructor or updateIce triggers the filling of a candidate
   set pool of that size. final actions are taken on
   setLocalDescription

   hta: decision to go with the proposal to create a pool

   <martin> cullen will take an action to follow up on the last
   issue (see my last item starting with "proposal")

When is SDP sendable?

   <juberti> Next topic: when is SDP sendable

   <juberti> When do we know if we have all streams?

   <martin> my proposal for this was that the success callback
   would fire, at which time the array^Wcollection would include
   all the streams

   cullen: this doesn't let you know whether a stream was added or
   removed.

   matthew: that doesn't work in all cases anyway; imagine calling
   setRemoteDescription twice, the second time before all
   callbacks have been received.

   cullen: on all functions that have callbacks, you can't call
   the function again before the callbacks have dispatched.

   juberti: this would be setLocal, setRemote, createOffer,
   createAnswer.

   ekr: what about getUserMedia?

   … should be possible to ask for multiple cameras.

   juberti: I have a proposal to handle the getUserMedia case.

   adambe: what about onaddtrack events?

   adambe: do we need onaddtrack when a stream is added?

   cullen: I read the spec, I think it says any time the remote
   side adds a track, you need a callback.

   adambe: there's also an onunmute event on tracks too.

   adambe: how about only onaddtrack only when a stream is
   updated, as opposed to added/removed?

   juberti: I like that proposal.

   cullen: I don't.

   martin: Let's address the stream callbacks first.

   hta: Let's do that.

   martin: setLocal, setRemote, createOffer, createAnswer should
   all be non-reentrant.

   <fluffy> proposal is that that the createOffer / createAnser,
   setLocal, setRemote, you can not call the same function again
   if the callback from a previous invocation has not returned

   martin: during time between setRemote and callback, exceptions
   should occur on any of these 4 APIs.

   martin: when you call setRemote, stuff will happen, but the
   browser will return to stable state multiple times.

   <fluffy> On set remote, you install all the stuff, then does
   does callback for onaddstream for each stream, then does
   callback with null to on add stream, then it call the success
   callback for set remote

   dom: do any other APIs do this?

   anant: in XHR, some things are disallowed while it is running.

   martin: during state transitions, no other transitions are
   allowed.

   anant: you can't call open on the same XHR twice.

   stefan: might this introduce a timing problem? some browsers
   are slower than others?

   dom: I don't think so

   cullen: I would guess that this is an atomic change, and it
   takes some time - I would look at some API that has similar
   needs

   dom: maybe IndexedDB

   jimbarnett: call should block instead of throwing exception

   adambe: if you get onrenegotiationneeded, that could cause a
   problem

   cullen: onrenegotiationneeded fires after the success/error
   callback, if needed.

   martin: queuing of calls could work OK.

   cullen: one lock across all 4 APIs.

   <timpanton> The way most UI APIs deal with this is to say that
   those functions can only be called on the 'main' thread

   hta: proposal is: when calling one of these APIs - check args,
   throw exception if needed, check lock, do work or queue task if
   needed.

   <timpanton> if the callback is also invoked on the same thread,
   this makes the thing queue naturally.

   hta: nobody argued for throwing an exception instead of
   queueing.

   hta: anant to write up the details here.

   <dom> ACTION: Anant to write up queuing mechanism for
   set{Remote,Local}Description, create{Offer,Answer} [recorded in
   [14]http://www.w3.org/2012/10/30-webrtc-minutes.html#action02]

   <trackbot> Created ACTION-60 - Write up queuing mechanism for
   set{Remote,Local}Description, create{Offer,Answer} [on Anant
   Narayanan - due 2012-11-06].

   <martin> callbacks have to be called on the same thread, there
   is only one thread

   juberti: when does onaddstream fire?

   <timpanton> So how could you get re-entrancy ?

   hta: onaddstream fires after installation is complete, but
   before the success callback has been dispatched.

   <martin> re-entrancy applies only in the sense that the actions
   associated with the methods take time and so could
   (conceivably, without these measures) operate in parallel

   burn: no add stream for failures, naturally

   <martin> the actions occur on browser-internal threads or "in
   the network"

   <timpanton> ok. got it.

   juberti: when is pc.remoteStreams updated?

   adambe: before the first onaddstream callback is fired,
   remoteStreams will be fully up to date with the changes.

   derf:<same thing>

   cullen: stream names are confusing.

   derf: event callbacks need to change to be less confusing.

   <dom> ACTION: Timothy to write up proposal for new stream event
   names. [recorded in
   [15]http://www.w3.org/2012/10/30-webrtc-minutes.html#action05]

   matthew: if SessionDescription is 3264 SDP, that SDP must
   always be 3264-compliant.

   cullen: if you can't do local candidates, we should return an
   error when trying to write SDP.

   matthew: will trickle update 3264?

   cullen: I think we'll need to.

   matthew: if we're doing trickle, we're going to need to update
   something.

   matthew: how do we generate workable SDP when trickling?

   matthew: Chrome currently generates broken SDP?

   matthew: How do I get valid SDP in the non-trickle case?

   cullen: wait for ICE complete callback, then SDP will be fully
   filled-in.

   matthew: but what about the initial setLocal? That SDP isn't
   fully valid.

   juberti: That is just a subset of the trickle case.

   matthew: But the SDP still isn't valid.

   juberti: We are going to solve this with the trickle ICE I-D.

   … and then the rest of the stuff should fall into place. You
   can call setLocal with an initial "no candidates" SDP, and then
   gathering commences.

   hta: we'll refer this to the IETF rtcweb WG to figure this out,
   and then we can resume this discussion.

Security for QoS labels

   matthew: Want to see API where packet priorities can be set.

   hta: culler's proposal does this - gives 3 levels of
   priorities.

   cullen: API that provides 3, 4, etc levels

   matthew: I don't know which one is more important.

   matthew: data could be above or below media (gaming, higher,
   file transfer, lower)

   dand: where would this priority be set from an API perspective

   stefan: on a track or datachannel.

   <dom> there was a (currently abandonned) proposal for
   setPriority on XHR that also had 4 levels FWIW
   [16]http://ajaxian.com/archives/xmlhttprequest-priority-proposa
   l

     [16] http://ajaxian.com/archives/xmlhttprequest-priority-proposal

   matthew: someone needs to write up a proposal for where these
   things go.

   hta: set at initialization, or during the call?

   matthew: I think it could be initialization.

   dand: once we get this request, we need a confirmation from the
   browser that it tried to accomplish this.

   martin: why?

   dand: this request can be fulfilled by going to a policy
   server.

   matthew: I don't care about marking, I just care about the
   congestion control prioritization

   matthew: not all packets will be labeled the same way

   matthew: either for different streams, or different packets in
   the same stram

   hta: need to set priority levels, and have it per track, and
   have 3 or 4 levels.

   hta: this will set congestion control/queuing in the browser,
   and setting of QoS is something for further study

   matthew: cullen has already written a draft

   goran: cullen's draft refers to other drafts

   cullen: we will remove that reference.

   cullen: we don't want JS to set the diffserv code points, but
   we do want it to be able to discover them.

   hta: want mapping from track to 6-tuple?

   <juberti> ACTION: Cullen to update draft to remove reference.
   [recorded in
   [17]http://www.w3.org/2012/10/30-webrtc-minutes.html#action06]

   <trackbot> Created ACTION-61 - Update draft to remove
   reference. [on Cullen Jennings - due 2012-11-06].

   Action. stefanh to propose priority API.

   <juberti> ACTION: stefanh to propose priority API. [recorded in
   [18]http://www.w3.org/2012/10/30-webrtc-minutes.html#action07]

   <trackbot> Created ACTION-62

   Adjourning for lunch.

Summary of Action Items

   [NEW] ACTION: Adam to update APIs to use mutable arrays of
   streams in peerconnection with ids [recorded in
   [19]http://www.w3.org/2012/10/30-webrtc-minutes.html#action01]
   [NEW] ACTION: Anant to write up queuing mechanism for
   set{Remote,Local}Description, create{Offer,Answer} [recorded in
   [20]http://www.w3.org/2012/10/30-webrtc-minutes.html#action02]
   [NEW] ACTION: Cullen to update draft to remove reference.
   [recorded in
   [21]http://www.w3.org/2012/10/30-webrtc-minutes.html#action06]
   [NEW] ACTION: stefanh to propose priority API. [recorded in
   [22]http://www.w3.org/2012/10/30-webrtc-minutes.html#action07]
   [NEW] ACTION: Timothy to write up proposal for new stream event
   names. [recorded in
   [23]http://www.w3.org/2012/10/30-webrtc-minutes.html#action05]

   [End of minutes]
Received on Thursday, 15 November 2012 10:37:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 15 November 2012 10:37:23 GMT