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

Emil Ivov <> Sun, 12 May 2013 18:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B23DB21F89AF for <>; Sun, 12 May 2013 11:29:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.678
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VPiNTTvgeaXK for <>; Sun, 12 May 2013 11:29:11 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c00::232]) by (Postfix) with ESMTP id DCCD621F8916 for <>; Sun, 12 May 2013 11:29:11 -0700 (PDT)
Received: by with SMTP id i23so3145540dad.23 for <>; Sun, 12 May 2013 11:29:11 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 with SMTP id nh3mr26065043pbc.40.1368383351552; Sun, 12 May 2013 11:29:11 -0700 (PDT)
Received: from ( [2607:f8b0:400e:c01::22d]) by with ESMTPSA id sq9sm11686214pab.5.2013. for <> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 12 May 2013 11:29:11 -0700 (PDT)
Received: by with SMTP id mc8so2001390pbc.4 for <>; Sun, 12 May 2013 11:29:10 -0700 (PDT)
X-Received: by with SMTP id os6mr26211752pac.145.1368383350836; Sun, 12 May 2013 11:29:10 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sun, 12 May 2013 11:28:50 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
From: Emil Ivov <>
Date: Sun, 12 May 2013 21:28:50 +0300
Message-ID: <>
To: Stefan Håkansson LK <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQkcFfbUtPgja7iWeSDAq3gw68gknbHSA777KJI2h5olbILu5C6gTcbJgXXrDzkCKsdgjNOS
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: Sun, 12 May 2013 18:29:12 -0000

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

> 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.