[minutes] WebRTC Teleconference - 2011-07-12


The minutes of last week's teleconference are available at:

... and copied as raw text below.

Harald summarized discussions in:
  (I added these notes to the end of each section in the minutes)


12 Jul 2011


       [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


           Dan_Burnett, francois, Alissa, Caroline?, Cary_Bran,
           Tim_Panton, Christophe_Eyrignoux, hta, Anant, John_Elwell,
           Cullen_Jennings, Ralph_Giles




      * [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?

    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-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.


    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
    ... 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
    ... That's a fundamental difference between our proposal and WHATWG

    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

    <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
    ... 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

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

    <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

    [meeting adjourned by consensus :)]

Summary of Action Items

    [NEW] ACTION: RalphGiles to consult a JavaScript expert on race
    condition [recorded in

    [End of minutes]

Received on Monday, 18 July 2011 11:18:39 UTC