W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2011

Re: [minutes] WebRTC Teleconference - 2011-07-12

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>
Message-ID: <95c7a14c7bb791767174977a27dfe077@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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 19 July 2011 14:32:15 GMT