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

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

From: Cullen Jennings <fluffy@cisco.com>
Date: Mon, 18 Jul 2011 11:01:48 -0700
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-Id: <6C570034-97F2-459D-8E79-C6F0DD745721@cisco.com>
To: Francois Daoust <fd@w3.org>

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?



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 Monday, 18 July 2011 18:02:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 18 July 2011 18:02:22 GMT