Re: [rtcweb] JSEP-bis and WebRTC-Extensions Section 5.2
Harald Alvestrand <harald@alvestrand.no> Thu, 18 May 2023 07:29 UTC
Return-Path: <harald@alvestrand.no>
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 B177BC13AE26 for <rtcweb@ietfa.amsl.com>; Thu, 18 May 2023 00:29:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.103
X-Spam-Level:
X-Spam-Status: No, score=-1.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, RDNS_NONE=0.793, 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
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 kv_8MI1WE3Nu for <rtcweb@ietfa.amsl.com>; Thu, 18 May 2023 00:29:42 -0700 (PDT)
Received: from smtp.alvestrand.no (unknown [IPv6:2a01:4f9:c010:a44b::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 C9B5FC15109D for <rtcweb@ietf.org>; Thu, 18 May 2023 00:29:19 -0700 (PDT)
Received: from [192.168.3.110] (unknown [185.71.208.122]) by smtp.alvestrand.no (Postfix) with ESMTPSA id 6FCA148468 for <rtcweb@ietf.org>; Thu, 18 May 2023 09:29:17 +0200 (CEST)
Message-ID: <435213e9-868b-55a1-ad00-63203ece2564@alvestrand.no>
Date: Thu, 18 May 2023 09:29:17 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0
Content-Language: en-US
To: rtcweb@ietf.org
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>
From: Harald Alvestrand <harald@alvestrand.no>
In-Reply-To: <HE1PR07MB4441A8F3E41CBA130ED2B7EE93779@HE1PR07MB4441.eurprd07.prod.outlook.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/KvVDMPbKS5dUSra_Bs1OPjzVsv0>
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: Thu, 18 May 2023 07:29:46 -0000
On 5/10/23 10:37, Christer Holmberg wrote: > Hi, > > Also note the following sentence in Section 4.1.8.: > > “An optionsparameter may be supplied to provide additional control over > thegenerated offer.” > > Doesn’t this cover the issue? > > Another question: when I call createOffer, how does the browser/library > determine what has been “enabled”, compared to what is “supported”? I think that determination is clearly in implementation-land; ie it should be descrbied in webrtc-pc for the JS interface in browsers, and in relevant documentation for webrtc implementations on other platforms. > > 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 > <mailto: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 > <mailto:rtcweb-bounces@ietf.org>> on behalf of Tim Panton > <thp@westhawk.co.uk <mailto:thp@westhawk.co.uk>> > *Sent:* Sunday, May 7, 2023 1:16:27 PM > > *To:*Christer Holmberg > <christer.holmberg=40ericsson.com@dmarc.ietf.org > <mailto:40ericsson.com@dmarc.ietf.org>> > > *Cc:*rtcweb@ietf.org <mailto:rtcweb@ietf.org> <rtcweb@ietf.org > <mailto: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 > <mailto: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 > <mailto:rtcweb-bounces@ietf.org>> on behalf of Justin Uberti > <justin@fixie.ai <mailto:justin@fixie.ai>> > *Sent:* Saturday, May 6, 2023 3:30:33 AM > *To:* rtcweb@ietf.org <mailto:rtcweb@ietf.org> > <rtcweb@ietf.org <mailto:rtcweb@ietf.org>>; > superuser@gmail.com <mailto:superuser@gmail.com> > <superuser@gmail.com <mailto: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 <mailto:rtcweb@ietf.org> > https://www.ietf.org/mailman/listinfo/rtcweb > <https://www.ietf.org/mailman/listinfo/rtcweb> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org <mailto:rtcweb@ietf.org> > https://www.ietf.org/mailman/listinfo/rtcweb > <https://www.ietf.org/mailman/listinfo/rtcweb> > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb
- [rtcweb] JSEP-bis and WebRTC-Extensions Section 5… Justin Uberti
- Re: [rtcweb] JSEP-bis and WebRTC-Extensions Secti… Justin Uberti
- Re: [rtcweb] JSEP-bis and WebRTC-Extensions Secti… Christer Holmberg
- Re: [rtcweb] JSEP-bis and WebRTC-Extensions Secti… Tim Panton
- Re: [rtcweb] JSEP-bis and WebRTC-Extensions Secti… Christer Holmberg
- Re: [rtcweb] JSEP-bis and WebRTC-Extensions Secti… Tim Panton
- Re: [rtcweb] JSEP-bis and WebRTC-Extensions Secti… Christer Holmberg
- Re: [rtcweb] JSEP-bis and WebRTC-Extensions Secti… Justin Uberti
- Re: [rtcweb] JSEP-bis and WebRTC-Extensions Secti… Roman Shpount
- Re: [rtcweb] JSEP-bis and WebRTC-Extensions Secti… Christer Holmberg
- Re: [rtcweb] JSEP-bis and WebRTC-Extensions Secti… Roman Shpount
- Re: [rtcweb] JSEP-bis and WebRTC-Extensions Secti… Christer Holmberg
- Re: [rtcweb] JSEP-bis and WebRTC-Extensions Secti… Christer Holmberg
- Re: [rtcweb] JSEP-bis and WebRTC-Extensions Secti… Christer Holmberg
- Re: [rtcweb] JSEP-bis and WebRTC-Extensions Secti… Harald Alvestrand
- Re: [rtcweb] JSEP-bis and WebRTC-Extensions Secti… Justin Uberti
- Re: [rtcweb] JSEP-bis and WebRTC-Extensions Secti… Sean Turner
- Re: [rtcweb] JSEP-bis and WebRTC-Extensions Secti… Justin Uberti