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

[minutes] June 11 F2F

From: Dominique Hazael-Massieux <dom@w3.org>
Date: Tue, 12 Jun 2012 11:54:38 +0200
Message-ID: <1339494878.24928.30.camel@cumulustier>
To: public-webrtc@w3.org
Hi,

The draft minutes of the WebRTC Working Group F2F meeting held in
Stockholm on June 11 (hosted by Ericsson) are available at:
http://www.w3.org/2012/06/11-webrtc-minutes.html

and copied as text below.

Dom

                               - DRAFT -

       Web Real-Time Communications Working Group Teleconference

11 Jun 2012

   [2]Agenda

      [2] http://www.w3.org/2011/04/webrtc/wiki/June_11_2012#Agenda

   See also: [3]IRC log

      [3] http://www.w3.org/2012/06/11-webrtc-irc

Attendees

   Present
          Harald_Alvestrand, Stefan_Hakansson, Magnus_Westerlund,
          Ted_Hardie, Tim_Terriberry, Anant_Narayanan,
          Dan_Burnett, Dan_Druta, Dominique_Hazael-Massieux,
          Cullen_Jennings_(remote), Justin_Uberti_(remote),
          Adam_Bergkvist, Jim_Barnett, Neil_Stratford, (remote),
          Stephan_Wenger, Gang_Liang(remote), Salatore, Loreto,
          Jonathan_Lennox, EKR_(remote), Randell_Jesup_(remote),
          Maire_Reavy_(remote), Mary_Barnes, Gonzalo_Camarillo,
          Richard_Ejzak

   Regrets
   Chair
          Harald_Alvestrand, Stefan_Hakansson

   Scribe
          anant, burn, DanD, stefanh_, dom, stefanh

Contents

     * [4]Topics
         1. [5]JSEP in PeerConnection
         2. [6]Statistics API proposal
            (http://www.w3.org/2011/04/webrtc/wiki/images/7/7d/Jun
            e_11_Stats.pdf)
         3. [7]Data API
         4. [8]Back to JSEP
     * [9]Summary of Action Items
     __________________________________________________________

   <dom> (there are more people in the room, but I can't identify
   them visually; if you know any of the missing names, please
   type "Present+ Name")

   <dom> [10]JSEPified PeerConnection API (slides)

     [10]
http://www.w3.org/2011/04/webrtc/wiki/File:WebRTC_interim-june-2012_PeerConnection_API.pdf

   <dom> Scribe: anant

   <dom> [11]WebRTC open action items

     [11] http://www.w3.org/2011/04/webrtc/track/actions/open

   <dom> ACTION-11?

   <trackbot> ACTION-11 -- Daniel Burnett to add Constraints API
   to API spec -- due 2012-01-12 -- OPEN

   <trackbot>
   [12]http://www.w3.org/2011/04/webrtc/track/actions/11

     [12] http://www.w3.org/2011/04/webrtc/track/actions/11

   Welcome to the W3C interim! Coffee at 10:30, lunch at 12:30 CET

   Administrivia, going through action items

   stefanh_: Action 11 is ongoing, more to be discussed today

   <dom> ACTION-12?

   <trackbot> ACTION-12 -- Daniel Burnett to add Stats API to API
   spec -- due 2012-01-20 -- OPEN

   <trackbot>
   [13]http://www.w3.org/2011/04/webrtc/track/actions/12

     [13] http://www.w3.org/2011/04/webrtc/track/actions/12

   stefanh_: ACTION 12

   <dom> ACTION-12: Harald's proposal
   [14]http://lists.w3.org/Archives/Public/public-webrtc/2012Jun/0
   040.html

     [14]
http://lists.w3.org/Archives/Public/public-webrtc/2012Jun/0040.html

   <trackbot> ACTION-12 Add Stats API to API spec notes added

   harald: I put some comments, feedback welcome

   <Martin_> I'm not sure that the mic is working

   burn: capabilities was discussed in terms of the constraints.
   there needs to be a quick check on the list before we can put
   it in

   dom: I agree. there is the sysapps WG whose one of the charter
   items is to define how web applications should be given access
   to privileged APIs

   burn: it would be good to look at that group. I want to make
   sure we don't wait on a model from that group before being able
   to put capabilities in our document

   <dom> ACTION-16?

   <trackbot> ACTION-16 -- Eric Rescorla to propose how to tie
   into identity frameworks for comms partner verification -- due
   2012-01-12 -- OPEN

   <trackbot>
   [15]http://www.w3.org/2011/04/webrtc/track/actions/16

     [15] http://www.w3.org/2011/04/webrtc/track/actions/16

   stefanh_: next action, putting identity information

   ekr: I am a little behind on that, working on it now. I can
   have that by 2 weeks or so

   <dom> ACTION-16 due June 25

   <trackbot> ACTION-16 Propose how to tie into identity
   frameworks for comms partner verification due date now June 25

   stefanh_: next action (25), belongs to the media capture task
   force. to draft initial requirements

   stefanh: propose to not discuss it further here

   fluffy: I had a question about that, what is the plan here?

   stefanh_: the plan is to move it from this tracker and opened
   into the mediacap tracker

   <dom> ACTION-29?

   <trackbot> ACTION-29 -- Cullen Jennings to change all numeric
   constants to be enumerated strings -- due 2012-06-15 -- OPEN

   <trackbot>
   [16]http://www.w3.org/2011/04/webrtc/track/actions/29

     [16] http://www.w3.org/2011/04/webrtc/track/actions/29

   fluffy: largely we've taken the first stab at moving most of
   the stuff, but we're still waiting for the respec2 move

   burn: there is no need to move respec2. dom made changes to the
   gUM doc, but we can do the same changes to the webrtc doc
   ... respec 3 = respec 2 + extra module

   <dom> ACTION-29: mostly done, waiting for new respec version

   <trackbot> ACTION-29 Change all numeric constants to be
   enumerated strings notes added

   <dom> +1 on moving WebRTC to respec v3

   burn: it worked well with gUM, so it's worth trying with the
   webrtc document

   stefanh_: action 42 is also mediacap
   ... shall we move on to the next part of the agenda? JSEPified
   PeerConnection API

   adambe has slides on the discussion

   <dom> [17]JSEPified PeerConnection API (slides)

     [17]
http://www.w3.org/2011/04/webrtc/wiki/File:WebRTC_interim-june-2012_PeerConnection_API.pdf

