- From: François Daoust <fd@w3.org>
- Date: Tue, 19 Jul 2011 16:31:46 +0200
- To: Cullen Jennings <fluffy@cisco.com>
- Cc: <public-webrtc@w3.org>
On Mon, 18 Jul 2011 11:01:48 -0700, Cullen Jennings wrote: > I note the minutes say > > Since all the proposals for API are based on the WHATWG > PeerConnection > model, this is the model we are going to be starting from. > > I brought this up at the end of the call and Harald did clarify that > we are going down design paths that are similar in some ways but > different in other ways to the current version of that proposal. I > want it to be clear we did not decide we using that document as a > starting point for the work. Do I have that right? I'm not sure I parse your comment correctly. What difference do you make between "model we are going to be starting from" and "using that document as a starting point for the work"? I would expect changes, of course, perhaps ending up with a proposal that is very similar to the one you shared. Francois. > > > > On Jul 18, 2011, at 4:18 , Francois Daoust wrote: > >> Hi, >> >> The minutes of last week's teleconference are available at: >> http://www.w3.org/2011/07/12-webrtc-minutes.html >> >> ... and copied as raw text below. >> >> Harald summarized discussions in: >> http://lists.w3.org/Archives/Public/public-webrtc/2011Jul/0066.html >> (I added these notes to the end of each section in the minutes) >> >> Francois. >> >> >> ----- >> 12 Jul 2011 >> >> [2]Agenda >> >> [2] >> http://lists.w3.org/Archives/Public/public-webrtc/2011Jul/0024.html >> >> See also: [3]IRC log >> >> [3] http://www.w3.org/2011/07/12-webrtc-irc >> >> Attendees >> >> Present >> Dan_Burnett, francois, Alissa, Caroline?, Cary_Bran, >> Tim_Panton, Christophe_Eyrignoux, hta, Anant, John_Elwell, >> Cullen_Jennings, Ralph_Giles >> >> Regrets >> Chair >> Harald >> >> Scribe >> francois >> >> Contents >> >> * [4]Topics >> 1. [5]Requirements document >> 2. [6]APIs >> 3. [7]Quebec meeting >> * [8]Summary of Action Items >> _________________________________________________________ >> >> <ceyrigno> ceyrigno is christophe (eyrignoux) from france telecom >> >> <cullenfluffyjenni> John Elwell on phone only >> >> <cullenfluffyjenni> +1.408.421.aaff is me Cullen Jennings >> >> <Cary> Cary == Cary Bran >> >> <steely_glint> I have no idea what my callerid will be, but I'm >> Tim >> Panton == steely_glint >> >> <steely_glint> I've contributed on the mailinglist. but I don't >> expect to speak. >> >> <steely_glint> tim@phonefromhere.com Phnefromhere.com Ltd >> >> <cullenfluffyjenni> John Elwell from siemens-enterprise.com >> >> <scribe> scribe: francois >> >> harald: 3 things on the agenda today: requirements, APIs and >> inputs >> for the Quebec city meeting. >> ... Anything to add to the agenda? >> >> [nothing heard] >> >> Requirements document >> >> harald: Stefan sent a draft requirements document to the list just >> before the meeting. >> ... on the 10th. >> ... Anyone seen the document? >> >> -> >> >> [9]http://lists.w3.org/Archives/Public/public-webrtc/2011Jul/0008.ht >> ml Stefan's announcement email >> >> [9] >> http://lists.w3.org/Archives/Public/public-webrtc/2011Jul/0008.html >> >> <burn> Doc is at >> >> [10]http://lists.w3.org/Archives/Public/public-webrtc/2011Jul/att-00 >> 08/webrtc_reqs.html >> >> [10] >> http://lists.w3.org/Archives/Public/public-webrtc/2011Jul/att-0008/webrtc_reqs.html >> >> anant: I'm all for adopting it as a working document. >> >> harald: anyone seen it who doesn't like it? >> ... I think we need to be careful about it. I would like to ask >> everyone to read carefully the document. >> ... Any comment should be sent to the list. >> ... We probably need some precise definitions. >> >> Cary: are DTMF not required? Handled differently? >> >> Harald: I don't see a requirement for DTMF here. The text got >> extracted from the one in IETF where DTMF was added afterwards. >> ... Please send a comment about it on the mailing-list. >> >> Cary: ok. >> >> Topic summary (part added after the meeting): The list of >> requirements from Stefan is a good starting point. We'll all >> review >> them with some care to figure out that we know what they mean, and >> refine as needed. >> >> APIs >> >> Harald: 3 pieces following our call for proposals: one was a >> pointer >> to the WHATWG section. One was a pointer to the 2 specs of the >> Audio >> WG. >> ... One of them being build on the PeerConnection proposal. >> ... The final one is from Cisco, built from PeerConnection but >> suggesting some changes. >> ... Any other things? >> >> Cullen: Fair summary, I think. >> >> Anant: We tried to explain the differences from the WHATWG >> proposal. >> Comments received are good. >> >> Cullen: one of the things I was hoping to discuss today is ???. >> Discussion with Ian. >> ... All the options we added are by no means the default. The >> examples we put on the Wiki page are simple use cases. >> ... For more sophisticated use cases, we should provide more >> precise >> controls. >> ... That's a fundamental difference between our proposal and >> WHATWG >> proposal, >> >> Anant so feedback is very much welcome on level of exposure we >> should give to Web apps. >> >> Cary: I think it's probably useful to add extensibility mechanisms >> for future use cases. >> >> Cary: we want things to be the same in all browsers. >> >> Harald: to me it seems kind of obvious that if the machine cannot >> figure things by itself, then we need to provide the mechanism to >> provide the info. >> >> Cullen: The stack does have voice detection capabilities. In the >> Google stack, it will guess. But we need more experience. >> >> <Cary> Francois - Cullen is speaking not me >> >> ??4: there are use cases where the application needs to tell the >> browser things it cannot determine by itself. >> >> [discussion about something possibly missing in ICE, following >> exchanges with Ian.] >> >> [Scribe missed last technical comments, feel free to make your >> points on IRC] >> >> Cullen: 3 people talking to each other. We could do it in >> different >> ways, with one, two or 3 PeerConnection objects. >> ... It seems to me that the API is not clear on how to handle >> multiple streams. >> ... Mapping between RTP level and API is not clear. >> >> Harald: with audio and video going on different RTP sessions, you >> do >> need multiple ICE connections inside a PeerConnection. >> >> ??4: a PeerConnection can handle multiple streams which can >> contain >> multiple tracks, is that correct? >> >> [sounds correct] >> >> Cullen: question on the table for the group is: do we want >> separate >> PeerConnection objects to talk to different peers, or one >> PeerConnection can be reused? >> >> Harald: with current proposals, you can send multiple streams to >> multiple PeerConnection objects. >> >> Anant: there could be a PeerConnection factory that creates the >> PeerConnection objects dynamically. Don't have strong preferences, >> but has to be expressed. >> >> Harald: the way we so far have gone with the specification and >> negotiation protocols is that listening is not well-defined. >> ... You can do anything you want to get the negotiation blob which >> you hand over to the PeerConnection. >> >> Cullen: The assumption I make is that browsers know what they can >> do >> with the blob. >> >> ??6: It seems that we're pushing for a lot of code to be run >> server-side. Has the group discussed whether it's better than >> doing >> things more P2P? >> >> scribe: I've not been following the details, just joined here. >> >> <steely_glint> Are we _sure_ we couldn't implement a SIP client in >> javascript based on the API. >> >> scribe: If we're going to implement an entire SIP stack anyway... >> >> [Jingle mentioned] >> >> ??6: Jingle relies on presence status. Something missing from >> current proposals. >> >> <steely_glint> jingle presence can be done entirely in the >> browser. >> >> Cullen: possible race condition in WHATWG spec, can someone >> enlighten me? >> >> Harald: is there a JavaScript expert in the room? I don't think >> so. >> >> Cullen: Right now in the WHATWG, you create a PeerConnection >> object, >> and then wait for the callback. There's something to avoid a race >> connection but I don't understand how it works. >> >> Tim: I'm not a JavaScript expert, but my assumption was that these >> kind of transitions can only happen in a stable state. You have >> time >> to set the callback. The browser continues to execute the script. >> ... That may just be a point that needs to be clarified, but could >> be what Ian is talking about. >> >> Cullen: Obviously, we all agree that they cannot be a race >> condition. If the way to solve it in JavaScript is as specified, >> then good. I just don't want any race condition. >> >> <scribe> ACTION: RalphGiles to consult a JavaScript expert on race >> condition [recorded in >> [11]http://www.w3.org/2011/07/12-webrtc-minutes.html#action01] >> >> <trackbot> Sorry, couldn't find user - RalphGiles >> >> harald: I think that the consensus we're reaching is that the API >> that we'll end up with will be based on the WHATWG proposal. >> ... and the details need to be discussed on the mailing-list. >> >> Cullen: "based on" means "reference" or "define a similar API"? >> >> Harald: my understanding is that our aim is to end up with a >> single >> document. >> ... I would like to explore offline exactly how we do the editing. >> >> Dan: There needs to be a W3C document for this to progress in W3C. >> It needs to be written as a W3C working draft. >> >> [discussion on document format, editor's draft for internal >> group's >> discussions, then public working draft when group is ready to >> publish it. That's really the first time when the external world >> "sees" the proposal?] >> >> francois: [mentions WebRTC wiki as a possible way to edit the >> document. No need for more formal submission] >> >> ??9: I second the Wiki format. >> >> Harald: ok, good progress here. >> >> Topic summary (part added after the meeting): Since all the >> proposals for API are based on the WHATWG PeerConnection model, >> this >> is the model we are going to be starting from. Discussion on the >> various proposals for changes / extensions to the model (including >> the audio API and the Mozilla/Cisco proposal) seem to be healthy >> and >> ongoing, so there is no need to take a decision on these proposals >> now. >> >> Quebec meeting >> >> -> [12]Results of F2F Registration poll >> >> [12] >> http://www.w3.org/2002/09/wbs/47318/webrtc-f2f-quebec/results >> >> <anant> I'm sorry I have to hop out for another meeting, but we've >> concluded the API discussion (we can followup further on the >> mailing >> list) >> >> <anant> thanks >> >> <rillian> thanks, anant >> >> francois: 31 people registered so far. Please do so in the next >> couple of days if you still haven't done so. >> >> harald: ok, so action item for everyone here. >> ... If there are things you want to see on the agenda, please >> bring >> them to the mailing-list. >> ... Any other business? >> >> [silence heard] >> >> Topic summary (part added after the meeting): The Quebec City >> meeting will also be focused on requirements and API. Remember to >> register! >> >> [meeting adjourned by consensus :)] >> >> Summary of Action Items >> >> [NEW] ACTION: RalphGiles to consult a JavaScript expert on race >> condition [recorded in >> [13]http://www.w3.org/2011/07/12-webrtc-minutes.html#action01] >> >> [End of minutes] >> > > > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html
Received on Tuesday, 19 July 2011 14:32:15 UTC