W3C home > Mailing lists > Public > public-webrtc@w3.org > November 2012

Re: List of items noted during f2f

From: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
Date: Mon, 5 Nov 2012 12:31:47 +0100
Message-ID: <5097A3A3.8050901@ericsson.com>
To: Martin Thomson <martin.thomson@gmail.com>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
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 

* 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 

> 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
>> ======
> [...]
>> * 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.


>> * 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.
Received on Monday, 5 November 2012 11:32:15 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:31 UTC