Re: [MMUSIC] [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00
Emil Ivov <emcho@jitsi.org> Sun, 12 May 2013 18:29 UTC
Return-Path: <emcho@sip-communicator.org>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B23DB21F89AF for <mmusic@ietfa.amsl.com>; Sun, 12 May 2013 11:29:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level:
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001]
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 VPiNTTvgeaXK for <mmusic@ietfa.amsl.com>; Sun, 12 May 2013 11:29:11 -0700 (PDT)
Received: from mail-da0-x232.google.com (mail-da0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id DCCD621F8916 for <mmusic@ietf.org>; Sun, 12 May 2013 11:29:11 -0700 (PDT)
Received: by mail-da0-f50.google.com with SMTP id i23so3145540dad.23 for <mmusic@ietf.org>; Sun, 12 May 2013 11:29:11 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=7gkTSk+96Pf79o0bHvtoQjoAuejxtwvY7WTKpfeK5jo=; b=kir6MBTsABysV9swgfFofbtLn9Xfih56feNq2yXwD/FmX/qDbnI22oyn+6MNA9yzeE xbB1NvGYVrjo5OvW2UoCchXYFlwlqkt2M9qDBAas9DN1OkFRd6apwOR+39WVKg5S7v10 9LGIF3IUeC/10gFsyDGUFYYQNEp9rSit34ndbzyMn/3qHA1dUJEhwu/lr88ZWPmWAJgn E+wdtR00bWQPx21yyls8Wmh0vaHKAI+T3VhpGPisT7xb3c271jUXdG1wegJpQvzriKY6 mdh7Y9WQE4JqQAJ1NrEZvJsTrYh7+ppUZm1qkRzs1fCiVW/E1+vflycXIp8aK4v/PiLn lNjQ==
X-Received: by 10.68.212.35 with SMTP id nh3mr26065043pbc.40.1368383351552; Sun, 12 May 2013 11:29:11 -0700 (PDT)
Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [2607:f8b0:400e:c01::22d]) by mx.google.com with ESMTPSA id sq9sm11686214pab.5.2013.05.12.11.29.11 for <mmusic@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 12 May 2013 11:29:11 -0700 (PDT)
Received: by mail-pb0-f45.google.com with SMTP id mc8so2001390pbc.4 for <mmusic@ietf.org>; Sun, 12 May 2013 11:29:10 -0700 (PDT)
X-Received: by 10.66.216.198 with SMTP id os6mr26211752pac.145.1368383350836; Sun, 12 May 2013 11:29:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.66.229.68 with HTTP; Sun, 12 May 2013 11:28:50 -0700 (PDT)
In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1C2CA23E@ESESSMB209.ericsson.se>
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>
From: Emil Ivov <emcho@jitsi.org>
Date: Sun, 12 May 2013 21:28:50 +0300
Message-ID: <CAPvvaaKwKBmeXYrCNr-8RAcg3ff5WGwXt77TPc4v-xFKpQWTnQ@mail.gmail.com>
To: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQkcFfbUtPgja7iWeSDAq3gw68gknbHSA777KJI2h5olbILu5C6gTcbJgXXrDzkCKsdgjNOS
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, "mmusic@ietf.org" <mmusic@ietf.org>, Paul Kyzivat <pkyzivat@alum.mit.edu>
Subject: Re: [MMUSIC] [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 12 May 2013 18:29:12 -0000
On Sun, May 12, 2013 at 8:18 PM, Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com> 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. > 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. > 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 -- https://jitsi.org
- Re: [MMUSIC] [rtcweb] Quick comments on draft-roa… Stefan Håkansson LK
- Re: [MMUSIC] [rtcweb] Quick comments on draft-roa… Paul Kyzivat
- Re: [MMUSIC] [rtcweb] Quick comments on draft-roa… Stefan Håkansson LK
- Re: [MMUSIC] [rtcweb] Quick comments on draft-roa… Paul Kyzivat
- Re: [MMUSIC] [rtcweb] Quick comments on draft-roa… Bernard Aboba
- Re: [MMUSIC] [rtcweb] Quick comments on draft-roa… Stefan Håkansson LK
- Re: [MMUSIC] [rtcweb] Quick comments on draft-roa… Emil Ivov
- Re: [MMUSIC] [rtcweb] Quick comments on draft-roa… Stefan Håkansson LK
- Re: [MMUSIC] [rtcweb] Quick comments on draft-roa… Emil Ivov
- Re: [MMUSIC] [rtcweb] Quick comments on draft-roa… Paul Kyzivat
- Re: [MMUSIC] [rtcweb] Quick comments on draft-roa… Bernard Aboba
- Re: [MMUSIC] [rtcweb] Quick comments on draft-roa… Cullen Jennings (fluffy)
- Re: [MMUSIC] [rtcweb] Quick comments on draft-roa… Bernard Aboba
- Re: [MMUSIC] [rtcweb] Quick comments on draft-roa… Bernard Aboba
- Re: [MMUSIC] [rtcweb] Quick comments on draft-roa… Stefan Håkansson LK
- Re: [MMUSIC] [rtcweb] Quick comments on draft-roa… Emil Ivov