Re: First agenda draft f2f TPAC

Thanks for providing feedback,

perhaps we should move things around.

Of the things you mention, all are in the first day (but afternoon) in 
the current draft, except for privacy which we put in the Media Capture 
part since most of the discussion so far has been related to access to 
input devices and finger print implications thereof.

Stefan
On 10/22/2012 03:15 PM, Cullen Jennings (fluffy) wrote:
>
> I'd like to see the following moved to the first day as they are most
> important
>
> Error handling - how are we going to do this in general
>
> Stats - we need to deal with things like is this flat or nested and
> how we are going to do it
>
> Constraints - we need to nail this down and make sure we all agree on
> how it is going to work. Particularly how they are changed later on
>
> Permissions and privacy - this is still pretty hand wavy and going to
> be holding up implementations real soon now
>
> The sequence of how operation, particularly callbacks happen - I
> think this is in the sequence diagram reviews mentioned but we to get
> crisp on this. A key point that needs to be resolved is when a peer
> receives an offer, how it can tell what's in it before deciding to
> accept or reject it.
>
>
>
>
>
> On Oct 17, 2012, at 6:28 AM, Stefan Hakansson LK
> <stefan.lk.hakansson@ericsson.com> wrote:
>
>> All,
>>
>> we've put together a draft agenda for the f2f meeting, see below.
>> Please let us know what you think. Should something be removed,
>> something added?
>>
>> Also, we have proposed who will be responsible for each session. If
>> you have been assigned to something you for some reason don't want
>> to do please let us know. Also, if you would like to be involved in
>> the preparation of one or more sessions, let us know that.
>>
>> Stefan for the chairs
>>
>> Monday morning 0830--1200 ========================= * welcome and
>> stuff
>>
>> * API functionality (MediaStream related) that has been discussed
>> but is not currently supported, what of this should we support in
>> v1? - Stefan
>>
>
> All the stuff here we have agreed to do in previous meetings and is
> trivial once we get the constrains stuff sorted out. I think this
> section could be reduce to about 15 minutes.
>
>> ** Sender side (all per track) *** Priority *** bw ***
>> width/height *** agc toggle switch *** bw/cong. feedback
>>
>> ** Receiver side *** reject certain or all tracks in offer ****
>> should app be able to? *** inform the sender of used / useful
>> width/height *** tell the sender that a stream/track is not played
>> (paused/unattached/ended)
>>
>> ** Not certain what side *** Control of AEC (echo cancellation)
>>
>> ** Agree on what of the above we need *** What in v1; what we can
>> move to v2 but “make room for” in v1; what we can’t see need for
>> *** One time, or possible to change?
>>
>> ** Discussion leads to requirements to IETF on SDP and RTCP
>> capabilities
>
> uh, sort of doubt any of this leads to anything that is not already
> in progress at IETF
>
>>
>>
>> * Coffee break 1030-1045
>>
>> * SDP handling - Martin T, Cullen
>
>
>> ** How long is an SDP created with createOffer/Answer valid?
>
> The above point is addressed in the specs. Glad to clarify if there
> is a problem. The rest of the points are pretty vacuous and as far as
> I can tell more related to IETF work that W3C. If we can get some
> specific things that are W3C issues, sure but as this stands it's
> just more lets explode stuff. I think this section should get a lot
> more specific about what problem it is trying to solve and should be
> pushed to last topic on last day.
>
>
>> ** Rollback funtionality *** at setLocal(offer) at offerer *** at
>> setRemote(offer) at answerer *** at setLocal(answer) at answerer
>> *** at setRemote(answer) at offerer *** What does an application do
>> to recover when the UA rejects the set* call?
>>
>>
>>
>> * Lunch 1200-1300
>>
>> Monday afternoon 1300-1800 ========================== * General
>> error handling principles - Anant
>
> This topic needs an hour
>
>
>>
>> * Call flows - Cullen’s sample flows - Cullen ** Walk through a
>> flow or two, verify that we understand what the transitions mean
>
> This topic need two hours
>
>
>>
>> * Stats - Harald
>
> This topic needs 2 hours
>
>> ** Conclude stats model ** Specific stats for *** Transports ***
>> ICE addresses / address pairs *** ???
>>
>> * Conclude DTMF (we hope) - Harald, Justin
>
> I'd guess this needs 30 minutes
>
>>
>> * Finish for the day
>>
>>
>> Tuesday morning 0830-1200 ========================= * API
>> functionality for remove stream - Harald ** Empty indices in
>> local/remoteStreams or not?
>
> We really need to nail this one down. Perhaps an hour?
>
>>
>> * States - Cullen, Justin ** PeerConnection ** ICE agent ** What is
>> exposed to application?
>
> Probably need 39 minutes to an hour for states.
>
>
>>
>> * End of WebRTC WG meeting (afternoon is Media Capture)
>>
>>
>

Received on Monday, 22 October 2012 13:38:57 UTC