JSEP in PeerConnection

   adambe: slides about our current PeerConnection API, I didn't
   really know in what form to do this. start with a simple
   example
   ... the code in the example has never been run, so there could
   be issues. but here's my view of how this API could work right
   now

   as few lines as possible, the straightest line possible between
   a two-way audio/video call

   the overview shows each step in the process

   subsequent slides will go in detail for each part

   who you are calling is left to the web application. variable
   signalingChannel is a way to send data to the other side
   (somehow)

   create a peerconnection, a way to handle ice candidates as they
   come in, use signalingChannel to send the candidate from the
   event over to the other side

   handler for handling what happens when you get a stream from
   the other side. in this case, we simply show the video in a
   video element

   <dom> (as far as I can tell, the current editors draft doesn't
   allow "null" for the IceServers configuration param in
   PeerConnection param)

   part2: use getUserMedia to get access to the local media and
   create an offer or answer (based on role)

   part3: handling incoming messages sent through the
   signalingChannel. three types of messages: "offer", "answer"
   and "candidate"

   anant: what is the SessionDescription constructor?

   adambe: that's how it is in the spec right now, it converts the
   string to an object

   <dom> anant: we can't add "SessionDescription" as a global
   object; we could either make it a sub-interface of
   PeerConnection, or avoid a constructor altogether by using a
   string

   <Martin_> mic

   adambe: we have a constructor to go one way, and stringifier to
   go another wa

   the object is the place to add those, and it's the placeholder

   <nstratford> Would it be possible for someone to relay slide
   numbers into the chat for those of us trying to follow along
   without video or slides in webex?

   <stefanh_> harald switched to the right slide in hang-out

   <DiMartini> this is the last slide

   dom: I don't know if there's another WebAPI that does that

   harald: get it out of the global namespace as an action item,
   and we can do the specific proposal

   adambe to consult with dom and make a proposal

   <dom> ACTION: adam to move SessionDescription and IceCandidate
   out of the global namespace [recorded in
   [18]http://www.w3.org/2012/06/11-webrtc-minutes.html#action02]

   <juberti> PeerConnectionSessionDescription

   <trackbot> Created ACTION-43 - Move SessionDescription and
   IceCandidate out of the global namespace [on Adam Bergkvist -
   due 2012-06-18].

   <dom> juberti, I think the idea was more to have
   PeerConnection.createSessionDescription() or something

   adambe: let's see what happens when someone calls. the start
   method takes a boolean in this example (true for outgoing,
   false for incoming)

   anant: on the receiving side, you're calling
   navigator.getUserMedia, and then createAnswer, without having
   received the offer

   adambe: the caller side has called start(true); the callee side
   hasn't done anything yet

   <fluffy> If this helps at all, I have a bit of a call flow at

   <fluffy>
   [19]https://github.com/fluffy/webrtc-w3c/raw/master/call-simple
   .png

     [19]
https://github.com/fluffy/webrtc-w3c/raw/master/call-simple.png

   <fluffy> it has some known problems

   ekr: what is the sequence of events on the answerer side?

   juberti: [answering, but not audibly]

   fluffy: I suspect this hasn't been carefully thought about

   fluffy: originally we didn't have the split and we didn't have
   setRemoteDescription

   juberti: do we still need pc.remotedescription as an argument
   to createAnswer?

   fluffy: what will drive this requirement is a rollback on
   update, but so far we don't have call flows that require this

   adambe: you do addstream, and when you call createAnswer, you
   use the added stream on the pc as the source of information,
   and then you pass a separate offer as another input
   ... it might make better sense to get both added streams and
   remote description from the pc

   <ekr> My general ask to the authors is that they need to
   provide a definitive answer to every such questoin.

   harald: the difference I remember is that with
   createAnswer(arg) you have not committed to accept from the
   other side

   <Martin_> There is a potential bug in the example code if the
   browser calls the getUserMedia callback inline because the
   remote description wont have been set when that happens.

   i.e. no guarantee to call setRemote after createAnswer

   ekr: I'd like to hear definitely whether or not I should call
   setRemoteDescr...

   juberti: you don't right now

   fluffy: this is clearly an issue where I haven't heard strong
   arguments one way or another. but obviously need to be defined

   lots of different alternatives

   if people have a preference for one or the other it would be
   great to hear

   ekr: one of the things I need to do is to introspect the offer.
   is one of the ways I do this is via setRemote that's fine, but
   we want to try and limit side effect to calling setRemote

   juberti: my expectation is that it doesn't really have a lot of
   side effects. unless there's both local & remote description
   nothing will happen

   fluffy: yeah

   juberti: why would we not automatically generate an answer when
   calling setRemoteDescr…? the answer lies is some outlying cases
   where there might be modifications required. but if we are
   always passing in the same description, then we should.

   <dom> ACTION: cullen to deep dive on setRemoteDescription with
   justin [recorded in
   [20]http://www.w3.org/2012/06/11-webrtc-minutes.html#action05]

   fluffy: what happens when you call setRemote? are any added
   stream callbacks called?

   <trackbot> Created ACTION-44 - Deep dive on
   setRemoteDescription with justin [on Cullen Jennings - due
   2012-06-18].

   juberti: the stream stuff is pretty clear, when setRemote is
   called, it triggers the callback

   fluffy: we might need two different callback.
   onstreamproposed/onstreamaccetped?

   harald: is it even meaningful to reject a stream? if the other
   end is sending me a stream, I can either take the data, or
   cause the data to not be sent

   ekr: I don't reject the idea, but the spec talks quite a bit
   about what happens when a stream is permanently dead
   ... when I get told there's a stream on the other side, I can
   either accept, get media, or I've been told there is no more
   media

   stefanh_: but you do hear about all this stuff. you get events
   on the stream

   ekr: what about the event where I get a video with h.264 but I
   constraint to only vp8 via setLocal

   juberti: you plugged in setRemote, got streams with
   audio/video. I don't know if you have track event, but you get
   stream event, you would then listen for onended, and these
   things are not negotiated

   ekr: conversely, when you accept, what happens?

   juberti: we talked about having an event where media start
   arriving

   stefanh_: you get an unmuted for incoming data

   ekr: what's the UI? in incoming call request, want to display
   audio/video, open a screen big enough, but don't want to do it
   until we know we can display it. but also before media actually
   arrives

   harald: tentatively, I think, when you get media stream
   (onstreamadded), and then you get media track events saying
   that the stream has ended because it cannot be delivered

   fluffy: using muted is bogus, because the other side may
   actually be muted so there's no data

   ekr: I tend to agree with cullen, but I can be convinced that
   it can be made to work

   juberti: we need to know one way or another if the negotiation
   completed or not

   ekr: that may imply the main thread has to block until the
   negotiation finished?

   so we'll need another event

   fluffy: so we'll add another event

   juberti: we need a state machine for streams

   <ekr> harald++

   harald: we need a state machine for streams and a state machine
   for tracks. audio track will be perfectly fine if we can't
   agree on the video codec.

   fluffy: the per track state. do you want us to do that as an
   extension of the tracks in this document or in the gUM
   document?

   dom: I think it belong in webrtc document

   harald: we have to have a state machine in the gUM document,
   but extend with more event and state in this document

   first we should figure out what events and states are

   fluffy: the high level use case is to see if negotiation failed
   or suceeded

   juberti: media arriving and muting should all be explicit

   adambe: as in the spec right now, things are very fluffy "when
   a stream has enough information to know it succeeded it should
   unmute"
   ... addtrack event is after setRemoteDescr… is called. is that
   really a stream in that case? it's something to be negotiated.
   I think we should have a mediastream only when the negotiation
   has completed

   fluffy: this ia an alternative approach, but we can make it
   work. there are some corner cases that we need to handle
   ... I think we can deal through all those issues.
   ... in the media stream's object it won't be in the video or
   audio track list (for smellivision)

   ekr: what's going to happen when we add non video/audio tracks
   to streams?

   <dom> partial interface MediaStream { attribute Smell
   smelltracks; }

   fluffy: does it buy you anything to have separate "tracks"
   attribute? and not just video/audio track sets

   stefanh_: it was to align with the media elements spec

   fluffy: a track should tell you what the type is

   harald: we discussed it a lot, and there was no case where it
   was simpler to have one set of tracks than 2 sets of tracks. I
   don't want to reopen that discussion
   ... ekr I think that if you want to have a dictionary instead
   of attributes, throw yourself at it

   <Martin_> var audiotracks = alltracks.filter(function(x) {
   return x.type === 'audio'; })

   <dom> +1 to harald

   <stefanh_> +1 to harald

   harald: I think it is actually extensible enough that we can
   add later when we need them, but adding earlier than needing
   them is not pleasant

   ekr: I'm not suggesting that we add them right now, as a
   programmer it's not ideal to have things named like this

   <ekr> I usually argue that the valid number of objects is: 0,
   1, and infinite

   <juberti> audiotracks = pc.tracks("audio")

   <ekr> juberti++

   jim barnett: we need a JS API to introspect the offer, and you
   don't get a stream object until you accept

   richard: you still need a way for the browser of responding to
   an offer based on what it's capabilities are. my interpretation
   is that createAnswer is the way to do that

   the question is, if there is enough information to the JS for
   it to know if it can accept the answer or not. there's a little
   bit of a chicken and egg there

   <Martin_> there is a problem with the haptic track

   <hta> ekr, I wouldn't mind too much if we defined tracks as
   tracks { audio[], video[] } rather than audiotracks[],
   videotracks[]. That's what I was driving at with "dictionary".

   <ekr> hta, that would be preferable to me.

   <Martin_> +

   <ekr> how do we make it so

   <juberti> that works for me too

   <hta> ekr, type up the IDL you want and send it in.

   <ekr> Willdo.

   adambe: we can discuss this issue separately later

   <dom> ACTION-44: Adam can help with when streams should be
   dispatched

   <trackbot> ACTION-44 Deep dive on setRemoteDescription with
   justin notes added

   [time for coffee! 15 minute break]

   <nstratford> Hangouts still doesn't work for many of us -
   please don't turon off WebEx!

   adambe: continuing example slide

   after setRemoteDescription is called, on the callee side,
   getUserMedia is called to select a local source

   if we're lucky, media will start flowing and the streams can
   been displayed

   ekr: there are a lot of events been thrown out of this API.
   only the ICE event fire in the example, what about the others?

   adambe: there's a subsequent slide that discusses the ICE
   events

   ekr: but there's also PeerConnection events. it's unclear to me
   when all these events fire

   <dom> (and do we need all these events?)

   adambe: I don't think it's clear when some of these events fire

   ekr: I can go in and enumerate when I think these events fire,
   do people want that?

   <juberti> ekr: perhaps you could mark up the sample i wrote up
   with the event times?
   [21]https://docs.google.com/document/d/1L3lMBINuLn2S7EO4APWTUaP
   cUMV0Ke1q2zCzZaYYba8/edit

     [21]
https://docs.google.com/document/d/1L3lMBINuLn2S7EO4APWTUaPcUMV0Ke1q2zCzZaYYba8/edit

   fluffy: proposal, why don't ekr and I take as an action item to
   annotate when the events fire
   ... sometimes ICE is per track and other times it's for the
   peerconnection, deliberately not cleared up in the spec yet

   <dom> ACTION: cullen to annotate the callflow diagram with
   events fired [recorded in
   [22]http://www.w3.org/2012/06/11-webrtc-minutes.html#action06]

   <trackbot> Created ACTION-45 - Annotate the callflow diagram
   with events fired [on Cullen Jennings - due 2012-06-18].

   <juberti> ekr,
   [23]https://docs.google.com/document/d/1L3lMBINuLn2S7EO4APWTUaP
   cUMV0Ke1q2zCzZaYYba8/edit

     [23]
https://docs.google.com/document/d/1L3lMBINuLn2S7EO4APWTUaPcUMV0Ke1q2zCzZaYYba8/edit

   <ekr> juberti, thanks

   adambe: regarding events and examples, most of the events, we
   don't really need

   fluffy: it's true you don't need them, but the customer for the
   spec is the browser implementers who need to know when to
   generate them

   adambe: I have suggested some discussion topics
   ... how to tell we have enough candidates? in the trickle case

   adambe: do we need to talk about that before we decide what the
   events are associated with?

   juberti: the "null" event may have independently of a candidate

   fluffy: in nearly every I think that is the case

   ekr: it is passing effectively a domstring to the interface for
   each candidate, then null may be okay, but for JSON, what would
   you do

   juberti: if some ICE candidate is an object, then this would
   have the m-line for SDP

   and real objects can be null in the DOM

   ekr: there are fast path lines, there is the case where I have
   two interfaces but can't write to one of them

   harald: for the implementation, we faked it by just doing a
   timeout. the browser should not decide when it's enough that we
   got all the candidates

   either we define what's enough, or we leave it to the
   application

   ekr: but the browser does know!

   fluffy: I think harald makes a good point, enough is not the
   right thing here, the question is when is ICE done? there are
   no more candidates

   ekr: the technical state in which every candidate fails or
   succeeds, happens about 40 seconds later...

   fluffy: that's the event we are talking about

   juberti: the application needs to either have its own timeout,
   but if it gets told if I have everything ahead of that, I'm not
   going to wait that long

   fluffy: so we need an event that does this ICE session is done

   ekr: the relevant event here is: I have now received STUN
   answers or given up on every possible candidate. min time: 0,
   max time: ~40-60 seconds after

   <JonLennox> The max time depends on your rtt estimate to your
   stun/turn server, doesn't it?

   adambe: so we need something in between 1 candidate and 40
   seconds later.

   ekr: how would you tell the browser this

   I would set a timer at the beginning for roughly at 4-5
   seconds, and timer or callback firing would send out the offer

   juberti: I think it should be really short, if it takes more
   than 5 seconds for a candidate, you probably don't want to use
   that candidate

   <fluffy> I think the action here should be that we define what
   happens when the browser wishes to indicate that it it is not
   expecting any more candidates to be produced - at that point it
   will indicate it by doing the following ?

   ekr: one thing it might be relevant here, would it make sense
   for the application to control
   ... there are only two relevant events, I got 1 candidate, or
   I'm done.

   juberti: anything in between is hard to specify

   if you using trickle candidates, that will always work better
   than timeouts

   fluffy: so null or events?
   ... it seems to me that the code you want to write is different
   in the case where you get a real candidate than when you get
   this event, you might want two different callbacks

   juberti: there's gathering, connecting.. there's really not any
   linear state progression in ICE. you can't get away from an
   explicit callback

   <JonLennox> I think there are separate state machines for
   gathering and connecting

   adambe: to sum up, people seem to agree that there should be
   some information on the candidates so the app can decide when
   to send something off. is the 40 second event useful to anyone?

   <Martin_> JonLennox, I agree

   <Martin_> the new issue is whether there are different state
   machines for the multiple different flows that might be created

   juberti: the last event is when the browser has finished ICE
   and it's got all the candidates that is can get

   fluffy: that often happens in <50ms

   so we definitely need that event

   juberti: the middle event is not needed when you use trickle
   candidates, and it's essentially a timeout

   jonathan: one issue where the 40second timeout is potentially
   interesting, trying to connect and nothing is working

   at the NULL you can switch from pinwheel to failure message

   juberti: that makes even more argument for the "now I think
   it's a good time callback"

   stefanh_: I have a problem with this in-between event because
   it depends on the other side

   adambe: so theres an event for every candidate, and one final
   event

   <JonLennox> You can always try the host candidates — you never
   know, they might work.

   <Martin_> and there are always host candidates

   stefanh_: resolution is: there will be 1 event for each
   candidate, and one event for "no more candidates".

   <dom> PROPOSED RESOLUTION: there will two kind of events: one
   for each candidate (to allow trickling), one when the browser
   has exhausted all possibilities

   the middle event is left up to the application

   <dom> RESOLUTION: there will two kind of events: one for each
   candidate (to allow trickling), one when the browser has
   exhausted all possibilities

   adambe: next topic is the renegotiation event

   <dom> [Shouldn't we make PeerConnection derive from
   EventTarget, to make it possible to use
   addEventListener/removeEventListener in addition to on...
   functions?]

   the idea here is to have a callback or an event that would help
   the developer to know when to actually create a new offer on
   answer

   <anant> +1 dom

   ekr: I don't know if this is needed, but I have a question, but
   will this be fired whenever addstream is called?

   fluffy: yes, that's the current thinking

   adambe: the name should probably be negotiationneeded instead
   of renogotiationneeded since it can happen the first time too.

   ekr: so if I add two streams, I get two of these callbacks?

   juberti: the callback only fires when it's actually needed

   adambe: this is quite a big topic, I don't know if we have
   enough to discuss it here. should the callback be triggered or
   not depending on the state...

   ekr: this is problematic in the naive implementation of gUM
   that is calls onaddstreams when it responds. now I call gUM
   twice if the negotiationadded is called twice

   juberti: only setLocalDescription changes the state, so calling
   createOffer without setting it won't call it

   adambe: if you do two addstreams in the same event loop
   iteration, it should only result in 1 event

   Martin_: but this would be in the gUM callback which almost
   certainly isn't in the same event loop iteration

   ekr: but what happens when I get this callback when I'm still
   waiting for createOffer to return?!

   adambe: perhaps we need more call flows & examples before we
   can dig into this

   stefanh_: we're only discussing here for tracks or streams,
   does this also happen when hardware is removed/added, or there
   is a browser-level mute?

   <ekr> Executive summary: I'm worried about race conditions.

   but we haven't decided which way to do these, and lot of other
   things to consider

   ekr: i'm not against this functionality just that it's defined
   in a way that doesn't result in problems

   juberti: this call flow seems to make sense to developers on
   webrtc-discuss

   adambe: to make the API easy to use, this is important, but
   it's not crucial for the functionality

   Paul_Kyzivat: : do you have a any notion of replacing a stream
   or changing the characteristics? it introduces nasty issues

   it's not unheard of to replace a m=audio line with another
   completely different line

   you have to keep both streams live and then decide which one to
   keep after a while

   the question is: the model you're talking about, maybe it's not
   rich enough to handle those cases? what do you do to your
   stream to change a codec?

   burn: as far as constraints are defined now, the browser can
   change the stream midway as long as it satisfies the
   constraints, even if it need a codec change

   fluffy: one use case is when the server switching to a
   narrow/wideband

   richard: if we just look at need to renegotiate in SDP, I don't
   think we want to support changing the media type for an m-line,
   in WebRTC. it would be OK for us to say once you've defined
   characteristics with a media line then make it be immutable

   <Martin_> port => 0, or a=inactive

   richard: if you need to renegotiate in order to add a new media
   line, you also want to list all codecs that are present in
   other lines, when creating an offer you want a list of all
   capabilities

   juberti: in some cases you do, in some cases you don't. in the
   JSEP draft I say the cases where you'd need a full offer

   but for some cases where you are only adding one track you
   don't need the full offer

   richard: doesn't the application need to be able to define
   that/

   Andrew Hutton: does this renegotiation happen, for instance,
   when direction of an m-line is changed?

   juberti: the only way to change the direction is via client
   setLocalDescription
   ... the whole idea is that when you get this negotiation
   callback, the developer creates an offer and ships it off

   stefanh_: I would like to conclude this discussion… we are
   moving into IETF territory

   the consensus seems to be that we need this callback, but
   editors need to define in what cases

   adambe: other topics: constraints that we can add, new global
   object IceServers, createProvisionalAnswers, ICE restart
   ... when we get a stream, how many places in the API can I have
   an effect on the workings of the system? what are the
   possibilities of introducing conflicting constraints

   if we count tweaking sdp from string and back to object, we
   have 5 places, and it feels like a lot of places where we can
   tweak

   juberti: 1, 2, 3, 4 are all needed, and 4 and 5 seem the same
   to me

   ekr: is there a 4 in the spec? do we need it?

   <ekr> sdp.tweakOffer = function(f) { this = f(this); }

   juberti: there will always be cases where we won't provide what
   the application wants (and they have to do it by hand), but for
   streams and gUM they are seperate.

   adambe: I agree that the intention is to modify separate
   things, but we have to be careful that we don't introduce
   conflicting constraints

   the reason or adding #4 is that, we should provide APIs to
   tweak the SDP

   <ekr> my brain seems to be failing: where is the constraints
   algorithm currently defined?

   fluffy: I agree no-one should parse the SDP on their own, but
   I'm hoping that constraints will cover all the things we need
   to do

   <dom> ekr, in getUserMedia

   <dom> ekr,
   [24]http://dev.w3.org/2011/webrtc/editor/getusermedia.html#meth
   ods-3 more specifically

     [24]
http://dev.w3.org/2011/webrtc/editor/getusermedia.html#methods-3

   stephanh: wouldn't it be confusing if one constraint in
   getUserMedia could also be set/overriden in addStream?

   ekr: I'm less concerned about 1vs2 than I am about 2vs3

   <ekr> oh, I see, it's just not where I expected. Thanks

   juberti: we need to have a clear indication about what
   constraints go into which API calls. you can't pass ICE restart
   into gUM

   <dom> (I think this means the constraints registry should make
   which constraint for which context abundantly clear)

   juberti: there's a 2nd parameter to the constructor where you
   put ICE constraints

   fluffy: some are perfectly willing to put relays for audio, but
   not putting video. constraints will be different for two
   different cases
   ... let's do an easy one like aspect ratio. If I set aspect
   ratio in #1, will that be remembered, or do I call it
   everytime?

   juberti: 1 gets carried over to 2; but if I add the stream to
   two different streams, then I can override

   <ekr> correction: 5 doesn't exist

   harald: this particular point illustrates that setting
   constraints have to fade at some point, because in the current
   setup it is easy to define conflicting constraints

   ekr: 5 exists, 4 doesn't

   <ekr> oh, you're right

   <fluffy> Ted has got the video reflected into webex for the
   folks on webex

   burn: I think that there will be subtle differences in
   interpretations of constraints in the different cases unless we
   define the context

   dom: does the registry ask for context for constraints?

   burn: currently doesn't but we can add it once we know what we
   want

   adambe: : for ICEServers, we have two suggestions: list of
   string, list of list of strings

   <ekr> so, I think we still didn't work out the merge algorithm

   dom: first easy change is to make it a dictionary

   <ekr> OR when it's needed.

   <fluffy> we can't hear whoever that was

   adambe: I think you're right

   <ekr> CAn the chairs keep this issue open?

   <stefanh_> it will be kept open

   <ekr> stefanh_, thanks

   <dom> (the actual syntax would be "DOMString[] servers", not
   "DOMString servers[]")

   adambe: do we have any requirements of different ICE
   constraints on different servers

   harald: that might make sense

   <Martin_> can someone explain how SRV interacts with this while
   you are at it?

   <hta> ACTION: anant to write up a spec for IceServer object,
   and compare [recorded in
   [25]http://www.w3.org/2012/06/11-webrtc-minutes.html#action07]

   <trackbot> Created ACTION-46 - Write up a spec for IceServer
   object, and compare [on Anant Narayanan - due 2012-06-18].

   dom: in your example, PeerConnection has null as the value, the
   draft doesn't allow null.

   anant: I think we should allow null and the browser should have
   defaults.

   adambe: for createAnswer, do we need the offer argument or can
   it automatically grab it from the pc?

   <JonLennox> Martin_, I'd think that'd be defined by the
   STUN/TURN URI definition?

   <dom> (on top of make it nullable, we should also make it
   optional then)

   fluffy: no-one could come any reason for why we couldn't remove
   the argument

   <Martin_> JonLennox, it's pretty vague in the STUN URI draft

   <dom> ACTION: Anant to provide a code example showing
   continuation for createAnswer [recorded in
   [26]http://www.w3.org/2012/06/11-webrtc-minutes.html#action08]

   <trackbot> Created ACTION-47 - Provide a code example showing
   continuation for createAnswer [on Anant Narayanan - due
   2012-06-18].

   <JonLennox> Martin_, should be fixed there then

   <Martin_> JonLennox, I'll take it up with the authors

   harald: this the 3rd redesign in 6 months, and I dont' want a
   redesign without a compelling reson

   6 months ago, I would settle for appealing reasons, but at this
   point I'd rather have a compelling reason

   fluffy: we haven't designed error handling yet, this may fall
   in this category

   harald: want to get into SdpType before lunch. having them
   twice is wrong, we should settle that

   ekr: we should have a new method call

   <ekr> that was sarcasm

   harald: we should try the polling method. who would like to
   have SdpType inside or outside?
   ... 1st question: do you have an opinion?

   7 opinions

   how many prefer to have the type inside the sdp object: 5

   how many prefer to be outside: 2

   conclusion: put the sdptype inside, remove the additional
   parameter

   harald: we can have the discussion about mutability later

   <Martin_> You missed the fourth and fifth questions, which are
   who thinks that the colour of the bike shed doesn't matter

   ekr: certain things are errors, but mutating it to wrong values
   is an error

   lunch!

   <juberti> derf i would prefer that it be mutable, but yes, that
   could be a less elegant workaround

   <juberti> it shall be green:
   [27]http://mamdblueroom.files.wordpress.com/2010/11/bikeshed2.j
   pg

     [27] http://mamdblueroom.files.wordpress.com/2010/11/bikeshed2.jpg

   <burn> scribe: burn

Statistics API proposal (
[28]http://www.w3.org/2011/04/webrtc/wiki/images/7/7d/June_11_Stats.p
df)

     [28]
http://www.w3.org/2011/04/webrtc/wiki/images/7/7d/June_11_Stats.pdf)

   hta: vital need for statistics, but often left until the last
   minute, so i wrote something

   <dom> [29]Stats API proposal, from Harald

     [29]
http://lists.w3.org/Archives/Public/public-webrtc/2012Jun/0040.html

   hta: statistics not intended for end user, mainly for service
   provider. Is everything actually still working?
   ... since service provider's only access is API, stats should
   be there
   ... should reuse meanings in other statistics collection
   approaches
   ... MediaStreamTrack is the core unit for collecting stats.
   Feedback from recipient to sender is important.
   ... since all of the data we care about is time-varying, need
   to timestamp everything
   ... means we will need to sync clocks (or equivalent), but lots
   of world knowledge here.
   ... user JS calls GetStats() on pc, then callback returns info
   ... model includes a pointer to track, local/remote data sets,
   data items are key/value pairs with keys in a new (?) registry
   ... define some MTI stats such as packets and bytes, IP:Port
   ... anyone can propose new statistics for registry. Need to
   distinguish between unsupported statistics data item and no
   result for that item.
   ... need aggregated statistics (MediaStream, all PC)
   ... maybe schedule periodic callbacks as well. The latter two
   may not need to be in version 1
   ... one challenge is that not all info is known to browser

   <fluffy> one comment on OS audio path, echo cancelation often
   estimates the round trip

   hta: another is that synchronized stats are needed for
   aggregation, but can't always exactly correlate sender and
   recipient data
   ... (jumps to "issues solved elsewhere") JS solves this

   anant: setInterval doesn't control when callbacks occur

   dom: you made this async because collection can take time?

   hta: if i can't guarantee getting back to you within 10ms, i
   shouldn't block. sometimes may need to call out to external
   module that could take time, although usually it won't.

   adam: can you say "collect for 10 secs"

   hta: don't want to. count in the core and use callbacks to
   compare and do the calculation

   dom: in zakim, eg, can ask who is making noise and it will wait
   for 10 secs

   hta: should be done at JS level

   stefan: have you been thinking about the data channel?

   hta: no

   stefan: i don't think we should have stats

   cullen: web sockets doesn't' have stats but is visible to
   browser

   randell: info is useful to app. bytes queued are available in
   websockets

   cullen: at least need bytes xmitted and received

   randell: per data channel, or global?

   cullen: not sure

   hta: difference from media is in data channel app sees the
   bytes, but not for media

   cullen: want to know what happened on network

   randell: there could be other useful info

   magnus: about data channel, also have partial reliability
   option. may need to know reliability stats

   hta: RFC for STCP MIB exists?

   <DanRomascanu> nobody implements that AFAIK

   hta: (continuing with slides) another challenge is model
   problems
   ... eg, where to count in FEC streams, where stats go for
   removed streams, how you count for multi-stream tracks

   <dom> [30]SCTP Management Information Base (MIB)

     [30] http://www.ietf.org/rfc/rfc3873.txt

   adam: where are counters in the first place?

   hta: conceptually they are attached to a MediaStreamTrack. You
   need a handle to the track to get data

   dom: why not put the stats method on the track object itself?

   adam: +1

   adam: it can remain as an ended or finished track

   <fluffy> I like HTA idea of never removing a track

   jonathan lennox: there are post-repair stats for RTCP

   scribe: there are also multiple remotes. result of tomorrow's
   discussions may make this more complex

   hta: don't want to support transport relays on multicast in v1
   or rule out doing it in the distant future
   ... with multi-stream tracks, how do I count only once even
   though only sent once

   ted: just count once. if you count for a particular track, you
   are right. However, adding up counts for all tracks will not
   add up to the number of bytes sent. Not a problem as long as
   app author knows what they did

   justin: track in multiple streams might be sent more than once
   due to different encodings

   randell: could be different processing on tracks too

   justin: should show up multiple times

   hta: maybe instead of MediaStreamTrack as selector, could query
   track for what to query to find out about its stats. Then ask
   PC for the info.

   anant: what is same stream/track is added to multiple peer
   connections

   cullen: sounds too complicated. better just to know what are
   all the objects to query

   stefan: why can't this go on the track?
   ... its all on the receiving side

   (several): disagree

   stefan: then the sides need to agree in advance on this info

   hta: yes, RTCP

   magnus: need a clear model for how to handle multiple encodings
   of same media source.

   justin: on remote side, what would they see if you had
   different encondings? Two tracks, right? Because different
   SSRCs. Maybe then we need to clone track rather than using
   multiple times

   cullen: this would get with propagating use up to gUM for
   camera changes, etc.

   (missed some)

   randell: adding add'l semantics on top of media stream tracks
   that already exist.
   ... network media tracks add info on local streams/tracks
   ... tracks in PC are not necessarily the same as those returned
   from getUSerMedia

   anant: make media stream tracks immutable so you can't change
   their characteristics after creation. it has fixed properties.
   if you want to display different resolutions in different
   images, then those are different tracks. can derive one track
   from another.

   justin: but if want to change resolution, will need to create a
   brand new track.

   ekr: what if other side changes resolution

   justin: benefit of making immutable? 1-1 identity is nice, but
   why does that mean you can't change an existing track

   anant: avoids having to change constraints that may conflict
   for derived tracks, where we would have to distinguish between
   changeable params and others that arent

   <Martin_> I was observing that there are four MediaStream
   sub-types; LocalIdealMediaStream, LocalPacketizedMediaStream,
   RemoteIdealMediaStream, RemotePacketizedMediaStream

   anant: can deal with remote changes differently

   randell: if track is sourced from video element,
   source-encoded, then you change the track?

   derf: this could happen at every keyframe!!!

   anant: should be forced to create a new track if
   characteristics change

   justin: can happen just by grabbing scroll handle

   randel: encoder might do this itself

   anant: SDP doesn't have all that?

   (several): no

   jimb: perhaps anything is SDP shouldn't be changeable, but
   everything else is okay?

   cullen: SDP does specify an envelope within which you can
   operate. I would still expect to be able to change SDP

   randell: request resolution changes may be able to happen
   without SDP changes, sometimes might.

   ekr: benefit of immutable?

   anant: video has fixed size. video doesn't know hat resolution
   is being received on track. more complex now in fixed output if
   track is changing under the covers.

   randell: already handled today

   justin: happens for html you download too
   ... want to avoid downscaling

   randell: always latency between UI resize and change in the
   source. ALso may not cause a resize (say if different parties
   have different sizes for same stream)

   justin: may go from small to large display and need fuller
   sending, but that doesn't change other small images.
   ... many reasons for this

   <fluffy> I want to insert myself on Q

   stefanwenger: may or may not be value of renegotation for
   change of resolution, but there are *many* SDP params that can
   change (framerate) during stream lifetime
   ... idea that stuff that sits in SDP without renegotiation not
   true for 264 and, i believe, VP8

   cullen: we agree that two different windows is two tarkc
   objects. we just don't agree with immutability of a track

   jimb: what is immutability? can a track change from audio to
   video? of course not, so that's one kind of immutability

   hta: will modify proposal to have another layer of indirection
   so that in simple case we can get just one piece of info back
   but to allow more complexity

   dom: question about privacy. some of the info available (remote
   ip and port) might be additional.

   hta: don't see anything yet that hadn't already been exposed
   ... did say that data must be possible to be anonymized

   anant: API is getStats, callback. Perhaps instead should be
   event that can be registered for regular returns

   hta: concerned about timers that no one is still around to
   listen to

   richard: RTCP also has application data that should be returned
   / received

   randell: data channel API would be better way to transmit such
   info.

   hta: if we find later that there is other info available in
   browser that other browser needs, RTP may be way to communicate
   it
   ... application data has multiple meanings

   <fluffy> +1 lenox

   lennox: app data is stuff for your app, not something
   standardized. if standardized, not "application data"

   ddruta: question about remote sources for stats. where does app
   connect.

   hta: whatever is sending RTCP reports .

   druta: should we have param that specifies URI?

   hta: perhaps could extend that way, but I need to see the use
   case before we go beyond remote browser

   stefan: what's next?

   hta: will come up with new proposal that can handle multiple
   stats per track.

   dom: will be separate spec, or part of main one?

   hta: if quick, should be part of main doc

   <scribe> scribe: DanD

Data API

   <dom> [31]P2P Data API slides

     [31]
http://www.w3.org/2011/04/webrtc/wiki/images/4/45/WebRTC_interim-june-2012_Data_API.pdf

   adambe: [Showing example from the slides]

   adambe: example creating a datachannel with an active
   peerconnection

   fluffy: We need to add the same thing that we do for media for
   data

   jesup: there will be no offer answer for datachannel

   fluffy: I'm on board with this proposal

   anant: Complicates the case as it combines the everything in
   one connection

   adambe: we talked about negotiation call back
   ... you will only have to create an offer for the first channel

   Richard: Why isn't data treated like the other media?

   hta: We had this discussion on the mailing list

   dom: there are differences between media and data

   hta: I proposed for unichannels for datachannel

   Richard: It seams to be the need to create a construct
   datachannels

   fluffy: we need to write down and we need to negotiate the
   lines in SDP. We're going in the right direction

   adambe: You are right. It can be a container for multiple
   datachannels

   fluffy: how do I know how to receive datachannels?

   <fluffy> @dan - you get a callback on the PeerConnection that
   tells you there is a new data stream

   <fluffy> you need some out of band info to know what it might
   contain

   <fluffy> I think we can do a little better than that

   Ted: I agree with Cullen. Designing it on the fly in the room
   is not productive

   jesup: I can write up a proposal

   adambe: we have a facility but is not in Javascript

   <dom> ACTION: Jesup to write up possible directions for
   datachannels in peerconnection and relationship with media
   streams/tracks [recorded in
   [32]http://www.w3.org/2012/06/11-webrtc-minutes.html#action09]

   <trackbot> Sorry, couldn't find user - Jesup

   burn: It seams that we're treating datachannel as a track
   ... we don't have a container to hold all the datachannel

   <dom> ACTION: Stefan to pester Jesup to write up possible
   directions for datachannels in peerconnection and relationship
   with media streams/tracks [recorded in
   [33]http://www.w3.org/2012/06/11-webrtc-minutes.html#action10]

   <trackbot> Created ACTION-48 - Pester Jesup to write up
   possible directions for datachannels in peerconnection and
   relationship with media streams/tracks [on Stefan Håkansson -
   due 2012-06-18].

   justin: datachannels are very application specific

   fluffy: I'd like to challenge this. CLUE might be able to use
   this

   hta: We need to add the use case for data channel
   standardidation

   jesup: going over the slides

   <dom> [34]Data Channel Issues, slides by Jesup Randell

     [34]
http://lists.w3.org/Archives/Public/public-webrtc/2012Jun/att-0063/W3_Interim_June_2012_Data_Channel.pdf

   jesup: Open Issues are when can you send data on the
   datachannel

   jesup: Second issue is when can we call create datachannel

   adambe: how can I connect datachannel if I don't have a
   peerconnection?

   dom: p2p data is very useful for developers with or without
   media
   ... we should not make the assumption that media is used

   jesup: proposal to create offer
   ... to create datachannel before createoffer

   ekr: We need a datachannel container as burn suggested

   ekr: It is an expessive task

   jesup: renegotiation need is application specific

   Stefan: you cannot treat renegotiation needed with delay

   Richard: If we don't have a construct for data channels
   ... first datachannel is special

   <dom> (note that data channels have at least two different
   types: reliable and non-reliable; I'm not sure how that is
   dealt with when some channels are reliable, and others are not)

   Ted: We have to consider resource utilization (radio) when
   keeping these datachannels alive

   jesup: If you decide you're done with the datachannel you can
   drop it
   ... when there's no data it makes sense to shut it down. If you
   do shut it down you're left with nothing. Back to square 0
   ... I don't have an objection

   Paul: to support exposing this object. If there are errors
   there's no place to report them

   fluffy: agreed with the error handling and add statistics to
   the case

   burn: I'd like to see this explicit object.

   <Martin_> from far enough away, everything looks the same

   burn: from an API perspective it looks like a track

   hta: doesn't really match

   JonLennox: You need to know that you can't create the objects

   <dom> have we come to a conclusion about the mystery data track
   object? is this discussion part of Randell's previous action
   item

   jesup: THe question is when can you call Send (from the slide
   proposal)
   ... if we allow before send we can reuse code written for
   websockets

   fluffy: I'm not worried about interoperability with websockets.
   More interested on error handling

   jesup: being application specific, application can figure out

   hta: if app really needs this it can build it. If you don't
   have early data it can fake it. I don't favor early data

   JonLennox: it's not clear to me what's the different between
   I'm connected and I can't send data to I just can't send data

   Ted: There's no such thing as early data. It's just data

   jesup: I you can create the connection before, better

   hta: should we poll for this?
   ... a lot of people have oppinions
   ... decision not to support early data
   ... coffee break

   Stefan: there was support for container

   <dom> ACTION: Adam to work with Randell on a proposal for a
   data channel container [recorded in
   [35]http://www.w3.org/2012/06/11-webrtc-minutes.html#action11]

   <trackbot> Created ACTION-49 - Work with Randell on a proposal
   for a data channel container [on Adam Bergkvist - due
   2012-06-18].

   <stefanh_> scribe: stefanh_

   First topic after coffee:

Report on status Audio WG.

   [36]WebRTC & testing slides

     [36] http://www.w3.org/2012/Talks/dhm-webrtc-testing/#%281%29

   dom: THere has been some controversy over what API to pick from
   two proposals.

   However, now the group has agreed on one API: the Web Audio API

WebRTC & testing

   dom: Next steps as we continue develop the APIs.

   Document stages FPWD LCWD (several of them usually) CR

   At CR we have to prove that the spec is implementable

   and that different implementations implement the spec in the
   same way

   testsuites are created for this purpose

   one or more testcases for each MUST in the spec

   <burn> scribe: burn

   dom: similarly for MUST NOT
   ... why do we need to do this? of course the process requires
   it, but more importantly interoperability is crucial for
   adoption and success of standards
   ... additionally, writing test cases *REALLY* exercises the
   spec language, pointing out where interpretations need to be
   clarified
   ... Although test cases are required for Candidate
   Recommendation, it's best to start as soon as the spec begins
   to stabilize. There is an obvious trade-off between getting it
   done early and being forced to update tests often as the spec
   changes.
   ... but tests can be written for stable parts of the spec. Some
   people/orgs are test-driven, requiring a test to be provided
   for every change request, but this can result in many changes.
   ... Best is not to wait too long. We should set up the testing
   framework before Last Call, and ideally begin writing tests as
   well.
   ... Often no one in the group wants to write tests. However,
   often others outside the group find it fun. It is a great way
   to improve the specification and does not require agreeing to
   the intellectual property statements that members must agree
   to.
   ... It's also a good way to really understand how the spec
   works -- if you can't write a test for it, the problem may be
   with the spec.
   ... Best practice is to have one or more test facilitator(s)
   per spec to oversee work. The facilitators do not have to write
   all the tests, just ensure they are written properly, getting
   done, etc.
   ... Most JS-based working groups now use testharness.js
   (assertion-building primitives), with a repository per spec in
   dvcs.w3.org. Each group needs to decide on the process for
   submission and review.
   ... Process could be "submit, review, approve" or "submit,
   approved" until proved wrong. If there is a formal review
   process details about the review need to be defined in advance.

   burn: review process does not have to be laborious or complex.
   can just have writers review other writers' tests, and vice
   versa.

   dom: (now showing test case(s) he wrote for getUserMedia)

   dvcs.w3.org/hg/media-capture/file/de85fe3f590f/submitted/W3C/
   (if I got it right)

   (now looking at
   dvcs.w3.org/hg/media-capture/file/de85fe3f590f/submitted/W3C/vi
   deo.html)

   dom: library provides two different kinds of tests: synchronous
   and asynchronous

   dom: in this example, he calls getUserMedia and verifies three
   assertions: there is a LocalMediaStream, no audio tracks were
   returned, and at least one video track was returned.

   anant: why do you call t.step inside the callback?

   dom: that might be a bug.

   hta: what's the procedure for running these against
   implementations?

   dom: browsers usuallly run the tests on their own. If they
   don't pass and they think the test or the spec is wrong, they
   then contact the WG
   ... also, the second js library allows for integration into
   various test frameworks for automated testing (for tests that
   do not require human judgement)
   ... Now for specifics for WebRTC. First, how do you test
   constraints interoperable? Second, how do you have peers to
   connect to? Also server-side components that we may need ref
   implementations for. We also need to make sure there is not a
   failure in the protocol itself (beyond the API).

   JonLennox: if ICE connection fails, need to do XXX. These kinds
   of tests are needed as well.

   dom: yes, network conditions need to be simulated as well.

   <stefanh_> scribe: stefanh_

   juberti: should we create a sw test harness with virtual input
   devices virtual network etc.?

   hta: dom is already in contact with chrome test people

   ekr: we will do this for firefox

   cullen: when the discussion starts we can contribute

   <dom> Scribe: dom

   hta: we're expecting a Mozilla volonteer for testing!

Back to JSEP

   adambe: we talked about sdptype on media description
   ... you could set the type as provisional either as a param to
   createAnswer, or by setting the attribute in the generated
   answer

   justin: as far as I know, the only meaning of provisioning vs
   final answer,
   ... the final answer ends the offer/answer exchange
   ... it only affects the state machine, not the actual
   offers/answers that are generated
   ... so the only effect of that parameter would be to set the
   type to pranswer
   ... based on previous discussions, we have already identified
   that the type attribute needs to be mutable
   ... I also object to this ad-hoc parameter on the method

   ekr: I think I agree with Justin here

   cullen: setLocal would behave different with pranswer
   ... I would put it as a constraint

   richard: there seems to be a potential need for the answer to
   inform the offer
   ... whether or not the intention behind it is provisional or
   not

   martin: the decision is always made by the application

   justin: it actually matters: there are some cases in which
   treating an answer as a pranswer is ok, but it's not ok to
   treat a pranswer as an answer

   richard: OK from which perspective?

   justin: at the callee side, the person generating the answer,
   the app decides whether to mark it as a pranswer or an answer
   ... the caller receives something; if he deals with a pranswer
   as an answer that's bad

   justin: it's probably OK in the reverse

   richard: in SIP, pranswers are not exposed

   justin: if a caller treats an answer as a pranswer, then the
   callee assumes that the state machine is in a stable state when
   it is not

   adambe: to summarize, we can either treat is as a constraint,
   or use the fact that the type attribute is mutable in the offer
   object
   ... so, should we have a constraint for it?

   justin: a constraint would probably be fine

   dom: what would we need several ways to do this?

   cullen: linked to error handling
   ... this depends on things we haven't looked at, so I don't
   think we can really make a decision

   ekr: if it turns out we need to know that type, I don't think
   we should stuff into constraints
   ... It really doesn't seem like a constraint

   <ekr> What I'm saying is that if we do decide we need this,
   putting it in a constraint seems pretty gross

   <ekr> it's not clear to me why it's any better than an extra
   argument

   <ekr> Obviously, it's just a taste issue

   adambe: so, we remove the additional argument; if we need it as
   a constraint, we'll add it back later

   [discussion about the value of constraints as a host for this]

   justin: I would prefer we avoid a bunch of positional
   parameters
   ... a dictionary with options would be much better

   dan: constraints were not designed for parameters

   adambe: yeah, I think we should have a settings dictionary

   <scribe> ACTION: adam to look at replacing mediaconstraints in
   createAnswer with a settings dictionary [recorded in
   [37]http://www.w3.org/2012/06/11-webrtc-minutes.html#action12]

   <trackbot> Created ACTION-50 - Look at replacing
   mediaconstraints in createAnswer with a settings dictionary [on
   Adam Bergkvist - due 2012-06-18].

   harald: what on earth does it mean for the error callback to be
   optional?
   ... I see no reason to make it optional since the app stops
   when error occurs

   anant: continuation would help here as well

   martin: this is similar with things done e.g. in XHR

   <Martin_> setTimeout

   tim: making it required would at least raise the chances that
   people copy & pasting the code would deal with error

   anant: another approach is to deal with errors as part of a
   single callback signature à la node.js

   <Martin_> node.js uses doSomething(function(err, value) { });
   It's a nice pattern.

   adambe: moving on to ICE Restart
   ... should we have an explicit updateIce() method to reset the
   IceServers configuration

   justin: in RFC@@@ says that restarting ICE is done by changing
   @@@

   <stefanh> scribe: stefanh

   <JonLennox> RFC 5245, changing ufrag and password

   discussion on restart ice

   usernam+password change

   (scribe a bit lost)

   general design: most apps will never call update ICE

   but what drove is that an app might be after a while willing to
   supply non-realay candidates

   Ted: is there not a need to be able to restart ICE but the app
   does not supply username+frag

   justin: what we need

   api call "generate new one and restart ice"

   the new username+password must be supplied to the server

   adambe: can the server even generate all info?

   does it have all info (like msid)?

   thompson: an advanced server can do this

   justin: we don't need the extra parameter

   magnusw: can someone tell me how this works if it is the
   browser that detects that an ICE restart is needed.

   cullen: "onrennegotiaonfeedback" signals this.

   lennox: new I/F available: should signal to app

   what if you have a perfectly usable 2G connection but moves
   into WiFi coverage

   what should happen

   should be discussed tomorrow

   justin: what should happen when new candidates are trickled
   10min after start?

   cullen: what is the difference betwenn a mandatory constraint
   and a setting?

   <JonLennox> The logic I understood of ICE was that once you
   converge, the way you change in the future is to do an "ICE
   Restart". The old selected pair is still live until a new pair
   is selected.

   cullen asking for guidance on settings/constraints/dictonaries

   ekr: should we replace parameters with dictonaries

   cullen: editors will take liberties and wait for yelling

   hta: chairs to bring back to rtcweb that how interface changes
   happen is unclear

   RESOLUTION: IceRestart to be removed

   <JonLennox> RFC 5245 9.1.2.1 "Existing Media Streams with ICE
   Running" is equivalent to trickle candidates before ICE has
   completed; 9.1.2.2 "…with ICE Completed" says you have to send
   the existing selected candidate unless you're doing an ICE
   Restart.

   <JonLennox> 9.1.1 "ICE Restarts" says "during the restart,
   media can continue to be sent to the previously validated
   pair."

   <JonLennox> So adding a candidate is an ICE restart; you keep
   using the old selected pair until the restart succeeds.

   <Martin_> JonLennox, does this imply that you need to gather on
   the existing network interfaces, or retry connectivity checks
   on previously failed candidates?

   <JonLennox> You can reuse the existing gather state if you want
   for the successful candidates, or re-gather. Whether you
   re-check previously failed candidates is a local decision,
   depending on whether you have some reason they'll start working
   now.

   setRemote/setLocal should accept the union of object andf
   string

   <Martin_> correct :)

   <JonLennox> What candidates to gather is the part of ICE that's
   the most subject to implementation choice

   <JonLennox> But the point is that once you're in the "ICE
   Completed" state the only way to change your set of candidates
   is through an ICE Restart.

   <JonLennox> From a w3c pov the interesting question is whether
   it's the application or the browser that needs to decide
   whether and when to do a re-gather.

   <JonLennox> (And how)

   <Martin_> The next trick is working out a) how to trigger ICE
   restart and b) how to discover that an ICE restart is needed...

   <Martin_> I think we have a, but I think we realize that we
   also need b

   <JonLennox> needed in a broad sense, including "possibly
   desirable"

   DanB: you usuall have to touch the SDP when interoprating

   <Martin_> exactly

   anant: important to define for the normal web developer.

   hta: we need to know what SDP things you'd like to munge before
   starting design an API for it

   <Martin_> of course, if you go to the trouble of enumerating
   your use cases so precisely, you might as well drop the SDP
   altogether and build APIs for each use case. Understanding the
   use case is the hard part, designing APIs is easy.

Summary of Action Items

   [NEW] ACTION: 39 to repsec2 move [recorded in
   [38]http://www.w3.org/2012/06/11-webrtc-minutes.html#action01]
   [NEW] ACTION: adam to look at replacing mediaconstraints in
   createAnswer with a settings dictionary [recorded in
   [39]http://www.w3.org/2012/06/11-webrtc-minutes.html#action12]
   [NEW] ACTION: adam to move SessionDescription and IceCandidate
   out of the global namespace [recorded in
   [40]http://www.w3.org/2012/06/11-webrtc-minutes.html#action02]
   [NEW] ACTION: Adam to work with Randell on a proposal for a
   data channel container [recorded in
   [41]http://www.w3.org/2012/06/11-webrtc-minutes.html#action11]
   [NEW] ACTION: Anant to provide a code example showing
   continuation for createAnswer [recorded in
   [42]http://www.w3.org/2012/06/11-webrtc-minutes.html#action08]
   [NEW] ACTION: anant to write up a spec for IceServer object,
   and compare [recorded in
   [43]http://www.w3.org/2012/06/11-webrtc-minutes.html#action07]
   [NEW] ACTION: cullen to annotate the callflow diagram with
   events fired [recorded in
   [44]http://www.w3.org/2012/06/11-webrtc-minutes.html#action06]
   [NEW] ACTION: cullen to deep dive on setRemoteDescription with
   justin [recorded in
   [45]http://www.w3.org/2012/06/11-webrtc-minutes.html#action05]
   [NEW] ACTION: Jesup to write up possible directions for
   datachannels in peerconnection and relationship with media
   streams/tracks [recorded in
   [46]http://www.w3.org/2012/06/11-webrtc-minutes.html#action09]
   [NEW] ACTION: juberti to deep dive on setRemoteDescription with
   cullen [recorded in
   [47]http://www.w3.org/2012/06/11-webrtc-minutes.html#action03]
   [NEW] ACTION: justin to deep dive on setRemoteDescription with
   cullen [recorded in
   [48]http://www.w3.org/2012/06/11-webrtc-minutes.html#action04]
   [NEW] ACTION: Stefan to pester Jesup to write up possible
   directions for datachannels in peerconnection and relationship
   with media streams/tracks [recorded in
   [49]http://www.w3.org/2012/06/11-webrtc-minutes.html#action10]

   [End of minutes]
Received on Tuesday, 12 June 2012 09:59:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 12 June 2012 09:59:17 GMT