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

Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> Mon, 05 November 2018 12:22 UTC

Return-Path: <sergio.garcia.murillo@gmail.com>
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 93ADD1298C5 for <rtcweb@ietfa.amsl.com>; Mon, 5 Nov 2018 04:22:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=gmail.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 aqBNjFQm-7bu for <rtcweb@ietfa.amsl.com>; Mon, 5 Nov 2018 04:22:12 -0800 (PST)
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 901CF127133 for <rtcweb@ietf.org>; Mon, 5 Nov 2018 04:22:11 -0800 (PST)
Received: by mail-wm1-x32b.google.com with SMTP id f1-v6so6249250wmg.1 for <rtcweb@ietf.org>; Mon, 05 Nov 2018 04:22:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=z6tox9Dx8MxVwVfcdcEkUoivlUcsQtvANQwBtheUyUY=; b=OEnOhAKnISzy2+Z8bnd281XpyiWAX43EukvBXD/oqeZuRvGW3k6ToVGIWwrcSeprgj F7+SoXby3PJg+9pCHgRvYS9PqerD14G6gyLhdDe5L5aScSU6Y2gWhS0TWCw+mENiZZJY F5diAm2G5//b8D4xv0vde4b9frcJmD51ak3Y9EbNOYCLB1WFChhwv2RVQRTe9Dd5DNZh B3ol9Y5MFMjkLjreo7jfstysEkRRlrsLx8ZxT5wNBa/jwYD/JpUz6TnT41mn0ftKQnOb G3yQfiGxSvEs1Y4MEkMaRYK36S7vYx3ZlIt5SJYHKdPBdHHY4adHlxkYLBg4vUydeE/U 0xfw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=z6tox9Dx8MxVwVfcdcEkUoivlUcsQtvANQwBtheUyUY=; b=fxOKjltKxiAXPy1ah8SyQvyMx2d/zZXMnLUejQgpDFjgNNWv/5xvx8GpWsh9DjHye+ 14qN7V785hGny1pE210OaN0IpN7ivBMIaEPYgmVWQq4wbyv1UA4y+XJy0GRHa7dXimiA 7enTTtZXGdrprKpvVHTTM4zlKkVmy4RzHoy5Iod1GjmdUkKbMVhNC2SdUAXy+phyQZ05 24S0n/htKTgsTS27/2blel8CueXDfsGZ7bZDXHTPZ5c8xDqrb+YDkkh5hOVu/e9e3EvC 88CYy5gm/3ljN4gxZgEYfYkn7j/21/t+zDB+w/0u7hlpv9IbyM2K/JaCLbJ6gI+tp9RA DQsw==
X-Gm-Message-State: AGRZ1gLynXNJbdduNhQgMJ67Op/932lzFbRvscfbvo7jMXmMOYK8vol3 tXmAqTW0OUR53t7/b4Ic1wNmGee5
X-Google-Smtp-Source: AJdET5epr0nB0akerHwhqhM8JwwV4ks8UvAAvE6ZSnvmg9Es4dFE0VxYRHM2HNEtfJsk2VCZoNsDzQ==
X-Received: by 2002:a1c:60c2:: with SMTP id u185-v6mr5908675wmb.80.1541420529896; Mon, 05 Nov 2018 04:22:09 -0800 (PST)
Received: from [192.168.0.111] (37.red-80-28-109.staticip.rima-tde.net. [80.28.109.37]) by smtp.googlemail.com with ESMTPSA id t14-v6sm33591468wra.63.2018.11.05.04.22.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Nov 2018 04:22:09 -0800 (PST)
To: Iñaki Baz Castillo <ibc@aliax.net>, Harald Alvestrand <harald@alvestrand.no>
Cc: rtcweb@ietf.org
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> <CALiegfmdxHVqndRYRP-gmTGKFweTdpPPGVOFBCPM7CpvLvVeYw@mail.gmail.com>
From: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
Message-ID: <7b85f46f-782b-de88-3598-70d9613f9981@gmail.com>
Date: Mon, 05 Nov 2018 13:25:30 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <CALiegfmdxHVqndRYRP-gmTGKFweTdpPPGVOFBCPM7CpvLvVeYw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/dzBCBawsNFCwDcmv-vspoUaB5FU>
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 12:22:14 -0000

On 05/11/2018 13:11, Iñaki Baz Castillo wrote:
> On Mon, 5 Nov 2018 at 12:45, Harald Alvestrand <harald@alvestrand.no> wrote:
>> On 11/05/2018 10:03 AM, Sergio Garcia Murillo wrote:
>>> I am not talking about replacing a transceiver but adding a new one
>>> and renegotiate. The initial O/A will drop the simulcast attribute on
>>> the answer and create a recvonly transceiver, and then create a new
>>> transceiver with simulcast encoding that will require a O/A.
>> OK, so we have the same picture in mind of what will happen in your
>> proposal. We end up with an useless transceiver and a new transceiver
>> that is suggested by the browser end, in a new media section; it's
>> impossible to use the media section that the (initiating) server proposed.
>>
>> That seems ugly.
> So:
>
> - receive a remote offer with a single m=video section requesting
> local simulcast
> - reply with a=recvonly (fxxx you, conference server)
> - reoffer with a new m=video with "correlated" simulcast settings
> - have the conference server like that
>
> And... all this party instead of just telling the client (via custom
> messaging before it "joins" the conference) the desired simulcast
> settings? :)
>
Not sure if you are responding to  Harald or to me.  If it is to me, my 
"do nothing" proposal to enable simulcast when the offer is sent by the 
SFU (just in case anyone wants to do it):

-SFU sends an offer with all the available streams/tracks (no simulcast 
m-line)
-Browser reply with recvonly on all m-lines
-Browsers reoffer with an additional m-line (sendonly?) with simulcast
-SFU answers

No change to the spec at the cost of an additional round trip. Note that 
this is almost the same case than if the browser sends and initial offer 
with simulcast, sfu answers with recvonly, and then re-offers with all 
the available streams/track.

Also, note that many of SFU devs (at minimum Iñaki and me)  are not even 
sending SDP on the wire but doing renegotiations locally.

Best regards
Sergio