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

Harald Alvestrand <harald@alvestrand.no> Wed, 22 May 2013 11:55 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A041A21F9346 for <rtcweb@ietfa.amsl.com>; Wed, 22 May 2013 04:55:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSIygDK5O+rl for <rtcweb@ietfa.amsl.com>; Wed, 22 May 2013 04:55:44 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 280D321F9223 for <rtcweb@ietf.org>; Wed, 22 May 2013 04:55:44 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D46BC39E140 for <rtcweb@ietf.org>; Wed, 22 May 2013 13:55:42 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IPuXU3lfRh0C for <rtcweb@ietf.org>; Wed, 22 May 2013 13:55:41 +0200 (CEST)
Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 975AC39E031 for <rtcweb@ietf.org>; Wed, 22 May 2013 13:55:41 +0200 (CEST)
Message-ID: <519CB23C.2050405@alvestrand.no>
Date: Wed, 22 May 2013 13:55:40 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <CA+9kkMDWy_Koq0Aun5A330O7OOMt9vimWPNe_uznAQdr0TSfow@mail.gmail.com> <51897B11.60004@nostrum.com> <518AB095.7010401@alum.mit.edu> <518AC143.2010006@nostrum.com> <1447FA0C20ED5147A1AA0EF02890A64B1C2C70B9@ESESSMB209.ericsson.se> <518D6482.2010008@alum.mit.edu> <1447FA0C20ED5147A1AA0EF02890A64B1C2C807D@ESESSMB209.ericsson.se> <518E70A9.7070007@alum.mit.edu> <1447FA0C20ED5147A1AA0EF02890A64B1C2CA23E@ESESSMB209.ericsson.se> <BLU405-EAS28962C7752B95767B7B2BED93A00@phx.gbl> <5191F4B8.2020602@ericsson.com> <5192011A.8030903@jitsi.org>
In-Reply-To: <5192011A.8030903@jitsi.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] [MMUSIC] Quick comments on draft-roach-rtcweb-glareless-add-00
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 May 2013 11:55:50 -0000

On 05/14/2013 11:17 AM, Emil Ivov wrote:
>
> On 14.05.13, 11:24, Stefan Håkansson LK wrote:
>> On 2013-05-13 19:58, Bernard Aboba wrote:
>>>
>>> On May 12, 2013, at 10:18, "Stefan Håkansson LK"
>>> <stefan.lk.hakansson@ericsson.com> wrote:
>>>
>>>>> 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.
>>> [BA] It is probably not possible to avoid them in all cases, but we
>>> can define RTCP functionality which along with some set of
>>> functionality (e.g. Simulcast, layered coding) will minimize them.
>>> This is worth doing (and soon).
>> I agree to this!
> RTCP `certainly sounds a lot better than SDP O/A
>
> Emil
>
If something's doable doing app-level signalling, it can be deployed at 
the speed of app updates - but each app has to do it on its own.

If something's doable using RTCP, it can be deployed at the speed of 
browser updates - but you have to convince the browser people to do it 
first.

SDP O/A extensions are in an uncomfortable place between these extremes, 
I think. But it's not obvious to me that one of the three always "sounds 
better" than the other ones.