Re: [rtcweb] JSEP-bis and WebRTC-Extensions Section 5.2

Justin Uberti <justin@fixie.ai> Mon, 05 June 2023 01:41 UTC

Return-Path: <justin@fixie.ai>
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 3D812C14CE55 for <rtcweb@ietfa.amsl.com>; Sun, 4 Jun 2023 18:41:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.553
X-Spam-Level:
X-Spam-Status: No, score=-0.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fixie-ai.20221208.gappssmtp.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4rxlhXKShTFN for <rtcweb@ietfa.amsl.com>; Sun, 4 Jun 2023 18:41:43 -0700 (PDT)
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F75FC14CE31 for <rtcweb@ietf.org>; Sun, 4 Jun 2023 18:41:42 -0700 (PDT)
Received: by mail-ed1-x535.google.com with SMTP id 4fb4d7f45d1cf-51494659d49so6530863a12.3 for <rtcweb@ietf.org>; Sun, 04 Jun 2023 18:41:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fixie-ai.20221208.gappssmtp.com; s=20221208; t=1685929300; x=1688521300; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=aP7fozR6vYaagZFta4MqD9r7NW95XR0tDAb4tLMNWCQ=; b=OGlyYv8jY0m5Cd8a66eY4aaY2+gu+ooX0Fv1WguBCaRUBdRrmKnMwOiEU0ReaQsX0q ymQK1nwLBZKr7UgiM/tLclNYwBo2gHxITEk/8x5ZhtKMlfcEbzvzGEY4R65ehAbS+XF6 qcExmxR034rlObJ93BOflKfzqwDaOy0dbF9/v/hAXLek16UfRkMyhGIE89bNkBOXoVWS U7bqGuG0SAtiFvSQlQC+RiTonRaxT1lZ4MUf8bw9Ecb7OAn4Jny7Rma0qKD53rtmaHWd jbaQu85NVGLXT3IsRk7/Sj9F6oXtfvUG7CaJ5Kfputje7vAsiaGIMUe9ASaqGnrMKOCR 0+CA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685929300; x=1688521300; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=aP7fozR6vYaagZFta4MqD9r7NW95XR0tDAb4tLMNWCQ=; b=aGMeBCKR2966jB8LlxKdk4+rLQvMdHy1y//H6w4fv9KlCO/fghyt6/v2XDqnH/hw/z 9vnMlXAnJkIZF6KhsEE8qI5hIeaF3zB6qdH40CywkVKNlVT6GOOp7OJNr7E+6xz8qIQ2 X4g8tRRKES0VjRQH1cvNGZN3aflFTE+2e+2a+f3pfMGSE5y7kRs93nFQNij316bjIpnI fxBza8t68LFtpqXkewwT3r0TRLrY+MYQE2GQUk5UA616jhgu1SBHEtkUxuaVvxrLT8uu 3tMpzY6wkTymN90dPzCDZsMNzDv9KVY9R0jRFIJ7pB3BG7pXcKvcDmN95yPGXnotViYG MdSQ==
X-Gm-Message-State: AC+VfDxG4goa86RFHb2UD6qJnfHAfyJSKnCktwIeHBVD20bBqwEj3Du5 PlsBVqZq440xAx4NEDT3jMwtpoaxfBynF+aIKPNQMg==
X-Google-Smtp-Source: ACHHUZ54KbzVNkE54VdwJSBs2DHyv5jF4pSHE+nhvu7rznhI+nCn6X9fw5V1+kAGAXWxAIEqvOJnCmep0UlqXfyhltM=
X-Received: by 2002:aa7:da42:0:b0:50d:1e11:eb9 with SMTP id w2-20020aa7da42000000b0050d1e110eb9mr7197139eds.1.1685929300411; Sun, 04 Jun 2023 18:41:40 -0700 (PDT)
MIME-Version: 1.0
References: <CAPn_nMPhh0x5-_BKa0xF595Y8LXo5oRQjJqFgxFLtcCf+-FpOw@mail.gmail.com> <HE1PR07MB44416F5D6CCD8940D5974E3193709@HE1PR07MB4441.eurprd07.prod.outlook.com> <61AC7C19-2806-483F-9526-637DB5D46104@westhawk.co.uk> <HE1PR07MB444193373683D3D0E2F0735F93709@HE1PR07MB4441.eurprd07.prod.outlook.com> <8A7B8A70-7E37-4B0F-917D-C2FF62B84768@westhawk.co.uk> <HE1PR07MB4441C0C4B70C1DD980EAE23393709@HE1PR07MB4441.eurprd07.prod.outlook.com> <CAPn_nMOJXhC8Ae_QSS+ariACcXx__mXRF1pUK6UQSbFuL3m5WQ@mail.gmail.com> <HE1PR07MB444104909398325EA92E91BE93779@HE1PR07MB4441.eurprd07.prod.outlook.com> <HE1PR07MB4441A8F3E41CBA130ED2B7EE93779@HE1PR07MB4441.eurprd07.prod.outlook.com>
In-Reply-To: <HE1PR07MB4441A8F3E41CBA130ED2B7EE93779@HE1PR07MB4441.eurprd07.prod.outlook.com>
From: Justin Uberti <justin@fixie.ai>
Date: Sun, 04 Jun 2023 18:41:29 -0700
Message-ID: <CAPn_nMPg5c5tq_4Huf97LTt8-moE4nVdV=2hbt_eLrx1pWox5Q@mail.gmail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: Christer Holmberg <christer.holmberg=40ericsson.com@dmarc.ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000011591b05fd58012f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/mr60XI1VzXrYRINhIi08DXcbbi4>
Subject: Re: [rtcweb] JSEP-bis and WebRTC-Extensions Section 5.2
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.39
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 Jun 2023 01:41:47 -0000

