Re: List of items noted during f2f

I'm happy to pick up a couple of the open items if you need text
suggestions.  I even promise not to apply Standard comment #22.

On 4 November 2012 07:41, Stefan Håkansson LK
<stefan.lk.hakansson@ericsson.com> wrote:
> IETF needs to:
> ==============
[...]
> * Design signaling for _app_ rejecting to receive streams/tracks

I'm not sure about this one, it seems to be an API issue, though that
obviously has some implications for SDP generation and consumption.

> * design a=content signalling into JSEP (accepted at W3C)

I'll note that we never really decided to use the a=content stufff for
mediastreams, though I don't think that there were any issues with
doing so.  It was never directly discussed.

I can understand how this might be an IETF issue if we decided to
allow for arbitrary content labels, which I have heard a desire to do,
privately.  We didn't decide that though.

> * (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
> ======
[...]
> * Stats API: Write up ICE stats, propose naming. Allow sequence(value) - HTA

Specifically: allow structure (so as to not rely on structured names)

> * SDP offer validity lifetime: Decided to be “until stable state”

Not so, we decided that "until stable state" was not sufficient and
that we would have to decide on a time, expressed in seconds.  This
would allow for asynchronous calls out to servers and the like to make
decisions.

> * Candidate generation: Document pool model. Who?

...default value of 0 that changes at setLocalDescription.  Implies
timing requirements.

> * Settings propagation through a PeerConnection must be worked out. Who?.

This had a dependency on the IETF, specifically regarding how things
like resolution would be "negotiated".  Application/SDP/RTCP.  Open
issue.

> * Rollback: Need to specify how to get current, transient and future state
> when negotiating.

We also decided *how* to implement rollback.  That's a bigger deal.  I
indicated that it might be nice to be able to determine the active
state, but - like the a=content thing - we didn't really agree to
anything (unless I assume that the absence of debate implies
acceptance, which I've found to be a very poor substitute for real
assent).

> * Vanilla SDP handling: How to handle SDP without SSRC signalling

Yes, and see synchronization topic.

> * Signalling model for propagating rejection of tracks back to originator

I don't get this one.  Isn't that ANSWER?

> * API for informing originator that tracks (or entire stream) has been
> rejected (by receiving app, or even receiving UA)

This would be the offerer, as opposed to sender, yes?  Answer?

> * Add application of “content label” to MediaStreams when adding them to a
> PeerConnection

See above.

Received on Sunday, 4 November 2012 17:02:30 UTC