Re: [MMUSIC] [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00

Stefan Håkansson LK <> Mon, 13 May 2013 07:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6925221F923C; Mon, 13 May 2013 00:21:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.35
X-Spam-Status: No, score=-3.35 tagged_above=-999 required=5 tests=[HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4ybvIUaeVjnw; Mon, 13 May 2013 00:21:51 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id DB2E621F9234; Mon, 13 May 2013 00:21:50 -0700 (PDT)
X-AuditID: c1b4fb30-b7f3a6d0000007a4-61-5190948a0093
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 6D.09.01956.A8490915; Mon, 13 May 2013 09:21:46 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Mon, 13 May 2013 09:21:46 +0200
Message-ID: <>
Date: Mon, 13 May 2013 09:21:46 +0200
From: Stefan Håkansson LK <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Emil Ivov <>
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprILMWRmVeSWpSXmKPExsUyM+JvrW7XlAmBBp/n6Vms2TmBxWLq8scs Fis2HGC1WPuvnd2BxePv+w9MHkuW/GTy+P8mMIA5issmJTUnsyy1SN8ugStj4q6pzAV/lCve /T3F3MB4TqaLkZNDQsBEovfGFlYIW0ziwr31bCC2kMApRol/Jzy7GLmA7LVA9pp+RpAEr4C2 xJb7p5i6GDk4WARUJU4fFgIJswkESlz//4sJxBYViJL493Y3VLmgxMmZT1hAbBEBeYnutkVg NcwC5RKnL30Hs4UFvCW2bVjIDLH3O7NE9+EUEJsTaOb0m8+g6m0lLsy5zgJhy0s0b50NVa8r 8e71PdYJjIKzkKybhaRlFpKWBYzMqxjZcxMzc9LLzTcxAoP14JbfBjsYN90XO8QozcGiJM6b zNUYKCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoFR+tp1373dbxw8AtyyHMu/Tzs2s6x1bnRr bZ3Q3xvrShSUdC4k19wLL1zkLLk39VB82pmjvnN/b/189omtTtyM8vkTFgR9LjjJO4vRKXHd m4Z/L7ntBVPtTA8ese9Vejtp+oHlxsc3aHs+l7pgs2jdSf3bO6ZPc3e+lpwesVltXdlaG7WE fhdhJZbijERDLeai4kQAFV5HUiQCAAA=
Cc: "" <>, "" <>, Paul Kyzivat <>
Subject: Re: [MMUSIC] [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 13 May 2013 07:21:56 -0000

On 2013-05-12 20:28, Emil Ivov wrote:
> On Sun, May 12, 2013 at 8:18 PM, Stefan Håkansson LK
> <> wrote:
>> On 5/11/13 6:24 PM, Paul Kyzivat wrote:
>>> On 5/11/13 7:50 AM, Stefan Håkansson LK wrote:
>>>> On 5/10/13 11:20 PM, Paul Kyzivat wrote:
>>>>> What is the probability that the other side, for independent reasons,
>>>>> decides to make a change within that interval? (And it isn't really the
>>>>> whole interval - it is only the first part of it.)
>>>> Given that in multiparty services the "main" video changes quite often,
>>>> I'd not say this is extremely low. It will happen.
>>> Are you thinking that there will be an SDP change every time the speaker
>>> changes???
>>> Or do you mean changes when participants join and leave a conference?
>> I meant the former (at speaker change).
>> I guess that different designs can be chosen for media from central node
>> to end-user clients, and some of them (as Bernard pointed out) would not
>> require any signaling. Still, there might be cases where signaling is
>> needed.
> Right, however in cases where signalling is indeed needed, should it
> really be defined by RTCWEB rather than the application developer?
>> But leaving that aside, we still have the case of the media end-user
>> client -> central node. If you're serious about not wasting bandwidth
>> (and with my radio/mobile background I am sort of obsessed :-) ) all
>> end-user clients which do not end up as main video anywhere should only
>> transmit a low resolution video. So at every speaker change there would
>> be at least one client that is asked to stop sending high resolution and
>> only transmit low resolution, and one client that is asked to start
>> transmitting high resolution video.
>> I think that this would best be done using some RTCP signaling scheme,
> RTCP is just one of the possibilities. This could also be implemented
> in a number of other ways that would all be more efficient for the
> specific application and all out-of-scope for rtcweb.
>> but I also think there was an agreement a long time ago that SDP O/A
>> should be used.
> Well the way I remember it SDP O/A was chosen for session negotiation
> and that other forms of signalling were explicitly left out of the
> charter.

I took the result of the discussion and poll at the IETF-84 
( as 
an indication of that SDP O/A should be used for this kind of in-session 
changes as well.

>> In this case either to transmit a new imageattr value
> imageattr is great as a declarative parameter indicating capabilities:
> "I can't show more than 720p so there's no point to send me more than
> that". Using it as a way to switch between thumbnail and HQ videos is
> not entire impossible but is not particularly efficient either.

To me it looks like a solution that people might feel inclined towards 

But there are others that want to use simulcast, and then pause/resume 
sending of high and low resolution streams, and that problem is more or 
less the same when it comes to signaling.

And even if we omitted the possibility for a receiver to indicate to the 
sender (via standardized signaling) that it should pause or resume 
sending, and instead left that up to an API (at sender side) and 
proprietary signaling, we still have to have some kind of signaling IMO: 
the sender can not just stop sending RTP packets, there need to be a 
signal to the receiver so it understands this (and does not think there 
are extreme packet losses or some other errors) and can indicate to the 
application at the receiving end (in WebRTC it should result in a "mute" 
event being fired on the PC-track in question).

I think the current assumption is SDP O/A for that kind of signaling.

>> requesting another resolution, or to pause/resume - using recv on/off in
>> Plan B or the direction attribute in Plan A - the low and high
>> resolution simulcast streams accordingly (or I assume to pause/resume
>> the enhancement layers if a scalable codec is used).
>>> I would hope there will normally not be SDP changes for either of those
>>> events.
>> I would like to avoid them too, but I'm not sure how.
> Well we can either figure that out (and it seems that we can't quite
> agree on a solution) or make sure APIs have all it takes for the
> matter to be resolved by app-to-app signalling.
> Emil
> --