List of items noted during f2f

Harald and I assembled the following list immediately after the meeting. 
We will transfer the WG internal things into actions or bugs eventually, 
and probably add more things as a result of reviewing the minutes, but 
wanted to get the list out ASAP to get comments/feedback.

The IETF part is most urgent since that meeting is next week already.

A similar mail will be sent to the Media Capture TF list.

IETF needs to:
==============
* Get BUNDLE settled
* Produce list of SDP extensions that MUST / MUST NOT / MAY be supported
* Produce list of things that must be changeable in SDP
* Produce list of things that cannot be changed in SDP
(“none of the above” is on W3C to report)
* Decide if Trickle-ICE is “allow”, “ignore for now”, or “don’t know”
* Revise MSID proposal to use ID, not index, for tracks
* Design signalling for max # of SSRCs in an m-line / RTP session 
(magnus’ draft - IPR issue) - or other means for UA receiving streams to 
reject when out of resources
* Design signaling for _app_ rejecting to receive streams/tracks
* design a=content signalling into JSEP (accepted at W3C)
* (Possibly for later): signaling for pause/resume sending over network 
(to enhance efficiency)
* (Possibly for later): Decide if SDES key exchange must be supported or not

WEBRTC
======
* Incorporate suggested error handling in document - Anant
* DTMF proposal - HTA to update with “Object oriented” approach
* API for requesting priority on tracks (attribute, constraint or both) 
- Stefan to write proposal
* Stats API: Write up ICE stats, propose naming. Allow sequence(value) - HTA
* MediaStream and MediaStreamTrack: Lose array, use id() property. - 
Adam to update.
* CreateOffer / CreateAnswer / Set* call serialization (semaphore). Anant
* SDP offer validity lifetime: Decided to be “until stable state”
* Candidate generation: Document pool model. Who?
* Settings propagation through a PeerConnection must be worked out. Who?.
* Rollback: Need to specify how to get current, transient and future 
state when negotiating.
* Vanilla SDP handling: How to handle SDP without SSRC signalling
* Early media handling: How to handle packets arriving before SDP ANSWER
* API to reject (or close) (offered only, or also currently streaming?) 
tracks or streams at receiver .
* Signalling model for propagating rejection of tracks back to originator
* API for informing originator that tracks (or entire stream) has been 
rejected (by receiving app, or even receiving UA)
* Add application of “content label” to MediaStreams when adding them to 
a PeerConnection


Stefan for Harald and Stefan

Received on Sunday, 4 November 2012 07:42:13 UTC