IETF Logo Mail Archive

Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls?

Iñaki Baz Castillo <ibc@aliax.net> Mon, 05 November 2018 17:24 UTC

Return-Path: <ibc@aliax.net>
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 3A9A7130E5B for <rtcweb@ietfa.amsl.com>; Mon, 5 Nov 2018 09:24:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sF-cxSvURGs4 for <rtcweb@ietfa.amsl.com>; Mon, 5 Nov 2018 09:24:04 -0800 (PST)
Received: from mail-vk1-xa41.google.com (mail-vk1-xa41.google.com [IPv6:2607:f8b0:4864:20::a41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BB81130E00 for <rtcweb@ietf.org>; Mon, 5 Nov 2018 09:24:04 -0800 (PST)
Received: by mail-vk1-xa41.google.com with SMTP id u62so2203181vkb.3 for <rtcweb@ietf.org>; Mon, 05 Nov 2018 09:24:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=+WVXoN7+NLA/EHLSUUFquJbKKkKJa+nGnfG27yHP5hk=; b=zQMWr7MwVN1mvVCggr2P0WrOUIVHRk7rf3FVyBSNzBAVzH7BY7GVBt4g4KA18Gyxkb 0IVQt7LJuuw6rX0hCM7ecu92vzMkxk4n8xD2zF4Sbo3tzgYclnmMqgxOWys7lMKDGKNC u7DRXpxp0V7pk9BER1tTYEXgmafTdKni+uaC2tRCvAxay0A77URNgj8jmcLazpyqc0B4 vzLEHE30Bx6Sf6DnaL3M9VcO3/jjcnbIA9G4CHR+ujDySBVL03uVelH3wJGOGHDXAUAT tcrlzPsghO11gXK31yXnHccI/WSnHvRk4pNetzvGrZgi6DUYBI6iSd66YBOMWss151EB kASw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=+WVXoN7+NLA/EHLSUUFquJbKKkKJa+nGnfG27yHP5hk=; b=DzMK6dg7Kt3J7OqUHgIZzNCPMeWSAebIay9L8pfbgFauKAvQnuXlyuJHSKIcWhhiZD pkT/4P4xFlaxDw3OUE3qbxkZoo7MWxAHPrI58oBh0NUiFYRomj83h40scNL25yzVY3VA 2FSFiYZPjZA+xBNxzboQMJlQscqwLs7aypQACKDcqGPMW8JKJRcb81o2yahxIBDfhNy7 qU2E/6Tr2YxgzJ3VtN2kB00kMk+GWw4lSUu5MqqFa3Q5lJbdC9c6+JY5l31kW3kIjcoH OpeHqf9SNwElqoj/FOdc10bQNgAdf+hn35KQjl+MbAD8nm9ZiAMLmX10VnpFnryifGmy Fnpg==
X-Gm-Message-State: AGRZ1gImveb+hfZPIPmS/89dTcvFoNs3A1mgNaorSG4YIFkJQm3+hCDS oCIJEijgGcmCd4KH4VrNsMlLW3GSPFpIKqMqYyefCI2b
X-Google-Smtp-Source: AJdET5flxhlBQHrCBrlsbrmPvK4BHOpHTbL5bM9jl27VvFe47rng/fcmbLbcyqYZqSPjiRsOxopIWfCg8Vn5UZuL6zU=
X-Received: by 2002:a1f:accf:: with SMTP id v198-v6mr10047785vke.3.1541438642948; Mon, 05 Nov 2018 09:24:02 -0800 (PST)
MIME-Version: 1.0
References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> <CALiegfmbghnBtDt=wfCAbOWi5SDFTi2qPgDOuXHRazKSvvCKNQ@mail.gmail.com> <CA+ag07YD3oSuL=R=h-28waha4b7xf7haU+-oWuNbzO_sBY4MQw@mail.gmail.com> <e567832e-1918-d51c-6f00-a732547c0a8e@alvestrand.no> <CA+ag07byo1vReeo2uMKxmF1tnzW+4CJSMPLaJO79H0s9j0PO0g@mail.gmail.com> <31fb92c1-2934-c33f-a3cf-552f027eacda@alvestrand.no> <bb7f863b-510c-f460-c9b0-843d500784b8@gmail.com> <5db76ada-b896-7eba-b42e-85b2e239dc42@alvestrand.no> <db90e287-145b-5ffe-18c0-f38faed76c07@gmail.com> <CALiegf=7yJJEbGT9SrbcEBBo9cnBbPimDP_oaTzJL63hrnXGoQ@mail.gmail.com> <CA+ag07ZuGYBhr=djPP=nLXLX96Yp2O4H8rJT2z8RVvNTiky2qw@mail.gmail.com> <CALiegfmOsLgeO-jkj20qKa0=w-xwHJdKD12Py_Dvades8Jjnrw@mail.gmail.com> <fe3e1b27-ba9f-4403-6835-8e7faebb4362@gmail.com> <CALiegf=o6z-HpU+Dr=KbJJss6pYenEnKo620gEyvkJ6PubvWRA@mail.gmail.com>
In-Reply-To: <CALiegf=o6z-HpU+Dr=KbJJss6pYenEnKo620gEyvkJ6PubvWRA@mail.gmail.com>
From: Iñaki Baz Castillo <ibc@aliax.net>
Date: Mon, 05 Nov 2018 18:23:50 +0100
Message-ID: <CALiegfkWHRqjaW6F4_5nVUAy2cJ+fGAHp68DgWoNGorNr6=stQ@mail.gmail.com>
To: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
Cc: Harald Alvestrand <harald@alvestrand.no>, rtcweb@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/J_aVFTDIgdvyItzPCRij7w4p0EQ>
Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Mon, 05 Nov 2018 17:24:13 -0000

Please, forget my comment about transceiver.receiver.getParameters(),
they are just wrong here.
On Mon, 5 Nov 2018 at 15:33, Iñaki Baz Castillo <ibc@aliax.net> wrote:
>
> On Mon, 5 Nov 2018 at 15:21, Sergio Garcia Murillo
> <sergio.garcia.murillo@gmail.com> wrote:
> >
> > By the way, according to the simulcast draft that should not be a problem at all:
> >
> >    An answerer that receives an offer with simulcast that lists a number
> >    of simulcast streams, MAY reduce the number of simulcast streams in
> >    the answer, but MUST NOT add simulcast streams.
>
> Not sure if that also covers "recv" simulcast items in the offer.
> Probably yes, so ok.
>
> However still useless IMHO. Imagine an SFU that wants to receive, at
> least those bitrates (because somehow it knows that all devices can
> handle at least 3 simulcast streams):
>
> - 150kbps
> - 400kbps
> - 1000kbps
>
> Imagine there are also some devices supporting up to 5 streams, so the
> SFU produces this simulcast settings in the offer for receiving:
>
> - 150kbps
> - 120kbps
> - 400kbps
> - 750kbps
> - 1000kbps
>
> If a device that just supports 3 simulcast streams receives such an
> offer, it would discard 2. Which ones? ok, the SDP can include info
> about the desired max-bitrate per rid, and we may think: oh, we can
> get the list of rids and bitrates  after pc.setRemoteDescription() by
> calling pc.getTransceivers()[1].receiver.getParameters().encodings, so
> the app can decide which ones to enable.
>
> But that's not true since receiver.getParameters() should not contain
> more rids than those supported by the device. Well, this constraint is
> really about sender.getParameters(). So you may say: ok we somehow
> read the maximum simulcast streams that our browser/device can send
> and then choose the appropriate ones from the receiver can call
> transceiver.sender.setParameters() with them.. Error! there is no API
> for knowing the max number of simulcast streams the browser can
> produce.
>
> Too many assumptions and non existing features in this text to make
> this scenario really possible.
>
> --
> Iñaki Baz Castillo
> <ibc@aliax.net>



-- 
Iñaki Baz Castillo
<ibc@aliax.net>

v2.23.0 | Report a Bug | By Email