Web Real-Time Communications Working Group Teleconference

<dom> scribenick: adambe

Minutes approval

stefanh: first, aprove minutes from last meeting

<stefanh> minutes: 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: 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> 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 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.