On Wed, May 10, 2023 at 1:37 AM Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> Hi,
>
>
>
> Also note the following sentence in Section 4.1.8.:
>
>
>
> “An options parameter may be supplied to provide additional control over
> the generated offer.”
>
>
>
> Doesn’t this cover the issue?
>

I think it would be worthwhile to tweak the sentence from 4.1.8 that you
previously mentioned to indicate that the mechanisms included in the SDP
are not just those supported by the browser, but also preferred by the
application. We can wave hands about the exact mechanism for how this is
done, perhaps referring to the possibility of future APIs.

I'll rework this PR to include such text as well as the other changes
previously noted in option b).

>
>
> Another question: when I call createOffer, how does the browser/library
> determine what has been “enabled”, compared to what is “supported”?
>

>
> Regards,
>
>
>
> Christer
>
>
>
>
>
>
>
> *From:* Christer Holmberg <christer.holmberg=40ericsson.com@dmarc.ietf.org>
>
> *Sent:* Wednesday, 10 May 2023 11.01
> *To:* Justin Uberti <justin@fixie.ai>; Christer Holmberg <
> christer.holmberg@ericsson.com>
> *Cc:* rtcweb@ietf.org
> *Subject:* RE: [rtcweb] JSEP-bis and WebRTC-Extensions Section 5.2
>
>
>
> Hi,
>
>
>
> >Part of the issue here is that we did spec the setCodecPreferences
> <https://www.rfc-editor.org/rfc/rfc8829#name-setcodecpreferences> API in
> JSEP allowing the JS application to control what formats it
>
> >wants to negotiate, so in many ways this change is just bringing RTP
> extensions in line with media formats (IOW, we already have
>
> >some disparities in the spec). As to the solution here, we also have to
> deal with more than just the notion of "enabled" - there is
>
> >also the change in how RTP header extensions are added in subsequent
> offers, which would probably be harder to do in a generic
>
> >statement, as it would have to override normative text later in the
> document.
>
> >
>
> >However I do recognize Christer's concern that there could be other
> parts of JSEP that need the same treatment (specifically, FEC mechanisms
>
> >and RTCP feedback mechanisms). To address this, we could do one of the
> following:
>
> >a) Add a generic statement as Christer proposes suggesting that
> "supported", as it pertains to JSEP, means the parameters that the JSEP
>
> >implementation can handle AND are enabled by the application, and have
> this apply to all relevant parts.
>
> >b) Extend the PR below to handle all the cases where the application
> might want to override "supported" (FEC and RTCP are the only remaining
>
> >ones, I believe). We could use "supported by the application" as Tim
> mentions to make the change more editorial.
>
> >c) Just go forward with the current PR and revisit the situation in the
> future when needed
>
> >
>
> >I tend to think that b) will actually be the most surgical and
> unambiguous change, so I lean in that direction at the moment.
>
>
>
> I am ok with both a) and b).
>
>
>
> But, in Section 4.1.8 there is the following sentence:
>
>
>
>    “The createOffer method generates a blob of SDP that contains an offer
>
>    per [RFC3264] with the supported configurations for the session,
>
>    including descriptions of the media added to this PeerConnection, the
>
>    codec, RTP, and RTCP options supported by this *implementation*, and
>
>    any candidates that have been gathered by the ICE agent.”
>
>
>
> What does “implementation” refer to? The browser? If so, wouldn’t that
> sentence have to be changed too, as it now says that the SDP generated
> using createOffer will contain the RTP and RTCP options supported by the
> implementation (not the application)?
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
> On Sun, May 7, 2023 at 12:51 PM Christer Holmberg <christer.holmberg=
> 40ericsson.com@dmarc.ietf.org> wrote:
>
> Hi,
>
>
>
> >> Are there actually some real implementation issues behind the proposed
> change, or is it only
>
> >> about W3C and IETF using different terminology?
>
> >
>
> > It’s an API layer thing. At present there are no ways for a javascript
> application to manage which RTP
>
> > header extensions are present in an offer*. So the current behaviour is
> to offer _everything_ the
>
> > library/stack is capable of. The W3C is creating an API point that
> allows the javascript application to
>
> > decide which extensions (of all the ones supported by the stack) are
> useful/relevant/safe for the application.
>
> >
>
> > If both side’s webRTC implementations support a lot of RTP header
> extensions, the current wording will have
>
> > them _all_ offered and all accepted in an answer, even if none of them
> add any value to the application - bloating
>
> > the packet size needlessly.  Specifically: ’supported’ is taken to mean
> supported by the user agent - rather than
>
> > supported by the application as a whole.
>
> >
>
> > (This is my understanding of the issue at least)
>
>
>
> Wouldn't it be better to have a generic statement, saying that for some
> features there are APIs that, for some features,
>
> allow the JS application to control what options are offered. That would
> also be future proof, and we would not have
>
> to update the JSEP spec every time there is a new API that allows the JS
> application to control what options are offered
>
> for a certain feature.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
>
>
> Sent from Outlook for iOS <https://aka.ms/o0ukef>
> ------------------------------
>
> *From:* rtcweb <rtcweb-bounces@ietf.org> on behalf of Tim Panton <
> thp@westhawk.co.uk>
> *Sent:* Sunday, May 7, 2023 1:16:27 PM
>
> *To:* Christer Holmberg <christer.holmberg=40ericsson.com@dmarc.ietf.org>
>
> *Cc:* rtcweb@ietf.org <rtcweb@ietf.org>
> *Subject:* Re: [rtcweb] JSEP-bis and WebRTC-Extensions Section 5.2
>
>
>
> I was also thinking about this too - and I somewhat agree.
>
>
>
> We could replace ‘supported' with 'supported by the current application’
> since at a high level what this change does is to differentiate between
> extensions that the library (libwebrtc etc) can support vs extensions the
> current application wants to support.
>
>
>
> It also makes it clearer that this is an editorial change.
>
>
>
> T.
>
>
>
> On 7 May 2023, at 11:10, Christer Holmberg <christer.holmberg=
> 40ericsson.com@dmarc.ietf.org> wrote:
>
>
>
> Hi,
>
>
>
> I have issues with the proposed change.
>
>
>
> First, AFAIK, "enabled" is not used in any other O/A specification.
>
>
>
> Second, my reading of "supported" is that it is something that the
> endpoint is actually willing to/capable of using within the session.
>
>
>
> Third, within the JSEP O/A procedures, "supported" is used for other
> features (e.g., FEC mechanisms). Using other terminology for one feature
> will only confuse the reader, in my opinion.
>
>
>
> Fourth, if it is unclear what "supported" really means we should rather
> clarify that.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> Sent from Outlook for iOS <https://aka.ms/o0ukef>
> ------------------------------
>
> *From:* rtcweb <rtcweb-bounces@ietf.org> on behalf of Justin Uberti <
> justin@fixie.ai>
> *Sent:* Saturday, May 6, 2023 3:30:33 AM
> *To:* rtcweb@ietf.org <rtcweb@ietf.org>; superuser@gmail.com <
> superuser@gmail.com>
> *Subject:* [rtcweb] JSEP-bis and WebRTC-Extensions Section 5.2
>
>
>
> The WebRTC W3C WG is working on an extension spec
> <https://w3c.github.io/webrtc-extensions/#rtp-header-extension-control-modifications>
> that suggests behavior for RTP header extension O/A that conflicts slightly
> with the current version of JSEP. Rather than have this sort of ad-hoc
> extensions extension to JSEP in the W3C spec, it was suggested that we
> could apply a tiny patch to JSEP before JSEP-bis is finalized (it's
> currently in the RFC Editor state). Murray was supportive of this but
> wanted to make sure the WG was fully behind this change first.
>
>
>
> For context, Section 5.2 in the W3C extension spec basically says that
> WebRTC endpoints can control the extensions that are in use, and as a
> result O/A negotiation should a) use only the extensions that are enabled
> by the endpoint, and b) always reoffer all extensions, rather than the
> previously negotiated set.
>
>
>
> I've made a PR that captures this request at
> https://github.com/rtcweb-wg/jsep/pull/1033/files
> <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-45f3175ddedc0fdc&q=1&e=d500064c-f63a-47ed-b1ec-2ff879fda6f4&u=https%3A%2F%2Fgithub.com%2Frtcweb-wg%2Fjsep%2Fpull%2F1033%2Ffiles>,
> and it basically makes two surgical changes:
>
> 1) replaces the use of "supported RTP header extensions" with "enabled RTP
> header extensions"
>
> 2) changes the text around "extensions... present in the most recent
> answer" to instead say "extensions... enabled on the associated
> transceiver" (similar to how codecs are handled in JSEP).
>
>
>
> Please let me know if this sounds reasonable to you or you have concerns.
>
>
>
> Thanks,
>
> Justin
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>