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

[minutes] August 28 teleconf

From: Dominique Hazael-Massieux <dom@w3.org>
Date: Thu, 30 Aug 2012 11:40:12 +0200
Message-ID: <1346319612.9649.0.camel@cumulustier>
To: public-webrtc@w3.org

The draft minutes of our call yesterday (Aug 28) are available at:

and copied as text below.

Please send corrections to the list.


       Web Real-Time Communications Working Group Teleconference

28 Aug 2012



   See also: [3]IRC log

      [3] http://www.w3.org/2012/08/28-webrtc-irc


          [GVoice], +1.403.244.aaaa, fluffy, +1.215.681.aabb,
          Dan_Burnett, stefanh, Dan Romanescu, DanDruta,
          nstratford, hta, +, +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, +,
          +, Martin, +972.9.957.aatt, rillian,
          +1.215.681.aavv, tim_panton, milan_patel

          StefanH, Harald



     * [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:


   stefanh: does anyone object to the minutes?
   ... I guess they are aproaved

   stefanh: should we move on to the walkthrogh of the MS API

   <burn> Agenda:


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


   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

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

   matthew: same answer as last time, we're worried about future

   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

   matthew: don't see low/mid distinction. rather, things are
   mixed together. prefer better split into transport and media

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

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

   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

   <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

   <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

   <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

   <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

   <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

   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

   <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

   matthew Tim and Neil as well.

   juberti: we can consider parts of this independently on the

   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:40:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:32 UTC