- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Tue, 12 Jun 2012 11:54:38 +0200
- 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 UTC