- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Thu, 30 Aug 2012 11:39:16 +0200
- To: public-webrtc@w3.org
Hi,
The draft minutes of our call yesterday (Aug 28) are available at:
http://www.w3.org/2012/08/28-webrtc-minutes.html
and copied as text below.
Please send corrections to the list.
Dom
Web Real-Time Communications Working Group Teleconference
28 Aug 2012
[2]Agenda
[2]
http://lists.w3.org/Archives/Public/public-webrtc/2012Aug/0200.html
See also: [3]IRC log
[3] http://www.w3.org/2012/08/28-webrtc-irc
Attendees
Present
[GVoice], +1.403.244.aaaa, fluffy, +1.215.681.aabb,
Dan_Burnett, stefanh, Dan Romanescu, DanDruta,
nstratford, hta, +33.6.85.56.aaee, +358.405.60aaff,
+1.630.423.aagg, +1.425.893.aahh, +1.503.712.aaii,
adambe, juberti, Jim_Barnett, +1.908.541.aajj, dom,
+1.469.277.aakk, +1.650.678.aall, +358.505.22aamm,
+1.831.440.aaoo, ekr, anant, christer, Spencer_Dawkins,
+1.610.889.aapp, Li, markus, Jerome, +91.80.33.41.aaqq,
+46.1.07.13.aarr, Martin, +972.9.957.aatt, rillian,
+1.215.681.aavv, tim_panton, milan_patel
Regrets
Chair
StefanH, Harald
Scribe
burn
Contents
* [4]Topics
1. [5]Minutes approval
2. [6]MS CU-WebRTC proposal
* [7]Summary of Action Items
__________________________________________________________
<dom> scribenick: adambe
Minutes approval
stefanh: first, aprove minutes from last meeting
<stefanh> minutes:
[8]http://lists.w3.org/Archives/Public/public-webrtc/2012Jun/00
87.html
[8]
http://lists.w3.org/Archives/Public/public-webrtc/2012Jun/0087.html
stefanh: does anyone object to the minutes?
... I guess they are aproaved
stefanh: should we move on to the walkthrogh of the MS API
proposal
<burn> Agenda:
[9]http://lists.w3.org/Archives/Public/public-webrtc/2012Aug/02
00.html
[9]
http://lists.w3.org/Archives/Public/public-webrtc/2012Aug/0200.html
MS CU-WebRTC proposal
hta: everyone has looked at it and people have commented on it
... today I've seen a desire to break the proposal up into
smaller parts
... which can be addressed
stefanh: we give the floor to martin
fluffy: I'm confused, what do we want to acomplish with this?
... what I saw on the agenda was to discuss the CURTCWeb stuff
... what I just heard was not that
hta: lets hear what the MS people want to present
fluffy: we need to say if we're changing the agenda
stefanh: let the MS guys present
hta: do we have the slides
... ?
<dom> [10]MS slides
[10]
http://lists.w3.org/Archives/Public/www-archive/2012Aug/att-0032/Curtsy_Web_Overview.pdf
stefanh: is someone from MS here?
martin: 2nd slide describes what we saw was going on with the
current work
... PeerConnection claims to be several things that it's not
[scribed lost a lot of things here]
scribe: on slide 3
fluffy: I don't things the points on slide 2 is right
martin: we should discuss this on the list
fluffy: I would have sent comments if I had seen the slides
earlier
martin: MSID is soley for this API
... multiplexing issues have not been resolved yet
... when you build this API for SDP it need a lot of things
that are not specified in SDP
... we think it's necessary to know what version of SDP
browsers will implement
... moving on to slide 4
martin: the lot of work is talking about signaling
... we don't think it's in the scope of this work
... slide 5 shows the propoed architecture
... there are three pieces
... first part, abstract streams
... getUserMedia() is good
... the media part with media streams serialized into the
network
... and the transport part with ICE...
... slide 7 is about RealTimePorts
... which represents candidates
<juberti> PeerConnection has the same relationships, they are
just wired together with different APIs.
martin: slide 8 talks about RealTimeTransport
... does ongingn concent checking and so on
... the RealTimeMediaStream is what sends packets
... the MediaDescription represents a single m-line
... it also provides a simple negotiation feature
... slide 11
fluffy: how is MediaDescription different compared to SDP
... is it more powerful?
martin: SDP describes an entire session
martin: MediaDescription describes a single m-line
... this is intended to say that this is a single stream
... it is what is necessary to get a single stream over the
network
... SDP covers many things
... it also has a concept of bidirectional media
fluffy: how do you interop with legacy without bidirectional?
martin: if you can enumerate the problems, it could be helpful
fluffy: hard to get this workingn without a media translator
martin: slide 11
... is the stuff that we didn't include in this proposal
... the data chanel
... we didn't see where it was going
... DTMF
... will follow up on the list with that one
... slide 13 is the sum of the deltas we identified
... there may be more
... not sure we need to bring those up
ekr: I have a question on this list
<dom> [ekr asks about "Control connection establishment based
on certificate"]
<dom> ["H.264 SVC support"]
[scribed lost a lot of stuff here]
discussion is about splitting SDP up
between MediaStream and PeerConnection
<ekr> I am about to summarize what I think has happened so far.
<ekr> scribe:ekr
matthew: H.264 SVC interacts badly with bundle and some other
stuff vis-a-vis SDP
fluffy: what does this do that you can't do with the mid-level
API
matthew: same answer as last time, we're worried about future
flexibility
matthew: this is a set of changes, some of which are
noncontroversial and some of which aren't. there may be room
for compromise
<matthew> i'm here now
matthew: obviously we would prefer to get rid of SDP entirely,
but even if we didn't do that, we think it would be good to
split up PC into transport and media negotiation. if you
absolutely had to you could make the interface to media
negotiation be SDP. See slide 5
<burn> scribe:burn
(missed something)
fluffy: bundle and svc together did not have problems in our
review. they definitely have to work together
<jesup> Let's move forward...
<hta> burn, the question is with H.264 and Bundle, and
interactions - this is a problem for IETF MMUSIC, and it has
not been raised over there.
fluffy: OK, what does that do for you?
fluffy: what are advantages of splitting SDP as you suggest on
slide?
matthew: don't see low/mid distinction. rather, things are
mixed together. prefer better split into transport and media
stream
<gape> I asked for reasons for skipping SDP- poor syntax and/or
semantics or not providing for interoperability.
juberti: in many cases all streams will go through same link,
so this is not necessarily cleaner. also doesn't interop well.
matthew: ip multicast reception in browsers easier in our model
juberti: maybe we can extend what we have in a declarative
manner. why do we need to restructure everything?
matthew: when you do SDP o/a can't send new offer until
existing has been replied to, etc. using sdp at all determines
how you talk about ICE candidates, etc.
... one possibility is direction we are going now -- will use
SDP o/a but if something inconvenient shows up we'll ignore it,
allowing overlapping offers, trickle ICE, identity to
DTLS-SRTP, etc.
... these are actual semantic changes so it is no longer SDP at
all
... if we are going to break SDP, why use SDP at all?
cullen: how are we in violation of SDP?
matthew: you can send offers while in an exchange already
juberti: no requirement that everything is 3264 compliant, but
can do that if you want
stefan: we are deep in the weeds here, should we refer to
another time for this?
ekr: this is important, and any decision here affects
everything else we do.
cullen: we have discussed all this before (for years).
splitting SDP is not even in MS proposal.
... major outcome of this is that it will stall us for 6
months. Better to discuss now and make a decision.
anant: agree we need to discuss now
<jesup> agreed, discuss
<juberti> agree
<ekr> yes, it was anant
<gape> yes, discuss now...
<mreavy> please discuss
cullen: issue is what are limitations of sdp. any system where
you want to minimize time before playing media, to get ready in
advance, will have characteristics of bad things happening if
you change media planned.
... offer/answer is necessary.
matthew: if using sdp o/a, then do so. No hacks for trickle
ice, multiple offers, etc.
... since api ends up getting cluttered, why not create
something clean from the beginning?
cullen: we are making all these things part of SDP
martin: some of the things stated were wrong. do not need to
have a single controller per path
... "make before break" is possible in the proposal
ekr: interesting comment from matthew about messing up sdp.
because we can't do some things in SDP today, we will extend
SDP with capabilities like bundle that allow for interop while
giving more functionality
<matthew> extend SDP = ok. screw with the offer/answer semantic
and claiming it is still O/A = not ok.
ekr: are we breaking semantics of SDP? I don't know. But adding
extensions as we always have is reasonable.
<matthew> once it isn't SDP O/A, we should stop saying it is.
*then*, given that there's also a bunch of ugliness about SDP
as an *API surface*, why keep it?
<ekr> matthew, that's the thing I am trying to get at, are we
not doing O/A?
<ekr> I thought we in fact were.
fluffy: wasn't make before break, it's early media. any system
where you advertise that media can be sent, if you change that
without notifying there is no way around that.
<matthew> the API not only allows, but encourages not doing O/A
in order to achieve its goals
martin: correct. with DTLS not possible to do that without
signaling path do a round trip.
cullen: disagree
<ekr> I am also not clear on this...
<ekr> sorry about that.
cullen: if want to receive media as soon as received offer,
have to notify of a change or will fail
<ekr> yes, I was the person who violated queue. I apologize
hta: if you want things to interact without going through JS,
need an object that contains both. breaking up as in MS
proposal doesn't do this, but peer connection does
fluffy: on SDP issues, we are using SDP. We are trying to
extend it to accomplish what we need. MS proposal doesn't meet
current use cases. Still need viable alternative to SDP
martin: hta said we need a container. maybe that's the browser.
cullen says API insufficient. Such use cases don't seem to be
documented in any drafts.
matthew: regarding container, if two things that interact must
be in the same container, then media stream and track need to
be in peer connection as well.
... we split transport from media stream because they are
useful that way. numerous use cases that don't involve sending
things outside the browser.
juberti: want to see a use case where separate objects can do
something that PC cannot. PC represents a session, which has
existed for all of telephony. Nice grouping semantics for
congestion control, easy for developers to understand.
juberti: about your deltas, most if not all of these could be
added to PC. Would it be useful to see how we might add these
to peer connection?
ekr: architectural purity seems to be main argument. i want to
know what this lets me do that i can't already do.
... need concrete example of something hard to do with existing
API.
<matthew> i'll need to get on this long list to answer that
hta: need multiple PC to connect multiple people.
<ekr> matthew, you're welcome :)
<matthew> maybe i'll still wait :)
<ekr> I have no idea what tim is saying.
<martin> opus
<jesup> G.729 ;-)
tim_panton: architecutural purity is a valid goal. hard to know
when to say we need to start over. (lost the rest)
<jesup> tim_panton: you may want to summarize what you said for
those who couldn't hear
fluffy: which of these deltas are we doing or could do?
... (goes through list quickly)
<ekr> BTW, I'm not suggesting that I'm not in favor of purity
<ekr> but it's not the only thing
fluffy: if SDP can't deal with 264 needs to be dealt with, but
not by this group.
<tim_panton> (So what you missed is the question - If a
radically new api is inevitable, we should start sooner rather
than later)
fluffy: we are largely working on all these items
stefanh: re purity/modularity, not sure the MS proposal is
really all that easy to use based on some prototyping we did.
way more objects to track than with current API
<ekr> stefanh, I am not sure about that, either
matthew: security desc would be SDES. required for EKT. will
answer other questions on the list.
juberti: agree with cullen's review. Most are things to be
added we just haven't gotten to yet. If we focus on SDP vs. JS
object that is easier to manipulate, also offer/answer are two
topics we need to focus on.
... would help working group
fluffy: elephant in room is whether IE will implement this. can
anyone answer?
matthew: can't answer, but can say that we believe that it is
possible to implement JSEP in terms of our proposal as a JS
library.
... also believe our API more useful for certain apps we may
want to build in the future.
<juberti> fair enough
matthew: in addiition to what justin said, also question of PC
as monolithic object. regarding more objects in new proposal,
we find it easier. being separate from PC makes API much
cleaner for multicast (and something else I missed)
<ekr> matthew, since when are you in favor of multicast
anything?
matthew: don't have to go to multiple objects, but it's
cleaner. will be better for apps 5-10 years from now.
<tim_panton> kinda like turing machine.
matthew: not that you can't use current approach, just ugly.
Today have to read and parse SDP, etc. to accomplish
everything. Better to have a clean architecture
... now that we're not using SDP, should make a clean break.
stefanh: we had set milestones for this group. they may be
optimistic, but we are under pressure to make progress. we need
solid use cases to make a major change at this point, or
recharter the group under a different schedule.
<martin> yes, we have done the analysis
anant: has MS team analyzed security risk of allowing web page
to have low-level access like opening a UDP socket
<matthew> i can answer this, or when i'm on queue
<matthew> this is exactly the same level of security as the
existing peerconnection
<martin> exactly the same
anant: even if safe, dangerous to design open-ended API. With
PC we know exactly what its purpose is. audio, video, and data
channels associated with PC. without concrete use cases in mind
today, too dangerous to do this today.
<ekr> martin, I'm not completely sold on this.
<ekr> (this == security)
<matthew> and if we want to bring up websocket, i'd love to
comment about "shipping broken things now and fixed things
later" vs "wait until specification is complete"
<ekr> you might tbe right
<ekr> but I'd like to see an analysis
<matthew> ekr, come work for MS :)
jesup: some aspects of this are interesting. use cases have
been alluded to that this makes easier, but even with pushing
now we haven't heard them. ultimately we will need to see these
use cases in order to consider this.
<anant> matthew, I disagree that the existing API is broken.
For what purpose is it broken?
<matthew> anant, i didn't say that the existing API was broken.
but if you think that's what i was talking about, perhaps
you're concerned it is?
jesup: we should move forward today as we have been. if we want
more purity, we can add those APIs in addition separately.
These don't have to be contradictory, esp. if JSEP can be
implemented on top of low-level.
<anant> matthew, no, I was simply going to say that the
question of shipping broken things now vs. waiting until a spec
is complete is irrelevant at this point
<matthew> anant, some folks did it for websocket
juberti: +1 jesup. we need one API. we can layer others on top
with JS, but otherwise multiple APIs will just confuse
developers.
<matthew> anant: so it appears to be a popular thing to do
<anant> matthew: yes, it was done for websockets, but my belief
is that we're not doing the same for PeerConnection
<matthew> TBD
<anant> of course, but that would be true of RealtimeTransport
too :)
<hta> burn, this is an architectural problem if later APIs
should expose lower layers than earlier APIs.
juberti: we started assuming that we needed it to work for
non-experts. Samples for CU-RTCWeb seem to require much more
understanding under the covers. Do we want to drop this
assumption?
<anant> nothing survives the brunt of actually shipping
<martin> umm, thanks, but I wasn't finished,
fluffy: from a taste/preference perspective, think current API
is simpler. also, all of CU-RTCWeb can be implemented on top of
JSEP.
<matthew> martin said q- before he started talking, but got
stepped on
<mreavy> the speaker queue is closed but i want to say that
it's important that our work can be used by non-experts.
<ekr> matthew, could you share that analysis?
matthew: lower-level API has same security characteristics. MS
has conducted a security analysis -- conclusion is it's
identical.
<ekr> Like the details, not the conclusion?
<fluffy> I think the question about security also had to do
with privacy issues
<ekr> I'm inclined to agree with you, but you know I like
reading this kind of thing.
<matthew> ekr, i'll see what i can do for the group
martin: at which point in the extension process do you decide
that it's too ugly?
<tim_panton> I'll type +1 for what martin just said about the
beast…. It is _always_ good to have a well designed open api.
SDP isn't one. As far as use cases -> Who expected the first
best use of PeerConnection to be a competitive tile game? We
really can't be dependent on our legacy use case. To Cullen's
point - the current stuff isn't _that_ tidy, we have had to dig
deep into SDP to get what we want.
<tim_panton> can someone voice that for me?
<matthew> agree with martin. optimizing for naive developers at
this point is a questionable driver, given the alternative
drivers like "clean and extensible API, usable for future use
cases"
<matthew> especially since "naive developers" will get tripped
up right away when we start talking trickle ICE, SDP changes
required for interoperation, etc.
stefan: seems to be some consensus to look into the proposals
for adding features based on use case needs. not hearing huge
support for replacing current API with CU-RTCWeb.
<matthew> meanwhile, when we get to the ICE API deck, if ever,
i'll want (as i said on the list) the 3rd option discussed
<mreavy> there's a big difference between non-expert and naive
developer
stefan: matthew submitted list of things he doesn't think work
with current API, so we should look at the list.
cullen: we are already doing this.
<anant> mreavy++, the last thing on even a veteran web
developer
<tim_panton> I support it.
<anant> 's mind is how to be setting up ports
<nstratford> I support it
<tim_panton> agreed.
<matthew> because we've now wandered away from SDP and
especially away from the semantics of SDP O/A, it *won't*
interoperate without some deep knowledge on the part of the web
developer. why are "browser-to-browser" use cases being
prioritized (from the developer-ease POV)
hta: did not hear active support for proposal outside of MS
group.
matthew Tim and Neil as well.
juberti: we can consider parts of this independently on the
list.
hta: out of time. need to take discussion to the list. chairs
need to confer on how to make progress.
... may need to take a poll here.
<matthew> peerconnection is a huge PITA to interoperate with
any existing VOIP system (SIP w/SDP O/A, Jingle w/trickle ICE,
POTS gateways that only want to do connectivity check responses
and not full ICE)... no more or less so than our (MS) proposal
<matthew> peerconnection might be easier for browser-to-browser
only, but that shouldn't be "the most important" use case.
they're all important.
hta: no clear consensus yet on one way to proceed.
Received on Thursday, 30 August 2012 09:39:33 UTC