Re: First agenda draft f2f TPAC

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:15:58 UTC