W3C home > Mailing lists > Public > public-webrtc@w3.org > December 2013

Re: Material (again!) for scoping discussion

From: Harald Alvestrand <harald@alvestrand.no>
Date: Wed, 25 Dec 2013 22:12:00 +0100
Message-ID: <52BB4A20.9050802@alvestrand.no>
To: public-webrtc@w3.org
On 12/25/2013 03:09 PM, Eric Rescorla wrote:
> On Wed, Dec 25, 2013 at 8:46 AM, Stefan Håkansson LK
> <stefan.lk.hakansson@ericsson.com> wrote:
>> On 19/12/13 17:01, Eric Rescorla wrote:
>>> On Thu, Dec 19, 2013 at 6:10 AM, Stefan Håkansson LK
>>> <stefan.lk.hakansson@ericsson.com> wrote:
>>>> Hi all,
>>>> we've now gone through the list of items that could be in/out of 1.0 of
>>>> WebRTC, and developed our opinion.
>>>> Clue for reading (most should be obvious): when there is a strange name
>>>> in the "Can be own spec?" column we propose creating a separate document
>>>> (with that working name).
>>>> Sorry for the very short notice, we'll talk more about this at the
>>>> telechat in a little less than five hours.
>>> I've gone through this list and it makes me pretty sad; this seems
>>> like a recipe for a system which is primarily useful for demos, but
>>> not suitable for building the range of applications that people really
>>> expect.
>>> As a worked example of this, let's start by considering track
>>> rejection and hold. If I am on a low bandwidth link and someone offers
>>> me video, I need to be able to reject it; it's not enough to just not
>>> display the video, since it's still chewing up bandwidth.  So, this
>>> seems like a fairly critical feature for a minimally functional
>>> system, and yet the chair's proposal is to defer past 1.0. How
>>> can this work?
>> In recent time I think there has been one proposal dealing with
>> rejection [1]. There was one comment on rejection [2] (incidentally
>> given by me) basically saying "your proposal looks good, but not sure we
>> need this now".
>> So based on recent discussion this does not seem like something a lot of
>> people want. And, I guess there are always the options of signaling
>> (outside the SDP) to the sender to switch off video, or munging the SDP.
> I don't think you can draw this inference.
> However, the suggestions you make above for how to address this
> are precisely why I suggested it as a test case for discussing the principles
> to use for how to make these decisions (which seems to me to be a
> lot more useful than trying to discuss each issue one at a time). I don't
> consider it acceptable to have basic functionality like this to either
> require SDP munging or out-of-band signaling.
I thought we had a good and constructive discussion of this exact topic 
in the Shenzhen/Seattle meeting, where one of the main conclusions was 
that the word "hold" means different things to different people, so we 
shouldn't use it; rather, we should use "stop/resume sending a track", 
and consider how "stop/resume sending a track" should be initiated.

My impression was that the conclusion was also that the architecturally 
correct place for this functionality was in the 
SenderControl/ReceiverControl objects ("doohickeys"), so I've been 
assuming that I'd understand the proposal of the people who proposed 
these (including Cullen) when the proposal was baked.

I could be wrong.
Received on Wednesday, 25 December 2013 21:12:04 UTC

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