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

Bernard Aboba <bernard.aboba@gmail.com> Mon, 05 November 2018 22:16 UTC

Return-Path: <bernard.aboba@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 82D771286D9 for <rtcweb@ietfa.amsl.com>; Mon, 5 Nov 2018 14:16:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 z78mEmTkNUUr for <rtcweb@ietfa.amsl.com>; Mon, 5 Nov 2018 14:16:41 -0800 (PST)
Received: from mail-vk1-xa35.google.com (mail-vk1-xa35.google.com [IPv6:2607:f8b0:4864:20::a35]) (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 347E2124D68 for <rtcweb@ietf.org>; Mon, 5 Nov 2018 14:16:41 -0800 (PST)
Received: by mail-vk1-xa35.google.com with SMTP id o10-v6so2406491vki.6 for <rtcweb@ietf.org>; Mon, 05 Nov 2018 14:16:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DNc9U4JA8OETlUK+MbkXDqPqvkH4EVUkwIuSMPgMdjA=; b=ZZsK4EL0oDy+qmu48G70TMcUGUfpB9RZ6zM8dx/eojDOAmQWsqj4u7xGg/tVFvkPv6 StgoslSlKJb47dRLnfyzLFea55d+3S4BPeSI0NHmIhQSaralKoc2MhbKGdZ00RQl+fVZ Xw1t9Ne2aIxhHbOTH2meMIyDW8SpbWrO97SqEqRLb/LGBGkDo2t3C5eSMsS54Mob+6xJ GIiVjWDkErSRytQLI5ZkSYAr28gI4mCtLiqLOAX09MLLBjAkiKima8oyywPBtZTHUKNs e5wbFBtFB8dBp0QgmhGGKxf0Th6/K+cat2YQIfIYfN4nu9rcV1qfvMxavHydydBMbFuz NxAw==
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; bh=DNc9U4JA8OETlUK+MbkXDqPqvkH4EVUkwIuSMPgMdjA=; b=o2eTw2S9Ny6X/QENabJ5yzQ1VK0rAUCzA3FOvS7nCa+hAAIuKuwLbuLwBSUu7j/hE6 bi8gfWnX8fo3Tl5BYnbBMiC5ratHbRHDE2Rz0CajHXOix5Ula23TlH4v+Z5UZ9ioGpql ZdgHRUfiJyYBdfXh/LPvjxl7Otdx5Wjg9S3TdttFPr+PykcI0LWqBPXUfuLa91NzYB7n RIIltmZ4bLIb0Xtrj2w0+k7AWSVqiMDR9T1RjVcX42MwsHpcCvGjH7oxM5Z0PV0wsp6f G6S4SWVZzQGh0ggmp1c/iq7MRAoV4+Pbdlt6pkGaFrolaPR2R9wQ/yTRq1iPRPdlrnEU sTJg==
X-Gm-Message-State: AGRZ1gI3y49CIjey2QpeDT9c0jKn1XDuXEtol7rHS5sQ2aOWfuj10BLS rmNWwt2u+Su06Yhxlc4bn5v4pv9iFVaMP6wg1oA=
X-Google-Smtp-Source: AJdET5fwqmdn/Sm7XxEA/1NLMukM2EsxPiexLcxm9zSTrVEhiRlYamV9TARtA6X3/qMf01nVZey1RcyEpCF9goYAPMY=
X-Received: by 2002:a1f:5a01:: with SMTP id o1mr5216926vkb.4.1541456199887; Mon, 05 Nov 2018 14:16:39 -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> <150c76b7-64eb-2e75-c9e0-2f503e705e4b@alvestrand.no>
In-Reply-To: <150c76b7-64eb-2e75-c9e0-2f503e705e4b@alvestrand.no>
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Mon, 05 Nov 2018 17:16:26 -0500
Message-ID: <CAOW+2duSN5u7u+JrSpvE509k47j7Uuu4=gKy5eMFeAnw5p=kiA@mail.gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Cc: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>, RTCWeb IETF <rtcweb@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003b32240579f23d0d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/nknfwFDnV4RVemtG3JxZDh5fVHk>
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 22:16:43 -0000

Harald said:

"Note that our current spec text says that when addTrack is called, a
transceiver is created with the max number of simulcast encodings set to
1, and that this number cannot be increased. This would have to change."

[BA] Most of the code examples I have seen that use addTrack for simulcast
call setParameters prior to createOffer().  To allow this, we might
consider saying that when addTrack returns, the encodings are initially
null, and so can be set by setParameters().

On Mon, Nov 5, 2018 at 4:30 PM Harald Alvestrand <harald@alvestrand.no>
wrote:

> On 11/05/2018 02:07 PM, Sergio Garcia Murillo wrote:
> > On 05/11/2018 12:45, Harald Alvestrand wrote:
> >> I do fear that simulcast will continue to affect parts of the spec that
> >> we don't expect it to. But we don't have the luxury of specifying it
> >> halfway; either we rip it out altogether, or we specify it in enough
> >> detail for interoperable implementation.
> >
> > I agree to that. If we are able to find an "easy" (i.e. not
> > introducing too many changes) I would not have any issues adding
> > support to that.
> >
> > Something like:
> >
> > - Browser adds a track via addTrack
> >
> > - Browser call SRD with a recv simulcast m-line offer
> >
> > - The transceiver is created with one send encoding per rid offered by
> > the SFU with default values and all send encodings except first one
> > with active=false (this would be the only required change)
> >
> > ----- browser encodes/sends a single rtp stream, same as if the remote
> > offer was a non simulcast stream--
> >
> > -Browser calls sender.getParameters(), modifies the desired send
> > encoding parameters ( scaleResolutionDownBy,  maxFramerate,
> > maxBitrate, etc) and enables them by setting active=true
> >
> > Would this approach fulfill the requirements?
>
> Yes, I believe so. This is also precisely what I was proposing, except
> for the requirement to call addTrack.
>
> Note that our current spec text says that when addTrack is called, a
> transceiver is created with the max number of simulcast encodings set to
> 1, and that this number cannot be increased. This would have to change.
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>