17:32:20 RRSAgent has joined #webrtc 17:32:20 logging to http://www.w3.org/2011/07/23-webrtc-irc 17:32:26 RRSAgent, make logs world 17:32:48 Meeting: Web Real-Time Communications Working Group - Quebec City F2F 17:33:17 Chair: Harald_Alvestrand, Stefan_Hakansson 17:33:21 Agenda: http://www.w3.org/2011/04/webrtc/wiki/July_23_2011 17:33:40 Regrets: Rich_Tibbett 17:36:11 RRSAgent, draft minutes 17:36:11 I have made the request to generate http://www.w3.org/2011/07/23-webrtc-minutes.html francois 17:42:03 burn has joined #webrtc 17:43:54 cullenfluffyjenni has joined #webrtc 17:45:15 francois has left #webrtc 17:45:17 francois has joined #webrtc 17:51:20 Present+ Stefan_Hakansson 17:51:30 Present+ Harald_Alvestrand 17:51:40 Present+ Dan_Burnett 17:51:44 Present+ Francois_Daoust 17:51:51 Present+ Cullen_Jennings 17:53:39 stefanh has joined #webrtc 18:01:03 anant has joined #webrtc 18:01:25 Cary has joined #webrtc 18:01:58 scribe: francois 18:03:06 stefanh has joined #webrtc 18:03:22 hta: [introduction]. W3C meeting hosted by IETF. W3C rules. 18:03:39 jesup has joined #webrtc 18:03:47 ... No polycon for the conference today. 18:04:17 Dan has joined #webrtc 18:04:36 ... Looking for scribes. 18:04:46 [francois and Cullen step up] 18:04:48 tedhardie has joined #webrtc 18:06:09 Topic: RTCWeb Architecture 18:06:20 hta: slides on Web RTC architecture. 18:06:56 ... Going to present goals, architecture layers, security. I won't touch upon details. 18:07:29 ... Goal is enable realtime Communication between browsers. Real Time means you can wave at someone and he can wave back. 100ms timescale. 18:07:42 ... Media is audio/video but people also want to send other stuff to. 18:07:53 ... Important to drive the design by use cases 18:08:39 ... We have to go for general functions to enable innovations. Use cases are least amount of things possible. 18:09:23 ... Basic concept: somehow Javascript, with the help of the server, can establish a connection to the other browser. 18:09:49 ... Media flows through the shortest possible path for latency and because it makes life simpler. 18:10:38 ... Different architecture layers. Apart from the browser, any other box must be assumed to be able to be controlled by an enemy. 18:10:50 DanD has joined #webrtc 18:10:52 ... That is a security context that is slightly different from in other areas. 18:11:01 ... In IETF, we're mostly concerned by attacks on the network. 18:11:09 ... Here, we have to take into account all components. 18:11:19 magnus has joined #webrtc 18:11:48 ... Data transport means you have to establish some data path. More or less agreed to use ICE. 18:12:27 ... UDP is the obvious transport given the constraints (we need to be able to backup to TCP though). Congestion management is necessary. 18:13:09 alissa has joined #webrtc 18:13:09 ... I'll skip rapidly through IETF issues as they will be addressed on Tuesday and Thursday. Focus on API here. 18:13:50 ... There will be data framing, securing, we must negotiate data formants and we need some baseline that everyone implements for the negotiation to always succeed. 18:14:11 ... We have use cases for setting up connections that require SIP and others that don't require SIP. 18:14:57 ... User interfaces include privacy considerations. The user has to know that he has allowed the use of camera and microphone and must be able to revoke that access at any time. 18:15:19 ... In scope for W3C, not so much for IETF. 18:16:11 hta: Talking about API, it shouldn't take too many lines of JavaScript to setup a connection and tear down a call. Multiple streams, pictures that jump up, etc. should be possible. 18:16:25 ... There are things that are on the wire but are truly relevant for the user. 18:16:44 ... In some cases, security demands that they are hidden to the user interface. 18:17:20 ... Interoperability requires that it all gets specified. 18:17:54 ... If you precise control precisely, it ages badly, e.g. "I want that precise codec". 18:18:36 ... Of course, we have to have interoperability. If you give the same script to two browsers, it should work. Not exactly the same resources because different capabilities are possible, but it should work. 18:18:57 ... When data is passed through this API, format has to be specified. 18:19:10 ... In some cases, we have blobs that get passed. 18:19:38 ... These blobs will be parsed by different browsers though, so they need to know how to parse them. 18:20:17 ... Summary slide: Having an overview is a means to ensure that we can talk about different parts of the system and we feel confident that we have all the pieces covered. 18:20:37 ... Questions/Comments/Disagreements? 18:21:25 Cullen: that seems consistent with what I'm think I'm hearing. 18:22:28 ??Wallace: you said precise control age badly. I'd like to say "higher quality than x/y/z", right. 18:23:09 ... Problem is that the notion of "higher quality" depends on codecs and profiles. 18:23:45 ... I fear it falls into a rathole designing a new way of describing codecs and qualities 18:24:35 Matthew_Koffman: I think legacy interoperability is missing from your slides. 18:24:48 ??2: what do you mean with legacy interoperability 18:25:32 s/??Wallace/EKR/ 18:25:51 Matthew_Koffman: I can show you existing devices that do RTP but not SRTP. If you want to non secure devices, you need to relax the bullet presented that unencrypted data do no need to be carried. 18:26:40 hta: one of the things that someone mentioned is that we need to talk to gateways. 18:27:27 ??3(Google): is this the right place to discuss that? Shouldn't this be handled by RTCWEB group on Tuesday/Thursday. 18:27:45 Matthew_Koffman: I believe it has API implications. 18:28:01 ... It's overview, the overview should talk about legacy system. 18:28:10 Scribe: Cullen Jennings 18:28:12 hta: I'll consider including that for Tuesday/Thursday as well. 18:28:23 ScribeNick: cullenfluffyjenni 18:29:01 Francois: Asked question about architecture and if we need to resolve it in this WG 18:29:45 Scribe: francois 18:29:49 hta: IF we discover that W3C perspective results in things need to change, we should take that change to IETF 18:29:55 s/Scribe: francois// 18:30:07 scribe: francois 18:30:24 Topic: Use Cases 18:30:42 Stefan: presenting use case 18:31:31 … simple use case is two web browsers communicating. One of the brwosers is behind a NAT. One link has packet loss 18:31:53 … works with different browsers and os 18:31:57 s/??3(Google)/TedHardie/ 18:32:10 .. video windows are resizable 18:32:19 RRSAgent, draft minutes 18:32:19 I have made the request to generate http://www.w3.org/2011/07/23-webrtc-minutes.html francois 18:32:35 Can move from ethernet to wifi to cellular and the session should survive 18:32:52 … Can move from ethernet to wifi to cellular and the session should survive 18:33:01 i/Topic: Use Cases/[quick raise of hands reveals that most of the room follows both IETF and W3C mailing-lists] 18:33:06 … Moving to second use case between two service providers 18:33:44 … case where you must handle two cameras sending video from one browser 18:34:21 Roni: asked question about streaming 18:34:50 i/Topic: Use Cases/ScribeNick: cullentfluffyjenni 18:34:53 RRSAgent, draft minutes 18:34:53 I have made the request to generate http://www.w3.org/2011/07/23-webrtc-minutes.html francois 18:34:56 Stefan: it is not streaming of the game, it is just the two camera's being sent to couach 18:35:16 … use case with a mess of video stream 18:35:37 i/Stefan: presenting use case/ScribeNick: cullenfluffyjenni 18:35:38 Colin: Questiona about if there was NATs in this case 18:35:39 RRSAgent, draft minutes 18:35:39 I have made the request to generate http://www.w3.org/2011/07/23-webrtc-minutes.html francois 18:35:49 Stefan: yes, there are nats 18:36:25 John: Is there an assumption that the video is the same or is different between peers 18:36:44 Stefan: each peer sends same video to all other peers 18:36:55 … use case with multip party on line game 18:37:09 s/multip/multi/ 18:37:53 … Use case with telco interop with PSTN 18:38:08 … need to be able to place and receive calls to PSTN 18:38:16 s/Questiona /Question / 18:38:27 … not clear how much gateway functionality would be needed 18:38:49 … IN the case of call FedEx, this adds being able to navigate IVR 18:39:19 Dan: brought up IVR interaction can be voice rec too 18:39:50 hta: need to tease out the requirements from this use case 18:40:45 Dan: does not care about telephone use case but if we are going to do it, we should do it right 18:41:04 Colin: are there other scenarios for legacy end points 18:41:17 Stefan: these are the only two case right 18:41:45 Roni: brought up need to deal with call center cases 18:42:00 Christer: goal is not to limit to PSTN, it is to connect to SIP 18:42:24 Colin: very differnt to GW soemthing that uses same media formats vs differnt media formats 18:42:38 Roni: ALso different in terms of security 18:43:26 Roni: do we need to knwo it is secure end to end 18:43:59 hta: In his google role: worried that we are worring too much concern about interoperabilyt 18:44:23 … telco network is only one concer 18:45:09 cullen: the Fedex use case. It's not only DMTF. There's the initial prompt. PSTN is not easy. Many attempts to interop with that have failed with Fedex. 18:45:31 I agree with that comment about worrying too much about PSTN. 18:45:32 ... We're very interested with the legacy use case. 18:45:45 ... 2.5 billion user out there without Internet connections. 18:46:18 ekr: There is interop with PSTN, legacy SIP devices, partially standard devices like webex 18:46:39 the very same argument was used when other initiatives started and complicated the heck out of the specifications with very little benefits IMO. 18:46:52 stefan: Use case video conference server 18:47:14 … doing simulcast where clients send high and low res video 18:47:41 … central server siwtches the active speaker high res video to all others plus sends a copy of all low res streams 18:48:20 Dan: Q, we are talking about a display with many people, plus when speaking each person gets bigger 18:48:59 stefan: does not need to get bigger immediately, can be hysteresis on staying on room 18:49:04 trying to identify the Dan's 18:49:30 yep - Dan in Cullen's notes it's not the Dan (Romascanu) in the IRC :-) 18:50:26 The dan in my notes was Dan Burnett - how do I indicate that ? 18:50:44 stefan: the server decides which one to display 18:50:58 just call me DanR if I speak 18:51:15 colin: very differnt requirements if users get to decide what streams get display instead of server 18:52:30 stefan: This use case is inside an organization and introduces a firewall. People outside the firewall should be able to participate 18:52:41 Topic: Derived API requirments 18:53:22 hta: these requirements are only going to be discussed here not in IETF 18:53:56 Dan: Is A1 asking permission or asking them which one to use ? 18:54:22 Ekr: this is a fundemental invariant that the browser that needs to do this 18:54:44 Dan: in W3C we should use the term User Agent not Browser 18:55:35 ekr: The web application needs to be able to request use of the device. The user agent needs to get consent to allow that 18:57:33 ekr: two way to do device selection. 1) application finds the devices and asks user which one wants to use 2) application asks for audio device and UA has way to select one 18:58:02 Matthew: useful to be able to preflight the permissions and find out if they would be OK or not 18:58:22 hta: getting close to end of time for this 18:58:55 francois: do we have some willing to review requirements 18:59:50 ACTION: Dan to send comments reviewing requirements to list 18:59:50 Sorry, amibiguous username (more than one match) - Dan 18:59:50 Try using a different identifier, such as family name or username (eg. ddruta, dburnett, dromasca) 19:00:08 ACTION: DanB to send comments reviewing requirements to list 19:00:09 Created ACTION-5 - to send comments reviewing requirements to list [on Daniel Burnett - due 2011-07-30]. 19:00:31 Alissa: where are the requirements going to live 19:00:45 hta: open issue - like to hear comments on this at end 19:01:08 stefan: moving on Security consideration slide 19:01:23 ISSUE: where are requirements going to live? 19:01:24 Created ISSUE-2 - Where are requirements going to live? ; please complete additional details at http://www.w3.org/2011/04/webrtc/track/issues/2/edit . 19:01:27 ACTION: hta query authors on A15 on what context means 19:01:27 Sorry, couldn't find user - hta 19:02:26 John: what about recording of media. Record what is spoken on mic or received at far end ? 19:02:52 … recording local or recording on a device across the network 19:02:55 ACTION: hta query authors on A15 on what context means 19:02:55 Sorry, couldn't find user - hta 19:03:05 … are people interest in this type of use case ? 19:03:15 ACTION: harald to query authors on A15 on what context means 19:03:15 Created ACTION-6 - Query authors on A15 on what context means [on Harald Alvestrand - due 2011-07-30]. 19:03:32 ACTION: John Ellwell - propose use case on recording 19:03:32 Sorry, couldn't find user - John 19:04:08 dromasca has joined #webrtc 19:04:19 stefan: asking question about adding other use case 19:04:30 [Note there is no way to action someone who is not a participant in the WG using Tracker] 19:04:42 hta: do we want lots of use cases that differ or a use case that encompasses lots of aspects 19:05:02 … what style do people want 19:05:21 cullen: slight preference that encompasses lots of aspects instead of having tens of use cases. 19:05:30 hta: I seem to be outnumbered. 19:05:33 stefan: me too 19:06:04 francois: do we need a use case with screen casting between peers, like VNC? 19:07:08 s/me too/same as Cullen/ 19:07:20 roni: There are uses cases in other WG in IETF. For example CLUE and the semantic label. 19:07:44 Action: Roni Eveans - find some of the use cases and send to group 19:07:44 Sorry, couldn't find user - Roni 19:09:26 (?Att): We need to look at them from the user perspective. End to end user experience is important thing. There are some use cases that are driven by actors:" in our case users, user agents, servers. We need to think that way about this work. Discovery of capabilities and matching two browsers together should be a big one. The timelines of browser development will mandate that we need this. 19:09:58 hta: over time - want to move on 19:10:07 s/(?Att)/Dan_Druta/ 19:10:42 Christer: goal is to come up with use cases that derive new requirements 19:11:38 Tim: like to include music use case 19:11:48 Cullen: in favour of it 19:12:22 hta: on E911, drop for now 19:12:34 Topic: Implementation Experience 19:13:24 hta: presenting in his google role on their implementations in chrome 19:13:36 I am Dan_Burnett 19:13:57 … goal, going for production quality code in chrome for everyone 19:14:10 … used to provide concrete feedback to the API and protcols 19:14:25 … they know the version they are shipping in the first version will not be what is in second version 19:14:36 … they have released key components at code.webrtc.org 19:14:50 … working on integrating into chroming 19:15:25 … add a webrtc C++ api that wraps the GIPs code 19:16:37 … webkit had a "quite rigorous" review process. Specs are very unstable. 19:17:07 … roling out changes to libjingle, webkit and more more I missed 19:17:41 … Got to a working demo with audio and video in brwoser 19:17:45 … going to work real soon now 19:17:50 ekr: what does that mean 19:18:07 hta: can't comments on relases dats - matter of months before it is in production chromium 19:18:44 hta: prefixing everything with webrtc to allow for changes to stable system later 19:19:24 cullen: after you get with a version in the production code. Is the intention to remain backwards compatible with the API you'll have shipped? 19:19:45 hta: we'll argue more strongly against cosmetic changes, yes. We're open for more important changes. 19:19:58 ekr: will it woll out as command line switch , then no switch 19:20:09 hta: yes, expect to see stage with switch 19:20:13 i/cullen: after you/scribe: francois/ 19:20:25 i/ekr: will it woll/scribe: cullenfluffyjenni 19:20:35 Topic: Implementation from Mozilla 19:20:40 s/will it woll/will it roll/ 19:21:48 Tim: mostly been focusing on infrastructure work 19:21:57 … for example, speeding up camera pipline 19:22:08 … doing a new low latency audio backend 19:22:26 … likely to land in firefox 8 or 9 19:22:43 … doing Media Stream API for splittling , mixing, syncronization 19:23:01 … allows for the more complex use cases and innovation 19:23:46 … Plans: using GIPS code from google. First target is firefox addon. Want to do this as it is rapidly evolving. 19:24:01 … Makes it easier to rapidly intereate 19:24:23 Takeget is something production ready in Q1 2012 (just a rough estimate, not a commitment) 19:25:09 … whole bunch of user experience questions, call interupt, multi domain conferencing 19:25:31 … been discussing doing SIP directly in browser 19:25:44 … feel this gives you easeier way to tie to other devices 19:25:44 jesup_cell has joined #webrtc 19:25:55 s/easeier/easier/ 19:26:52 Topic: Implementation from Cisco 19:26:55 Topic: Cary brand presenting Cisco implementation 19:27:10 s/Topic: Implementation from Cisco// 19:27:12 cary: started to see can we get two browsers to call each other using sip 19:27:42 … have implemented this in Chromium and Mozilla 19:28:07 … can do browser to browser voice and video calls betwene browsers and between browsers and video phones 19:28:16 … using GIPS 19:29:00 … put Cisco SIP stack chromium by implementing a render host API and also need to touch the webkit glue 19:29:56 …Did Firefox extension focusing on putting the video and voice 19:30:22 … plan to contribute code to open source projects "soon" 19:31:08 Topic: Ericsson Implemetation 19:31:28 stefan: working on top of webkitGTK+ 19:32:23 … goal is to learn about the API and how it works, learn about flexibility of API, learn it can be implemented with reasonable effort 19:32:43 … have send feedback to editor of spec to add things like label 19:33:05 … there are a bunch of blog posts (URL in slides) 19:33:33 … can demo offline if you want and there is a youtube video of this 19:33:48 magnus: How many of you have looked at security issues 19:34:08 hta: chrome has touch security review process and this is going throught it 19:34:18 tim: have touch security review process 19:34:54 cullen: security, what's that? 19:36:00 Topic: API Design Questions 19:36:26 scribe: francois 19:36:58 cullen: trying to come up with questions and answers that people in the room may have as things they want to do. 19:37:35 ... Looking for feedback on whether we should this or that. Consensus on things that don't need to be done. 19:38:11 TedHardie: thinking about whether some of the interfaces between the browsers and the OS need to be taken into account 19:38:40 cullen: Right. Today, I'm going to stay high level, but we'll need to go into much more details later on. 19:39:24 ... Design principles: same stuff as said earlier. A simple app does not need to know a lot about underlying things. 19:39:45 ... Looking at use cases that enable things. 19:40:06 ... Starting with connecting to media: connecting to devices, cameras, microphones. 19:40:25 ... Do we have an API to enumerate what the various cameras are on a device? 19:40:40 ... Example of laptop with different cameras. 19:40:46 ... I'd like some feedback. 19:41:18 hta: one thing that is fairly common is "switching to headset". 19:41:49 ekr: also common that the system picks up the wrong camera. The feature that is imperative is that the user gets the choice. 19:41:49 switching to headset is taken care of the OS though (in the most common cases) 19:42:16 ... whether it's a web app or a chrome issue is still tbd. 19:42:45 tablets: front/rear, etc. May be able to group with user giving permission to use hte camera 19:43:10 TedHardie: two cases. One is when you want to set a default. Second is when you want to switch or mix. 19:43:55 ... For the enumeration, I do think that the JavaScript needs to be able to query that information from the browser, but not for naming. 19:44:42 cullen: an API to find out the current list of media devices and some notifications mechanism to tell us what modifications there are to that. 19:45:06 DanDruta: that ties with the consent problem. 19:45:33 Right: camera/mic plugin/removal. Consent needed for a new device to be used 19:45:55 TedHardie: I disagree. The need for consent needs to be on a per call basis. 19:46:11 gape has joined #webrtc 19:46:20 DanDruta: I may not want to give permission to an app to see my face, but may be ok for it to see my room. 19:46:25 Though a user could (at their option) pre-give consent for a specific device/app combo 19:47:09 Tim: the ability to enumerate the different cameras may raise a security concern as it gives the ability to fingerprint the browser more easily. 19:48:02 MatthewKoffman: when you install Skype on a tablet, for instance, you typically enable the app to access cameras. 19:48:13 Related issue: naming of cameras - "standard" names vs user input names vs generic names (camera_1, etc) 19:48:39 cullen: the permission problem is increadibly complex. 19:48:57 ... I don't think we have enough to nail down the many ways we may need to access the camera yet. 19:49:22 Is the solution to the permission problem part of our spec, or something for each implementation to decide on? 19:49:31 alissa: thinking about the use case where you may want to use the camera to take still pictures but not to stream video 19:49:46 stefan: coordination with DAP. We'll handle streams, they will handle still pictures. 19:50:21 actually, I think Alissa's concern was that this API might be used to record but not stream 19:50:33 cullen: you should be able to add new cameras/microphones and switch to that at any time. 19:50:48 yeah, capture or record, but not stream 19:51:11 right, capture. and then presumably do evil. 19:51:35 cullen: the currently proposed API does not give you much in terms of ICE process. 19:51:55 ... The one issue that I want to ask is how do we want to pass credentials? 19:52:19 ... Does the JavaScript see the password? 19:52:44 hta: good question on what the model is. Whether it's on the user, browser, or server. 19:53:58 cullen: [examples of different TURN servers configurations found in the wild] 19:54:24 MatthewKoffman: do we need to have calling use cases that involve enterprises? 19:54:29 cullen: there's one. 19:54:56 ACTION: cullen to send a server-provider TURN use case and user-provider TURN use case 19:54:56 Created ACTION-7 - Send a server-provider TURN use case and user-provider TURN use case [on Cullen Jennings - due 2011-07-30]. 19:55:35 cullen: other things we could possibly want to be notified about such as: 19:56:09 ... can't gather address from one of servers, fail to connect to TURN server, other side disconnects. 19:56:14 ... etc. 19:56:51 ... Each time you get a better path to the other side, knowing about that would help debugging things a lot. 19:57:19 TedHardie: why would we want that other than for debugging? 19:58:23 Another point Matthew made a moment ago that Cullen wanted captured: may want to know when my (the user's) address changed. 19:58:52 ... If you chose 2 instead of 3 or 4, do you want this to be passed back to the JavaScript? 19:59:28 MatthewKoffman: yes, you need that for several purpose 19:59:46 cullen: to tell people to switch to another NAT, because the current one is evil. 20:00:30 hta: I can imagine that people will say that not passing the address back to JavaScript is actually a security feature. 20:00:48 +1 20:00:50 MatthewKoffman: I can explain why it's a fake security issue. 20:01:15 The remote address is trivially available on the wire since data is going peer-to-peer 20:01:29 Not to the JS. 20:01:42 True 20:01:54 [discussion on aggressive/fast/low mode] 20:02:18 Colin: sometimes you want not to use the best possible connectivity, but maybe something below. 20:02:39 Christer: not so much an error, rather a choice when you call the API. 20:02:53 I'm concerned that the API not force the JS application; after all, some of these applications are simply going to say "sorry, video/audio not available" to the user, where this is an add-on to the basic application (the poker site video use case) 20:03:18 Sorry, missed the text "to deal with this level of detail" 20:04:52 ekr: connectivity check, you're going to want to know whether the connection is direct or through the relay, etc. 20:05:19 MatthewKoffman: that's the sort of information you know to be able to say: "your NAT is fine, it's John's NAT that's crappy". 20:05:57 [calling for a 15mn break. Discussion to continue afterwards] 20:14:07 gape has joined #webrtc 20:17:05 s/…/.../g 20:17:11 RRSAgent, draft minutes 20:17:11 I have made the request to generate http://www.w3.org/2011/07/23-webrtc-minutes.html francois 20:28:57 Gape has joined #webrtc 20:32:07 Present+ Gonzalo_Camarillo 20:32:16 Present+ Ted_Hardie 20:32:24 Present+ Emile_Stephan 20:32:45 Scribe: Dan_Burnett 20:32:50 Present+ Roni_Even 20:32:52 ScribeNick: burn 20:33:17 Present+ Andrew_Hutton 20:33:26 Topic: ICE 20:33:53 Topic: Signaling 20:33:56 Present+ Leon_Portran 20:33:57 Cary has joined #webrtc 20:34:10 Present+ Alan_Johnston 20:34:11 Cullen: for non-ICE signaling, when do you send messages? 20:34:21 Present+ Ross_Finlayson 20:34:37 ... need to add all media codecs before end of javascript (all at same time). when function call returns, signaling is sent 20:35:14 ... Other option is "open" we proposed. 20:36:06 ... either add explicit startsignaling, or queue up everything and add at once which means implicit signaling 20:36:22 Matthew: do it the way everything else does, whatever that is. 20:36:32 ... I think browsers do it implicit way. 20:36:36 Present+ Ram_Ravinaranath 20:36:36 tedhardie has joined #webrtc 20:36:41 tlr has joined #webrtc 20:36:44 ... because every time control is returned it re-renders 20:36:45 Present+ John_Elwell 20:36:56 Christer: who is doing negotiation? 20:37:20 Present+ ThomasRoessler 20:37:28 Cullen: not javascript that does signaling 20:38:07 EKR: you express opinions to PeerConnection about what you would like, and invisible to JS this happens in the background as necessary 20:38:21 Cullen: some negotiation will happen, done by the browser 20:38:21 carybran has joined #webrtc 20:39:03 DanDruta: this is early vs. late binding. either give pref in advance or control directly. 20:39:22 Present+ Alissa_Cooper 20:39:32 Present+ Timothy_Terriberry 20:40:16 Cullen: one way as you get permission and access to media streams, you gather up and then put all in the PeerConnection object at once. alternatively, could add to PeerConnection one at a time as you get them but don't start sending media on any until you say go. 20:40:31 (missed Matthew comment) 20:40:53 EKR: they are really equivalent 20:41:01 Present+ Dan_Romascanu, Jon_Peterson, Bert_Wijien, Nar_Gadiraju, Xavier_Marjou, Christer_Holmberg, Miguel_Garcia, Magnus_Westerlund, Colin_Perkins, Salvatore_Loreto 20:41:11 Stefan: should be able to add and remove during session. confusing if you have to do startsession. 20:41:28 Present+ Dan_Druta, Bert_Greevenbosch, Matthew_Koffman, Eric_Rescorla, Cary_Bran 20:41:38 EKR: JS VM must not start until control has returned from all JS. 20:41:46 Cullen: this is not true of all JS. 20:42:03 Cullen: sounds like leaning towards implicit. 20:42:16 Matthew: yes, but treat everything as an add. 20:42:32 Roni: and need delete as well 20:42:41 Cullen: negotiation is implicit 20:43:48 Cullen: most of the APIs were leaning towards SIP-style SDP offer/answer, thought there was consensus there. 20:44:10 ... three models: SIP, Jingle, or raw SDP in offer/answer wrapper. 20:44:48 ... another variant is an advertise/propose model that I had sent in. 20:45:11 ACTION: Matthew to send some text around SDP 20:45:11 Sorry, couldn't find user - Matthew 20:46:01 Colin: all payload formats use offer/answer semantics, so keeping that would be helpful. 20:46:31 Matthew: Need to be able to determine what kinds of coders/decoders you have. 20:46:52 hta: have never seen a use case where you need to know which coder/decoder you're using. 20:47:40 Matthew: matters for audio recording. same as determining whether you can do real-time media. if API allows recording of video, need to be able to know how to encode it, resolution, etc. 20:47:49 ... maybe other groups might do this, but it needs to be done. 20:48:13 ... want to be able to choose from JS which encoding, etc. to use. 20:49:10 (missed comment from Harald on why this is necessary). 20:49:39 hta: JS coder needs to just say "I want to communicate" but not necessarily how. 20:50:29 Matthew: what if browser is a terminal for PBX. want browser to act more like Skinny phone than SIP phone. 20:51:20 Cullen: replace skinny with MGCP for this discussion. you need to know things about device. can't nogotiate SDP without knowing additional info. 20:52:09 Roni: there are many parameters, not all are codec-specific. Some params you need to have anyway. 20:53:15 Ted: maybe middle ground is advertise/offer/answer. First send what's available, then offer/answer from then on. You get an informed O/A and can still use O/A. 20:53:46 ... gateway should not need to have fundamental semantic shifts. Adv/O/A leaves you with the same semantics as SDP. Should discuss over beer. 20:54:06 Stefan: we need this data to negotiate, but is it part of this API? 20:55:14 JonPeterson: O/A always had the notion of counter-proposal. SDP can describe sessions well but not negotiate. So you can describe a complete session and allow a counter-proposal for something better. 20:55:28 Ted: makes gateways too complex. 20:55:48 Jon: if offer or answer described full session, yes, but it doesn't. 20:55:51 tlr has joined #webrtc 20:57:02 hta: no matter how we do this, we will see JS parsing these negotiation blocks. If we want to support our use cases, this will need to be gatewayed eventually anyway. 20:57:30