19:50:05 <RRSAgent> RRSAgent has joined #webrtc
19:50:05 <RRSAgent> logging to http://www.w3.org/2012/08/28-webrtc-irc
19:50:07 <trackbot> RRSAgent, make logs world
19:50:07 <Zakim> Zakim has joined #webrtc
19:50:09 <trackbot> Zakim, this will be RTC
19:50:09 <Zakim> ok, trackbot, I see UW_Web RTC()4:00PM already started
19:50:10 <trackbot> Meeting: Web Real-Time Communications Working Group Teleconference
19:50:10 <trackbot> Date: 28 August 2012
19:50:33 <fluffy> fluffy has joined #webrtc
19:51:11 <Zakim> + +1.403.244.aaaa
19:51:13 <Zakim> - +1.403.244.aaaa
19:51:13 <Zakim> + +1.403.244.aaaa
19:51:44 <fluffy> Zakim, aaaa is fluffy 
19:51:44 <Zakim> +fluffy; got it
19:53:04 <stefanh> stefanh has joined #webrtc
19:55:47 <Zakim> + +1.215.681.aabb
19:56:04 <Zakim> +Dan_Burnett
19:56:06 <burn> burn has joined #webrtc
19:56:15 <burn> zakim, who's here?
19:56:15 <Zakim> On the phone I see [GVoice], fluffy, +1.215.681.aabb, Dan_Burnett
19:56:25 <burn> zakim, I am Dan_Burnett
19:56:25 <Zakim> ok, burn, I now associate you with Dan_Burnett
19:56:27 <Zakim> +stefanh
19:56:56 <DanD> DanD has joined #webrtc
19:57:10 <nstratford> nstratford has joined #webrtc
19:57:25 <Zakim> + +972.9.957.aacc
19:57:54 <Zakim> + +1.425.580.aadd
19:58:04 <Zakim> +??P14
19:58:14 <danromascanu> danromascanu has joined #webrtc
19:58:15 <DanD> +Dan_Druta
19:58:28 <nstratford> Zakim, ??P14 is me
19:58:28 <Zakim> +nstratford; got it
19:58:32 <Zakim> +??P16
19:58:41 <Zakim> +hta
19:58:54 <DanD> +DanD
19:58:55 <stefanh> Anyone volonteer for scribing?
19:59:15 <Zakim> + +33.6.85.56.aaee
19:59:27 <Zakim> + +358.405.60aaff
19:59:44 <DanD> 1.425.580.aadd is DanD
19:59:48 <Milan_Patel> Milan_Patel has joined #webrtc
19:59:50 <Zakim> + +1.630.423.aagg
19:59:53 <Zakim> + +1.425.893.aahh
20:00:10 <juberti> juberti has joined #webrtc
20:00:18 <Zakim> + +1.503.712.aaii
20:00:21 <juberti> Zakim, who is here?
20:00:21 <Zakim> On the phone I see [GVoice], fluffy, +1.215.681.aabb, Dan_Burnett, stefanh, +972.9.957.aacc, +1.425.580.aadd, nstratford, ??P16, hta, +33.6.85.56.aaee, +358.405.60aaff,
20:00:25 <Zakim> ... +1.630.423.aagg, +1.425.893.aahh, +1.503.712.aaii
20:00:25 <Zakim> +adambe
20:00:33 <adambe> adambe has joined #webrtc
20:00:36 <juberti> Zakim, aadd is juberti
20:00:36 <Zakim> +juberti; got it
20:00:40 <Jerome> Jerome has joined #webrtc
20:00:47 <Zakim> +Jim_Barnett
20:00:48 <dom> Zakim, code?
20:00:49 <Zakim> the conference code is 9782 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), dom
20:00:58 <martin> IVR is causing me issues
20:00:58 <juberti> Zakim, aahh is juberti
20:00:58 <Zakim> +juberti; got it
20:01:08 <Zakim> +??P26
20:01:09 <Zakim> + +1.908.541.aajj
20:01:20 <dom> Zakim, ??P26 is me
20:01:20 <Zakim> +dom; got it
20:01:22 <danromascanu> +972.9.957.aacc is me
20:01:26 <dom> Zakim, who's on the call?
20:01:26 <Zakim> On the phone I see [GVoice], fluffy, +1.215.681.aabb, Dan_Burnett, stefanh, +972.9.957.aacc, juberti, nstratford, ??P16, hta, +33.6.85.56.aaee, +358.405.60aaff, +1.630.423.aagg,
20:01:29 <Zakim> ... juberti.a, +1.503.712.aaii, adambe, Jim_Barnett, dom, +1.908.541.aajj
20:01:38 <Zakim> + +1.469.277.aakk
20:01:41 <ekr> ekr has joined #webrtc
20:01:45 <anant> anant has joined #webrtc
20:01:51 <juberti> I can scribe for parts like IDP
20:01:52 <Zakim> + +1.650.678.aall
20:01:59 <juberti> that I don't have an opinion on... :)
20:02:02 <stefanh> thanks justin!
20:02:04 <Li> Li has joined #webrtc
20:02:05 <Zakim> + +358.505.22aamm
20:02:08 <Zakim> + +1.650.735.aann
20:02:14 <Jim> Jim has joined #webrtc
20:02:27 <anant> aann is anant
20:02:32 <ekr> zakim: who is here
20:02:37 <dom> Agenda: http://lists.w3.org/Archives/Public/public-webrtc/2012Aug/0200.html
20:02:38 <anant> Zakim: aann is anant
20:02:41 <Zakim> + +1.831.440.aaoo
20:02:46 <ekr> zakim, who is here?
20:02:46 <Zakim> On the phone I see [GVoice], fluffy, +1.215.681.aabb, Dan_Burnett, stefanh, +972.9.957.aacc, juberti, nstratford, ??P16, hta, +33.6.85.56.aaee, +358.405.60aaff, +1.630.423.aagg,
20:02:49 <Zakim> ... juberti.a, +1.503.712.aaii, adambe, Jim_Barnett, dom, +1.908.541.aajj, +1.469.277.aakk, +1.650.678.aall, +358.505.22aamm, +1.650.735.aann, +1.831.440.aaoo
20:02:50 <anant> how do you tell Zakim the name?
20:02:59 <ekr> zakim, aall is ekr
20:02:59 <Zakim> +ekr; got it
20:03:00 <martin> I don't have a dial pad on my phone, is there a direct line?
20:03:06 <ekr> zakim, aann is anant
20:03:06 <Zakim> +anant; got it
20:03:07 <anant> Zakim, aann is anant
20:03:07 <Zakim> sorry, anant, I do not recognize a party named 'aann'
20:03:13 <anant> thanks ekr!
20:03:15 <DanD> zakim, aadd is DanD
20:03:15 <Zakim> sorry, DanD, I do not recognize a party named 'aadd'
20:03:16 <Zakim> +??P32
20:03:21 <ekr> zakim, who is here?
20:03:21 <Zakim> On the phone I see [GVoice], fluffy, +1.215.681.aabb, Dan_Burnett, stefanh, +972.9.957.aacc, juberti, nstratford, ??P16, hta, +33.6.85.56.aaee, +358.405.60aaff, +1.630.423.aagg,
20:03:23 <stefanh> zakim, aamm is christer
20:03:23 <burn> zakim, aakk is Spencer_Dawkins
20:03:24 <Zakim> ... juberti.a, +1.503.712.aaii, adambe, Jim_Barnett, dom, +1.908.541.aajj, +1.469.277.aakk, ekr, +358.505.22aamm, anant, +1.831.440.aaoo, ??P32
20:03:24 <Zakim> +christer; got it
20:03:24 <Zakim> +Spencer_Dawkins; got it
20:03:57 <Zakim> + +1.610.889.aapp
20:03:57 <Li> zakim, aajj is Li
20:03:58 <Zakim> +Li; got it
20:04:07 <Jerome> +3368556
20:04:15 <dom> Zakim, aaff is markus
20:04:15 <Zakim> +markus; got it
20:04:20 <dom> Zakim, aaee is Jerome
20:04:20 <Zakim> +Jerome; got it
20:04:43 <dom> Zakim, who's on the call?
20:04:43 <Zakim> On the phone I see [GVoice], fluffy, +1.215.681.aabb, Dan_Burnett, stefanh, +972.9.957.aacc, juberti, nstratford, ??P16, hta, Jerome, markus, +1.630.423.aagg, juberti.a,
20:04:46 <Zakim> ... +1.503.712.aaii, adambe, Jim_Barnett, dom, Li, Spencer_Dawkins, ekr, christer, anant, +1.831.440.aaoo, ??P32, +1.610.889.aapp
20:05:04 <dom> scribe: adambe
20:05:06 <Zakim> + +91.80.33.41.aaqq
20:05:11 <Zakim> +??P35
20:05:21 <Zakim> + +46.1.07.13.aarr
20:05:23 <adambe> stefanh: first, aprove minutes from last meeting
20:05:23 <Milan_Patel> Present+ milan_patel
20:05:25 <stefanh> minutes: http://lists.w3.org/Archives/Public/public-webrtc/2012Jun/0087.html
20:05:32 <Zakim> + +1.650.353.aass
20:05:40 <adambe> ... does anyone object to the minutes?
20:05:46 <adambe> ... I guess they are aproaved
20:05:59 <dom> i/stefanh: first/Topic: Minutes approval
20:06:00 <jesup> jesup has joined #webrtc
20:06:04 <martin> +1650353
20:06:07 <adambe> ... should we move on to the walkthrogh of the MS API proposal
20:06:07 <burn> Agenda:  http://lists.w3.org/Archives/Public/public-webrtc/2012Aug/0200.html
20:06:20 <dom> Topic: MS CU-WebRTC proposal
20:06:21 <Zakim> - +972.9.957.aacc
20:06:29 <adambe> hta: everyone has looked at it and people have commented on it
20:07:02 <fluffy> q+
20:07:05 <adambe> ... today I've seen a desire to break the proposal up into smaller parts
20:07:06 <ekr> q+
20:07:12 <adambe> ... which can be addressed
20:07:22 <adambe> stefanh: we give the floor to martin
20:07:25 <mreavy> mreavy has joined #webrtc
20:07:46 <adambe> fluffy: I'm confused, what do we want to acomplish with this?
20:08:00 <adambe> ... what I saw on the agenda was to discuss the CURTCWeb stuff
20:08:08 <adambe> ... what I just heard was not that
20:08:13 <ekr> q-
20:08:22 <adambe> hta: lets hear what the MS people want to present
20:08:37 <adambe> fluffy: we need to say if we're changing the agenda
20:08:45 <adambe> stefanh: let the MS guys present
20:08:50 <adambe> hta: do we have the slides
20:08:52 <adambe> ... ?
20:08:59 <dom> -> http://lists.w3.org/Archives/Public/www-archive/2012Aug/att-0032/Curtsy_Web_Overview.pdf MS slides
20:09:26 <adambe> stefanh: is someone from MS here?
20:10:01 <adambe> martin: 2nd slide describes what we saw was going on with the current work
20:10:15 <adambe> ... PeerConnection claims to be several things that it's not
20:11:07 <Zakim> + +972.9.957.aatt
20:11:17 <adambe> lost a lot of things here
20:11:24 <adambe> ... on slide 3
20:11:43 <adambe> fluffy: I don't things the points on slide 2 is right
20:11:54 <adambe> martin: we should discuss this on the list
20:12:06 <adambe> fluffy: I would have sent comments if I had seen the slides earlier
20:12:20 <adambe> martin: MSID is soley for this API
20:12:33 <adambe> martin: multiplexing issues have not been resolved yet
20:13:11 <adambe> ... when you build this API for SDP it need a lot of things that are not specified in SDP
20:13:29 <adambe> ... we think it's necessary to know what version of SDP browsers will implement
20:13:36 <adambe> ... moving on to slide 4
20:13:50 <rillian> rillian has joined #webrtc
20:13:59 <rillian> "Conference is full"
20:14:00 <adambe> ... the lot of work is talking about signaling
20:14:12 <adambe> ... we don't think it's in the scope of this work
20:14:20 <ekr> zakim, who is talking?
20:14:21 <dom> Zakim, who's noisy?
20:14:31 <Zakim> ekr, listening for 10 seconds I heard sound from the following: stefanh (9%), hta (22%), adambe (4%), +1.650.353.aass (18%)
20:14:46 <Zakim> dom, listening for 14 seconds I heard sound from the following: adambe (3%), +1.650.353.aass (84%)
20:14:48 <adambe> ... slide 5 shows the propoed architecture
20:14:58 <adambe> ... there are three pieces
20:15:06 <adambe> .. first part, abstract streams
20:15:12 <adambe> ... getUserMedia() is good
20:15:44 <adambe> ... the media part with media streams serialized into the network
20:15:55 <adambe> ... and the transport part with ICE...
20:16:44 <adambe> ... slide 7 is about RealTimePorts
20:16:58 <adambe> ... which represents candidates
20:17:04 <juberti> PeerConnection has the same relationships, they are just wired together with different APIs.
20:17:09 <tim_panton> tim_panton has joined #webrtc
20:17:22 <adambe> ... slide 8 talks about RealTimeTransport
20:17:43 <adambe> ... does ongingn concent checking and so on
20:18:00 <adambe> ... the RealTimeMediaStream is what sends packets
20:18:17 <Zakim> -Spencer_Dawkins
20:18:19 <fluffy> q?
20:18:52 <Zakim> + +1.778.785.aauu
20:18:55 <adambe> ... the MediaDescription represents a single m-line
20:19:21 <adambe> ... it also provides a simple negotiation feature
20:19:28 <adambe> ... slide 11
20:19:42 <adambe> fluffy: how is MediaDescription different compared to SDP
20:19:47 <adambe> ... is it more powerful?
20:19:59 <adambe> martin: SDP describes an entire session
20:20:08 <rillian> Zakim: aauu is me
20:20:08 <adambe> ... MediaDescription describes a single m-line
20:20:25 <adambe> ... this is intended to say that this is a single stream
20:20:32 <tim_panton> zakim, who's here?
20:20:32 <Zakim> On the phone I see +972.9.957.aatt, +1.778.785.aauu, [GVoice], fluffy, +1.215.681.aabb, Dan_Burnett, stefanh, juberti, nstratford, ??P16, hta, Jerome, markus, +1.630.423.aagg,
20:20:35 <Zakim> ... juberti.a, +1.503.712.aaii, adambe, Jim_Barnett, dom, Li, ekr, christer, anant, +1.831.440.aaoo, ??P32, +1.610.889.aapp, +91.80.33.41.aaqq, ??P35, +46.1.07.13.aarr,
20:20:35 <Zakim> ... +1.650.353.aass
20:20:43 <adambe> ... it is what is necessary to get  a single stream over the network
20:20:47 <dom> Zakim, aauu is rillian
20:20:47 <Zakim> +rillian; got it
20:20:52 <adambe> ... SDP covers many things
20:21:03 <adambe> ... it also has a concept of bidirectional media
20:21:17 <adambe> fluffy: how do you interop with legacy without bidirectional?
20:21:32 <Zakim> -anant
20:22:22 <adambe> martin: if you can enumerate the problems, it could be helpful
20:22:26 <Zakim> +anant
20:22:44 <adambe> fluffy: hard to get this workingn without a media translator
20:22:54 <adambe> martin: slide 11
20:23:06 <adambe> ... is the stuff that we didn't include in this proposal
20:23:10 <adambe> ... the data chanel
20:23:18 <adambe> ... we didn't see where it was going
20:23:20 <adambe> ... DTMF
20:23:33 <adambe> ... will follow up on the list with that one
20:23:41 <ekr> q+
20:23:45 <adambe> ... slide 13 is the sum of the deltas we identified
20:23:47 <fluffy> q-
20:23:48 <adambe> ... there may be more
20:24:05 <adambe> ... not sure we need to bring those up
20:24:19 <adambe> ekr: I have a problem with this list
20:24:35 <Zakim> -anant
20:24:39 <dom> [ekr asks about "Control connection establishment based on certificate"]
20:24:49 <ekr> adambe: I'm not saying I have a problem with this list… I just have a question.
20:24:52 <anant> anant has joined #webrtc
20:25:02 <dom> s/problem with/question on/
20:25:16 <dom> s/adambe:/adambe,/
20:25:16 <Zakim> +anant
20:25:22 <fluffy> q?
20:25:59 <dom> ["H.264 SVC support"]
20:26:16 <dom> ack ekr
20:26:43 <adambe> sry, lost a lot of stuff here
20:27:53 <adambe> does anyone want to take over scribing this?
20:28:35 <Richard> Richard has joined #webrtc
20:29:05 <Zakim> -anant
20:29:09 <adambe> which nick is Matthew?
20:31:10 <adambe> discussion is about splitting SDP up
20:31:27 <adambe> between MediaStream and PeerConnection
20:32:13 <ekr> who was that?
20:33:03 <Zakim> - +1.215.681.aabb
20:33:26 <ekr> zakim, who is here?
20:33:26 <Zakim> On the phone I see +972.9.957.aatt, rillian, [GVoice], fluffy, Dan_Burnett, stefanh, juberti, nstratford, ??P16, hta, Jerome, markus, +1.630.423.aagg, juberti.a, +1.503.712.aaii,
20:33:30 <Zakim> ... adambe, Jim_Barnett, dom, Li, ekr, christer, +1.831.440.aaoo, ??P32, +1.610.889.aapp, +91.80.33.41.aaqq, ??P35, +46.1.07.13.aarr, +1.650.353.aass
20:33:48 <Zakim> + +1.215.681.aavv
20:34:35 <Zakim> +anant
20:35:09 <jesup> thanks ekr
20:35:12 <ekr> ekr: I am about to summarize what I think has happened so far.
20:35:13 <jesup> and dan
20:35:19 <Markus> Markus has joined #webrtc
20:35:21 <jesup> cullen
20:35:22 <burn> scribe:burn
20:35:41 <hta> Gøran Eriksson
20:35:42 <stefanh> name: goran
20:35:42 <ekr> matthew: H.264 SVC interacts badly with bundle and some other stuff vis-a-vis SDP
20:35:54 <ekr> fluffy: what does this do that you can't do with the mid-level API
20:36:11 <martin> q?
20:36:16 <ekr> matthew: same answer as last time, we're worried about future flexibility
20:36:20 <gape> gape has joined #webrtc
20:36:45 <matthew> matthew has joined #webrtc
20:37:05 <ekr> matthew: this is a set of changes, some of which are noncontroversial and some of which aren't. there may be room for compromise
20:37:14 <matthew> i'm here now
20:37:32 <dom> RRSAgent, pointer?
20:37:32 <RRSAgent> See http://www.w3.org/2012/08/28-webrtc-irc#T20-37-32
20:37:50 <dom> RRSAgent, draft minutes
20:37:50 <RRSAgent> I have made the request to generate http://www.w3.org/2012/08/28-webrtc-minutes.html dom
20:38:18 <ekr> 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
20:38:19 <burn> (missed something)
20:38:49 <burn> fluffy:  bundle and svc together did not have problems in our review. they definitely have to work together
20:38:55 <jesup> Let's move forward...
20:39:02 <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.
20:39:11 <dom> scribenick: burn
20:39:14 <ekr> fluffy: OK, what does that do for you?
20:39:28 <burn> fluffy:  what are advantages of splitting SDP as you suggest on slide?
20:39:54 <dom> s/scribe: adambe/scribenick: adambe
20:39:56 <anant> anant has joined #webrtc
20:40:01 <burn> matthew:  don't see low/mid distinction.  rather, things are mixed together.  prefer better split into transport and media stream
20:40:38 <gape> I asked for reasons for skipping SDP- poor syntax and/or semantics or not providing for interoperability.
20:40:55 <martin> q+
20:41:11 <burn> jesup:  in many cases all streams will go through same link, so this is not necessarily cleaner.  also doesn't interop well.
20:41:25 <hta> s/jesup/justin/?
20:41:28 <burn> matthew:  ip multicast reception in browsers easier in our model
20:41:32 <jesup> burn : that was justin
20:41:38 <burn> (sorry)
20:41:46 <fluffy> q?
20:41:47 <dom> s/jesup:/juberti:/
20:41:52 <ekr> Nor was it JSEP :)
20:42:47 <burn> juberti:  maybe we can extend what we have in a declarative manner.  why do we need to restructure everything?
20:43:28 <burn> 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.
20:44:22 <burn> ... 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.
20:44:34 <ekr> q+
20:44:40 <burn> ... these are actual semantic changes so it is no longer SDP at all
20:44:58 <burn> ... if we are going to break SDP, why use SDP at all?
20:45:11 <burn> cullen:  how are we in violation of SDP?
20:45:37 <burn> matthew:  you can send offers while in an exchange already
20:46:09 <burn> juberti:  no requirement that everything is 3264 compliant, but can do that if you want
20:46:31 <burn> stefan:  we are deep in the weeds here, should we refer to another time for this?
20:46:50 <burn> ekr:  this is important, and any decision here affects everything else we do.
20:47:19 <burn> cullen:  we have discussed all this before (for years).  splitting SDP is not even in MS proposal.  
20:47:46 <burn> ... major outcome of this is that it will stall us for 6 months.  Better to discuss now and make a decision.
20:47:56 <burn> anant:  agree we need to discuss now
20:48:00 <jesup> agreed, discuss
20:48:04 <juberti> agree
20:48:05 <ekr> yes, it was anant
20:48:09 <gape> yes, discuss now...
20:48:29 <mreavy> please discuss
20:49:16 <burn> 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.
20:49:26 <burn> ... offer/answer is necessary.
20:49:42 <tim_panton> q+
20:49:49 <burn> matthew:  if using sdp o/a, then do so.  No hacks for trickle ice, multiple offers, etc.
20:50:00 <ekr> chairs: can we have some queue discipline?
20:50:24 <burn> ... since api ends up getting cluttered, why not create something clean from the beginning?
20:50:41 <fluffy> q?
20:50:48 <tim_panton> q-
20:51:11 <burn> cullen: we are making all these things part of SDP
20:51:18 <fluffy> q+
20:51:41 <hta> q+
20:51:53 <burn> martin:  some of the things stated were wrong.  do not need to have a single controller per path
20:52:18 <martin> q-
20:52:18 <burn> ... "make before break" is possible in the proposal
20:53:54 <burn> 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
20:53:55 <matthew> extend SDP = ok. screw with the offer/answer semantic and claiming it is still O/A = not ok.
20:54:20 <burn> ... are we breaking semantics of SDP?  I don't know.  But adding extensions as we always have is reasonable.
20:54:25 <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?
20:54:34 <fluffy> q?
20:54:43 <hta> ack ekr
20:54:44 <ekr> matthew: that's the thing I am trying to get at, are we not doing O/A?
20:54:50 <ekr> I thought we in fact were.
20:55:23 <burn> 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.
20:55:42 <matthew> the API not only allows, but encourages not doing O/A in order to achieve its goals
20:55:46 <burn> martin:  correct.  with DTLS not possible to do that without signaling path do a round trip.
20:55:51 <burn> cullen:  disagree
20:56:11 <ganesh_> ganesh_ has joined #webrtc
20:56:20 <ekr> I am also not clear on this...
20:56:23 <ekr> sorry about that.
20:56:28 <burn> ... if want to receive media as soon as received offer, have to notify of a change or will fail
20:56:29 <hta> q?
20:56:47 <ekr> yes, I was the person who violated queue. I apologize
20:56:58 <Zakim> -??P32
20:57:07 <fluffy> q+
20:57:10 <hta> ack fluffy
20:57:11 <fluffy> q-
20:57:12 <fluffy> q+
20:57:50 <martin> q+
20:57:56 <hta> q-
20:58:00 <matthew> q+
20:58:02 <juberti> q+
20:58:03 <burn> 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
20:58:04 <ekr> q+_
20:58:08 <ekr> q-_
20:58:10 <ekr> q+
20:58:10 <Zakim> +??P7
20:58:59 <burn> 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
20:58:59 <fluffy> q-
20:59:14 <hta> q+
20:59:15 <tim_panton> zakim, ??P7 is me
20:59:15 <Zakim> +tim_panton; got it
20:59:37 <martin> q-
20:59:39 <burn> 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.
21:00:37 <burn> 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.
21:01:11 <matthew> q-
21:01:11 <burn> ... we split transport from media stream because they are useful that way.  numerous use cases that don't involve sending things outside the browser.
21:01:11 <hta> q?
21:01:48 <tim_panton> q+
21:02:10 <burn> 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.
21:02:42 <jesup> zakim: who is talking?
21:02:49 <ekr> juberti
21:02:53 <ekr> I think he is using opus
21:02:55 <ekr> :)
21:02:58 <fluffy> q?
21:02:58 <burn> ... 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?
21:03:01 <fluffy> q+
21:03:09 <hta> ack juberti
21:03:20 <stefanh> q+
21:03:59 <burn> ekr:  architectural purity seems to be main argument.  i want to know what this lets me do that i can't already do.
21:04:17 <burn> ... need concrete example of something hard to do with existing API.
21:04:28 <matthew> i'll need to get on this long list to answer that
21:04:37 <hta> ack ekr
21:04:37 <burn> hta:  need multiple PC to connect multiple people.
21:04:38 <ekr> q+matthew
21:04:38 <hta> ack hta
21:04:45 <ekr> matthew: you're welcome :)
21:04:53 <matthew> maybe i'll still wait :)
21:05:05 <ekr> I have no idea what tim is saying.
21:05:13 <martin> opus 
21:05:36 <jesup> G.729 ;-)
21:05:38 <burn> tim_panton:  architecutural purity is a valid goal.  hard to know when to say we need to start over.  (lost the rest)
21:05:50 <tim_panton> done
21:06:09 <tim_panton> yeah too much wind at burning man.
21:06:16 <jesup> tim_panton: you may want to summarize what you said for those who couldn't hear
21:06:24 <burn> fluffy:  which of these deltas are we doing or could do?
21:06:40 <dom> Zakim, who's noisy?
21:06:47 <burn> ... (goes through list quickly)
21:06:51 <Zakim> dom, listening for 10 seconds I heard sound from the following: hta (4%), +1.650.353.aass (70%)
21:06:54 <dom> Zakim, mute aass
21:06:54 <Zakim> +1.650.353.aass should now be muted
21:06:57 <ekr> BTW, I'm not suggesting that I'm not in favor of purity
21:07:04 <ekr> but it's not the only thing
21:07:40 <juberti> q+
21:07:56 <dom> ack tim
21:07:57 <dom> ack fluffy
21:08:24 <burn> ... if SDP can't deal with 264 needs to be dealt with, but not by this group.
21:08:26 <tim_panton> (So what you missed is the question - If a radically new api is inevitable, we should start sooner rather than later)
21:08:52 <burn> ... we are largely working on all these items
21:08:57 <fluffy> q-
21:09:52 <stefanh> q-
21:09:52 <burn> 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
21:10:00 <dom> ack matthew
21:10:04 <ekr> stefanh: I am not sure about that, either
21:10:15 <dom> ack matt
21:10:22 <matthew> q-
21:10:27 <burn> matthew:  security desc would be SDES.  required for EKT.  will answer other questions on the list.
21:10:30 <dom> ack ju
21:10:31 <matthew> act matthew
21:10:35 <dom> queue=
21:10:36 <matthew> can't type
21:10:49 <ekr> ack matthew
21:10:52 <fluffy> q?
21:11:10 <juberti> whoops, i was muted
21:11:22 <fluffy> q+
21:11:47 <matthew> q+
21:12:09 <burn> 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.
21:12:14 <stefanh> q+
21:12:16 <burn> ... would help working group
21:12:48 <burn> fluffy:  elephant in room is whether IE will implement this.  can anyone answer?
21:13:22 <burn> 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.
21:13:39 <burn> ... also believe our API more useful for certain apps we may want to build in the future.
21:13:53 <anant> q?
21:13:56 <anant> q+
21:13:58 <jesup> q+
21:14:01 <hta> ack fluffy
21:14:09 <dom> ack matt
21:14:11 <gape> q+
21:14:22 <ekr> q+
21:14:32 <juberti> fair enough
21:14:50 <juberti> q+
21:15:33 <burn> ... 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)
21:15:45 <ekr> matthew: since when are you in favor of multicast anything?
21:15:55 <martin> q+
21:16:02 <burn> ... don't have to go to multiple objects, but it's cleaner.  will be better for apps 5-10 years from now.
21:16:54 <tim_panton> kinda like turing machine. 
21:17:00 <burn> ... 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
21:17:25 <ekr> q?
21:17:27 <burn> ... now that we're not using SDP, should make a clean break.
21:17:42 <hta> ack stefanh
21:18:13 <dom> q+ to comment on W3C staff
21:18:32 <burn> 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.
21:18:39 <fluffy> q?
21:19:01 <fluffy> q+ 
21:19:05 <matthew> q+
21:19:12 <martin> yes, we have done the analysis
21:19:12 <burn> anant:  has MS team analyzed security risk of allowing web page to have low-level access like opening a UDP socket
21:19:15 <dom> q-
21:19:15 <matthew> i can answer this, or when i'm on queue
21:19:38 <matthew> this is exactly the same level of security as the existing peerconnection
21:19:53 <ekr> q-
21:19:57 <martin> exactly the same
21:19:58 <tim_panton> q+
21:20:09 <burn> ... 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.
21:20:19 <hta> ack anant
21:20:27 <ekr> martin: I'm not completely sold on this.
21:20:33 <ekr> (this == security)
21:20:34 <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"
21:20:35 <ekr> you mihg tbe rihgt
21:20:37 <gape> q-
21:20:44 <ekr> but I'd like to see an analysis
21:20:58 <matthew> ekr: come work for MS :)
21:21:09 <burn> 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.
21:21:10 <anant> matthew: I disagree that the existing API is broken. For what purpose is it broken?
21:21:55 <Zakim> -[GVoice]
21:21:57 <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?
21:22:14 <burn> ...  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.
21:22:26 <dom> Zakim, close queue
21:22:26 <Zakim> ok, dom, the speaker queue is closed
21:22:34 <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
21:22:45 <matthew> anant: some folks did it for websocket
21:22:55 <burn> juberti:  +1 jesup.  we need one API.  we can layer others on top with JS, but otherwise multiple APIs will just confuse developers.
21:23:00 <matthew> anant: so it appears to be a popular thing to do
21:23:24 <anant> matthew: yes, it was done for websockets, but my belief is that we're not doing the same for PeerConnection
21:23:30 <matthew> TBD
21:23:46 <anant> of course, but that would be true of RealtimeTransport too :)
21:23:48 <hta> burn, this is an architectural problem if later APIs should expose lower layers than earlier APIs.
21:23:48 <burn> ... 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?
21:23:53 <fluffy> q?
21:23:54 <hta> q?
21:23:54 <anant> nothing survives the brunt of actually shipping
21:24:02 <hta> ack jesup
21:24:04 <martin> q-
21:24:04 <hta> ack juberti
21:24:21 <martin> Q+
21:24:47 <martin> umm, thanks, but I wasn't finished,
21:25:04 <burn> fluffy:  from a taste/preference perspective, think current API is simpler.  also, all of CU-RTCWeb can be implemented on top of JSEP.
21:25:08 <matthew> martin said q- before he started talking, but got stepped on
21:25:16 <fluffy> q-
21:25:30 <ekr> martin......
21:25:32 <ekr> martin.....?????
21:25:37 <mreavy> the speaker queue is closed but i want to say that it's important that our work can be used by non-experts.
21:25:38 <martin> I don't have a mute
21:25:46 <ekr> apparently you are a mute!
21:25:53 <martin> oh well
21:25:55 <juberti> he had to call 10 low level APIs to unmute :)
21:26:06 <dom> Zakim, unmute aass
21:26:06 <Zakim> +1.650.353.aass should no longer be muted
21:26:08 <martin> there were no knobs at all
21:26:20 <martin> Zakim, that was rude
21:26:20 <Zakim> I don't understand 'that was rude', martin
21:26:24 <dom> Zakim, who is muted?
21:26:24 <Zakim> I see no one muted
21:26:58 <Christer> Christer has joined #webrtc
21:26:58 <ekr> matthew: could you share that analysis?
21:27:06 <burn> matthew:  lower-level API has same security characteristics.  MS has conducted a security analysis -- conclusion is it's identical.
21:27:08 <ekr> Like the details, not the conclusion?
21:27:17 <fluffy> I think the question about security also had to do with privacy issues
21:27:29 <ekr> I'm inclined to agree with you, but you know I like reading this kind of thing.
21:27:45 <matthew> ekr: i'll see what i can do for the group
21:27:57 <martin> q-
21:27:58 <burn> martin:  at which point in the extension process do you decide that it's too ugly?  
21:28:04 <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.
21:28:04 <dom> ack matthew
21:28:12 <dom> ack tim
21:28:32 <tim_panton> can someone vice that for me?
21:28:39 <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"
21:28:42 <tim_panton> voice.
21:29:15 <matthew> especially since "naive developers" will get tripped up right away when we start talking trickle ICE, SDP changes required for interoperation, etc.
21:29:27 <burn> 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.
21:29:39 <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
21:29:57 <mreavy> there's a big difference between non-expert and naive developer
21:30:07 <burn> ... matthew submitted list of things he doesn't think work with current API, so we should look at the list.
21:30:25 <burn> cullen:  we are already doing this.
21:30:45 <anant> mreavy++, the last thing on even a veteran web developer
21:30:50 <tim_panton> I support it.
21:30:53 <anant> 's mind is how to be setting up ports
21:30:54 <nstratford> I support it
21:31:08 <tim_panton> agreed.
21:31:23 <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)
21:31:24 <burn> hta:  did not hear active support for proposal outside of MS group.
21:31:40 <burn> matthew; Tim and Neil as well.
21:31:45 <ekr> that is justin, right?
21:31:49 <hta> yes.
21:31:59 <burn> juberti:  we can consider parts of this independently on the list.
21:32:21 <burn> hta:  out of time.  need to take discussion to the list.  chairs need to confer on how to make progress.
21:32:29 <burn> ... may need to take a poll here.
21:32:31 <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
21:33:00 <matthew> peerconnection might be easier for browser-to-browser only, but that shouldn't be "the most important" use case. they're all important.
21:33:09 <burn> hta:  no clear consensus yet on one way to proceed.
21:33:18 <Zakim> -ekr
21:33:30 <Zakim> -??P35
21:33:32 <Zakim> - +1.831.440.aaoo
21:33:33 <Zakim> -christer
21:33:33 <Zakim> -tim_panton
21:33:34 <Zakim> - +1.215.681.aavv
21:33:34 <Zakim> -adambe
21:33:35 <Zakim> - +46.1.07.13.aarr
21:33:35 <Zakim> -markus
21:33:36 <dom> Zakim, list attendees
21:33:37 <Zakim> - +1.650.353.aass
21:33:39 <Zakim> -juberti.a
21:33:41 <Zakim> As of this point the attendees have been [GVoice], +1.403.244.aaaa, fluffy, +1.215.681.aabb, Dan_Burnett, stefanh, +972.9.957.aacc, +1.425.580.aadd, nstratford, hta,
21:33:43 <dom> RRSAgent, draft minutes
21:33:43 <RRSAgent> I have made the request to generate http://www.w3.org/2012/08/28-webrtc-minutes.html dom
21:33:44 <Zakim> ... +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,
21:33:47 <Zakim> ... +358.505.22aamm, +1.650.735.aann, +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,
21:33:50 <Zakim> ... +1.650.353.aass, +972.9.957.aatt, +1.778.785.aauu, rillian, +1.215.681.aavv, tim_panton
21:33:53 <Zakim> - +1.610.889.aapp
21:33:55 <Zakim> - +972.9.957.aatt
21:33:56 <Zakim> -stefanh
21:33:58 <Zakim> -anant
21:33:59 <dom> RRSAgent, draft minutes
21:33:59 <RRSAgent> I have made the request to generate http://www.w3.org/2012/08/28-webrtc-minutes.html dom
21:34:00 <Zakim> - +1.503.712.aaii
21:34:02 <Zakim> -juberti
21:34:04 <Zakim> -hta
21:34:06 <Zakim> -Li
21:34:08 <Zakim> -Dan_Burnett
21:34:10 <Zakim> -nstratford
21:34:13 <Zakim> -rillian
21:34:14 <Zakim> - +1.630.423.aagg
21:34:16 <Zakim> -Jerome
21:34:18 <Zakim> -fluffy
21:34:21 <Zakim> -dom
21:34:22 <Zakim> -Jim_Barnett
21:34:31 <Zakim> - +91.80.33.41.aaqq
21:34:31 <ganesh_> bye
21:34:33 <dom> Chair: Harald, Stefan
21:34:42 <dom> RRSAgent, draft minutes
21:34:42 <RRSAgent> I have made the request to generate http://www.w3.org/2012/08/28-webrtc-minutes.html dom
21:34:43 <Zakim> -??P16
21:34:44 <Zakim> UW_Web RTC()4:00PM has ended
21:34:44 <Zakim> Attendees were [GVoice], +1.403.244.aaaa, fluffy, +1.215.681.aabb, Dan_Burnett, stefanh, +972.9.957.aacc, +1.425.580.aadd, nstratford, hta, +33.6.85.56.aaee, +358.405.60aaff,
21:34:44 <Zakim> ... +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.650.735.aann,
21:34:45 <Zakim> ... +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, +1.650.353.aass, +972.9.957.aatt,
21:34:46 <Zakim> ... +1.778.785.aauu, rillian, +1.215.681.aavv, tim_panton
21:34:50 <rillian> dom, burn: thanks for scribing
21:47:34 <jesup> jesup has left #webrtc
23:57:43 <Zakim> Zakim has left #webrtc