On 11/04/2012 06:02 PM, Martin Thomson wrote:
> 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.
Thanks, that is much appreciated (and I saw you already provided a
proposal for sync getUM!).
>
> 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.
This is how I understand this area: For rejection, there are two situations:
* the first one is that the receiving browser does not have enough
resources to handle all offered tracks. This could in principle be
handled by the "max-ssrc" proposal (meaning that the sender would in
certain situations know that the receiver can not handle all added
MediaStreamsTracks, so it could be dealt with already before sending an
offer or answer).
* the second one is that the app at the receiving end for some reason do
not want (some of) the RTP streams that the sending end wants to send.
Here, we do need an API for rejecting, but in addition a mean to signal
this.
* signaling is straightforward for the case when the initiating app
wants to send more than the responding app wants to receive, since the
SDP answer can provide this info (the details on how it is done depends
on if there is one m-line per RTP stream, or if several RTP streams are
part of a single m-line).
* but, for the case when the responding app wants to send RTP streams to
the initiating that it does not want, there can be a problem and that is
if this info (about what the responding app intents to send to the
initiating app) if conveyed by the SDP answer since the SDP answer
finalizes the SDP o/a and there is no "ack" on that answer that could be
used to tell the other end about rejected RTP streams (ROAP had a "ack"
message that could have been used)
>
>> * 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.
It was mentioned, but not discussed. I took the lack of discussion (or
objection) as in indication of that we could have a=content as a working
assumption for the time being, but I agree, this was not discussed or
decided.
>
> 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)
That was also my understanding.
>
>> * 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.
My recollection was that Matthew towards the end of the discussion said
something about that he was fine with "stable state" and that everyone
seemed to agree (and I think that is what the scribe caught at 11:30 -
11:37 in http://www.w3.org/2012/10/29-webrtc-irc).
But we should discuss this some more on the list if this is not what
others took away from that discussion.
>
>> * Candidate generation: Document pool model. Who?
>
> ...default value of 0 that changes at setLocalDescription. Implies
> timing requirements.
I don't follow. Could you elaborate (I'm sure you're right, I just want
to understand your thinking)?
>
>> * 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.
Agree.
>
>> * 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).
I agree, there are a lot of things here that need to be discussed and
worked out.
>
>> * 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?
Yes, that would be the ANSWER, but how it should be visible in the SDP
depends on one/many m-lines, BUNDLE and I guess some more things that I
don't know of. And it should be specced. And then we have the situation
discussed earlier in this mail when the responding app wants to send
tracks to the initiating side that are not wanted, and signals this in
the ANSWER, then there is no "ack/nack" message to carry rejection info.
>
>> * 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?
See above.
>
>> * Add application of “content label” to MediaStreams when adding them to a
>> PeerConnection
>
> See above.
>