W3C home > Mailing lists > Public > public-webrtc@w3.org > January 2013

Re: First agenda draft Boston f2f meeting

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Wed, 16 Jan 2013 14:30:28 +0100
Message-ID: <50F6AB74.5010400@ericsson.com>
To: public-webrtc@w3.org
On 2013-01-16 12:31, Harald Alvestrand wrote:
> On 01/15/2013 08:51 PM, DRUTA, DAN wrote:
>> Hi Stefan,
>>
>> I would like to suggest squeezing one more topic in the agenda for
>> WebRTC.
>> We got some good discussions on the list related to your proposal for
>> the Priority API but it will be useful if we get some face to face
>> conversation going and see if we can capture some consensus points.
> Dan,
>
> we considered that, but we couldn't figure out what was of lesser
> importance so that we could reduce its timeslot.

That is right, what could be added is that we tried to cover what would 
be relevant given the parallel discussions proposed for the 
RTCWEB-MMUSIC part of the meeting.

There is nothing about priority on that agenda, if it was added I think 
we should consider bumping it up in priority(!) for our discussions in 
the WebRTC WG part of the meeting.

>
> If the people working on specific settings (Giridhar, Travis, Cullen)
> can prepare well for the meeting and have a limited set of contention
> points to present to us, it might be possible to get that piece done in
> 1.0 hours rather than 1.5 so that we can start the webrtc part of the
> meeting half an hour earlier - but we're always getting complaints that
> we get too many items and too few conclusions...
>
>>
>> Thanks,
>> Dan
>>
>> -----Original Message-----
>> From: Stefan Håkansson LK [mailto:stefan.lk.hakansson@ericsson.com]
>> Sent: Tuesday, January 15, 2013 2:48 AM
>> To: public-webrtc@w3.org
>> Subject: First agenda draft Boston f2f meeting
>>
>> Hi all,
>>
>> below is a first proposal of agenda items, along with some info on what
>> we thought should be covered, for the Boston face-to-face meeting. It
>> includes Media Capture TF and WebRTC WG for completeness.
>>
>> We would very much appreciate feedback on this proposal. Perhaps most
>> importantly if there are things we should cover that are missing, but
>> also if there are things we could skip in favor or longer discussions on
>> other topics.
>>
>> Stefan for the chairs
>>
>> Media Cap:
>> ==========
>> Day 1 - 4 hours
>> ---------------
>> "Media Capture and Streams" document:
>>
>> * device enumeration
>>     Decision:
>> * error handling
>>     Decision: Use the PeerConnection-callback model, or use the model
>> used
>> in IndexedDB, File API (return objects that represent operations, errors
>> as events on the objects).
>> * "immediate stream" gUM
>>     Decision: No, backwards compatible gUM, new gUM call style.
>> * Identity aspects of MediaStreams
>>     Yes or no?
>>     Stream or track level binding?
>>     Implications?
>> * Resource reservation (exclusive access to devices)
>>     Specified in gUM or "implementor choice"?
>>     One stream from a source or multiple streams from a source?
>>     Exclusive, shared-in-tab, shared-in-browser, anything-goes?
>>
>> Day 2 - 3 hours
>> ---------------
>> * Settings/constraints (2h)
>>     Model (0.5 hours)
>>     What settings to have in v1 (1.5h)
>>
>> * Decide next steps for doc (last call WG) (0.5h)
>>
>> Recording document (0.5h):
>>     Approval for publication as FPWD (close call at the meeting)
>>
>>
>>
>> WebRTC:
>> =======
>> Day 2 - 1 hour
>> --------------
>> * Call flow
>>     Walk through examples in spec
>>     Note disagreements on "what happens here"
>>     Note questions about "what happens here if...."
>>     Don't make decisions - list questions
>>
>> Day 3 - 4 hours
>> ---------------
>> * MediaStream and MediaStreamTrack - SDP interface (1.5h)
>>     (Based on the conclusions from rtcweb/mmusic)
>>     What id's/labels needs to be signaled
>>     How to handle rejection (support now? How?)
>> * Error handling (0.5h)
>>     Sticking to current principles
>>     Specific errors and additional error data
>> * Data channel (0.5h)
>>     Verify that we pass all info needed for SCTP setup, and vice versa
>> * Rollback (hope this is just API, and settled)
>> * Stats (1h)
>>     Stats needed, whether current are well defined
>>     Where should stats specs live? (IANA registry, IETF doc, W3C doc, all
>> of the above?)
>>
>> * Next steps, open issues list (0.5h)
>>
>>
>
>
Received on Wednesday, 16 January 2013 13:30:52 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:32 UTC