See also: IRC log
<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]
harald: Stefan sent a draft
requirements document to the list just before the
meeting.
... on the 10th.
... Anyone seen the document?
-> http://lists.w3.org/Archives/Public/public-webrtc/2011Jul/0008.html Stefan's announcement email
<burn> Doc is at 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 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 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.
-> Results of F2F Registration poll
<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 :)]