From nobody Wed Jul 5 14:30:36 2023 Return-Path: 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 528ADC151525 for ; Wed, 5 Jul 2023 14:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.653 X-Spam-Level: X-Spam-Status: No, score=-5.653 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_DNSWL_HI=-5, 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=ham 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 mvN1RaLLlXde for ; Wed, 5 Jul 2023 14:30:31 -0700 (PDT) Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (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 52E56C14F736 for ; Wed, 5 Jul 2023 14:30:31 -0700 (PDT) Received: by mail-wm1-x332.google.com with SMTP id 5b1f17b1804b1-3fa94ea1caaso11193035e9.1 for ; Wed, 05 Jul 2023 14:30:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fixie-ai.20221208.gappssmtp.com; s=20221208; t=1688592629; x=1691184629; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=nRODgqVRHFl0Rzm/dCQJo3TqUz1U50pKq5tFlw5s7ZE=; b=qmOGJbNI8RPczT9U3VpkcDF0nGPil4S1YowvbftjEPi8ByHjsREfmH26Wk7XDwHQzL sXXhhDNC4EG+S7k/QJ4LNd8TVCG0VtINtRn3RVL8tBTgbUIhVI+noVfpNpkINYxc8orv U6i9u03pJkq1IUYYC3SOXnmUkejV6s6fsIIeWbGWPWjUlFCwFS8j9UtIkCnKWyjJVTWh VK6Rg83cHn9X+9gJc8p5ZMifH+Y6gKfAKz23czplpKcS1AHx/6uE+uxW2h58Q9DCCdgM KSe9dWaBsg/tcEVe6t+5V/2wl+PQPYO92bltOBWSoreT/XFkDE771ucFGwR1LFFY3zMx kJqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688592629; x=1691184629; 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=nRODgqVRHFl0Rzm/dCQJo3TqUz1U50pKq5tFlw5s7ZE=; b=Zq+cwzQNiTSPPhZdIluKJwPCUHCCIis47cnwWPrTqnKSycyyajmnCdE7XBh5/2RxEy 0uZbYaaNIzn3cROtWqScMf8LrgYkuE77HruZ1QWxVSuHI/XP9KCmOm24t2e3HfNadlbU bLXCS7EsV6efCMMDTtvjt4gsh3iFaJplu3i2jEeKPNgjIj0injdA7InLS0mIthxjENgL OLY950l0pxvvw4taeOFUvMOXiKkg4O7UtHEw69nv894SMx++pkgDDweIOoCfpX6rd9pv ZgHK298sI61lcUxRQLzMDSNz3T/aqSSSSciF9M4YHDZuIFcpnot6RlaUCBDbsLMzTHL8 6GeQ== X-Gm-Message-State: ABy/qLYtVrqnl9D2Kxf269Ds2UKE8d+X87uXN1nfPg8ls8JiEJFVMWAU x2Ot5pJfnOh2XgPcFh4z3H54z6EDDy9gwncbAaUEZQR2Ku5ZhPKt4GZQbg== X-Google-Smtp-Source: APBJJlGEdUHaGGUA32Egp0H3hRf9+V4RnXe5KpGW1Ko2K4rp3r1Zqf0f7M+jIuW+tIU06LXx1Hgs07BnUaI2uh7hgB8= X-Received: by 2002:a1c:7408:0:b0:3fb:2d92:ecf1 with SMTP id p8-20020a1c7408000000b003fb2d92ecf1mr253062wmc.7.1688592629279; Wed, 05 Jul 2023 14:30:29 -0700 (PDT) MIME-Version: 1.0 References: <61AC7C19-2806-483F-9526-637DB5D46104@westhawk.co.uk> <8A7B8A70-7E37-4B0F-917D-C2FF62B84768@westhawk.co.uk> <1FDC8668-3120-48F9-9819-E015137048BA@sn3rd.com> In-Reply-To: <1FDC8668-3120-48F9-9819-E015137048BA@sn3rd.com> From: Justin Uberti Date: Wed, 5 Jul 2023 14:30:18 -0700 Message-ID: To: Sean Turner Cc: Christer Holmberg , "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="000000000000d6c06805ffc41b87" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2023 21:30:35 -0000 --000000000000d6c06805ffc41b87 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Finally had a chance to crank this out. Based on this thread, I made the following updates: - updated 4.1.8 (createOffer) to indicate that offers reflect the application's preferences as well as the implementation's capabilities - removed text from that section that asserted that you couldn't reoffer your full capabilities in a re-offer scenario (previously discussed and agreed upon) - added RTCP and FEC mechanisms to the list of things that application might control - used Tim's language of "supported by the application" rather than "enabled" to make things simpler PTAL: https://github.com/rtcweb-wg/jsep/pull/1033/ On Mon, Jun 5, 2023 at 8:34=E2=80=AFAM Sean Turner wrote: > Thanks Justin! > > spt > > > On Jun 4, 2023, at 21:41, Justin Uberti 40fixie.ai@dmarc.ietf.org> wrote: > > > > > > > > On Wed, May 10, 2023 at 1:37=E2=80=AFAM Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > Hi, > > > > > > > > Also note the following sentence in Section 4.1.8.: > > > > > > > > =E2=80=9CAn options parameter may be supplied to provide additional con= trol over > the generated offer.=E2=80=9D > > > > > > > > Doesn=E2=80=99t this cover the issue? > > > > > > I think it would be worthwhile to tweak the sentence from 4.1.8 that yo= u > 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 =E2=80=9Cenabled=E2=80=9D, compared to what is = =E2=80=9Csupported=E2=80=9D? > > > > > > > > Regards, > > > > > > > > Christer > > > > > > > > > > > > > > > > From: Christer Holmberg > > > Sent: Wednesday, 10 May 2023 11.01 > > To: Justin Uberti ; 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 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 t= o > 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 th= e > 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: > > > > > > > > =E2=80=9CThe createOffer method generates a blob of SDP that contain= s an offer > > > > per [RFC3264] with the supported configurations for the session, > > > > including descriptions of the media added to this PeerConnection, th= e > > > > codec, RTP, and RTCP options supported by this implementation, and > > > > any candidates that have been gathered by the ICE agent.=E2=80=9D > > > > > > > > What does =E2=80=9Cimplementation=E2=80=9D refer to? The browser? If so= , wouldn=E2=80=99t 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=E2=80=AFPM 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=E2=80=99s an API layer thing. At present there are no ways for a j= avascript > 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=E2=80=99s webRTC implementations support a lot of RTP he= ader > extensions, the current wording will have > > > > > them _all_ offered and all accepted in an answer, even if none of the= m > add any value to the application - bloating > > > > > the packet size needlessly. Specifically: =E2=80=99supported=E2=80= =99 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 woul= d > also be future proof, and we would not have > > > > to update the JSEP spec every time there is a new API that allows the J= S > application to control what options are offered > > > > for a certain feature. > > > > > > > > Regards, > > > > > > > > Christer > > > > > > > > > > > > > > > > Sent from Outlook for iOS > > > > From: rtcweb on behalf of Tim Panton < > thp@westhawk.co.uk> > > Sent: Sunday, May 7, 2023 1:16:27 PM > > > > To: Christer Holmberg > > > > Cc: 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 =E2=80=98supported' with 'supported by the current app= lication=E2=80=99 > 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 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 > > > > From: rtcweb on behalf of Justin Uberti < > justin@fixie.ai> > > Sent: Saturday, May 6, 2023 3:30:33 AM > > To: 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 that suggests behavio= r > for RTP header extension O/A that conflicts slightly with the current > version of JSEP. Rather than have this sort of ad-hoc extensions extensio= n > to JSEP in the W3C spec, it was suggested that we could apply a tiny patc= h > 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, 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 concern= s. > > > > > > > > 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 > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > --000000000000d6c06805ffc41b87 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Finally had a chance to crank this out. Based on this thre= ad, I made the following updates:
- updated 4.1.8 (createOffer) to indi= cate that offers reflect the application's preferences as well as the i= mplementation's=C2=A0capabilities
- removed text from that se= ction that asserted that you couldn't reoffer your full capabilities in= a re-offer scenario (previously discussed and agreed upon)
- add= ed RTCP and FEC mechanisms to the list of things that application might con= trol
- used Tim's language of "supported by the applicat= ion" rather than "enabled" to make things simpler
=

On Mon, Jun 5= , 2023 at 8:34=E2=80=AFAM Sean Turner <sean@sn3rd.com> wrote:
Thanks Justin!

spt

> On Jun 4, 2023, at 21:41, Justin Uberti <justin=3D40fixie.ai@dmarc.ietf.org= > wrote:
>
>
>
> On Wed, May 10, 2023 at 1:37=E2=80=AFAM Christer Holmberg <christer.holmb= erg@ericsson.com> wrote:
> Hi,
>
>=C2=A0
>
> Also note the following sentence in Section 4.1.8.:
>
>=C2=A0
>
> =E2=80=9CAn options parameter may be supplied to provide additional co= ntrol over the generated offer.=E2=80=9D
>
>=C2=A0
>
> Doesn=E2=80=99t this cover the issue?
>
>
> I think it would be worthwhile to tweak the sentence from 4.1.8 that y= ou previously mentioned to indicate that the mechanisms included in the SDP= are not just those supported by the browser, but also preferred by the app= lication. 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 chan= ges previously noted in option b).
>=C2=A0
>
> Another question: when I call createOffer, how does the browser/librar= y determine what has been =E2=80=9Cenabled=E2=80=9D, compared to what is = =E2=80=9Csupported=E2=80=9D?
>
>=C2=A0
>
> Regards,
>
>=C2=A0
>
> Christer
>
>=C2=A0
>
>=C2=A0
>
>=C2=A0
>
> From: Christer Holmberg <christer.holmberg=3D40ericsson.com@dmarc.ietf.org<= /a>>
> Sent: Wednesday, 10 May 2023 11.01
> To: Justin Uberti <justin@fixie.ai>; Christer Holmberg <christer.holmberg@ericsson.com= >
> Cc: rtcweb@ietf.o= rg
> Subject: RE: [rtcweb] JSEP-bis and WebRTC-Extensions Section 5.2
>
>=C2=A0
>
> Hi,
>
>=C2=A0
>
> >Part of the issue here is that we did spec the 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 R= TP extensions in line with media formats (IOW, we already have
>
> >some disparities in the spec). As to the solution here, we also ha= ve to deal with more than just the notion of "enabled" - there is=
>
> >also the change in how RTP header extensions are added in subseque= nt offers, which would probably be harder to do in a generic
>
> >statement, as it would have to override normative text later in th= e document.
>
> >
>
> >However I do recognize Christer's concern that there could be = other parts of JSEP that need the same treatment (specifically, FEC mechani= sms
>
> >and RTCP feedback mechanisms). To address this, we could do one of= the following:
>
> >a) Add a generic statement as Christer proposes suggesting that &q= uot;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 applicati= on might want to override "supported" (FEC and RTCP are the only = remaining
>
> >ones, I believe). We could use "supported by the application&= quot; as Tim mentions to make the change more editorial.
>
> >c) Just go forward with the current PR and revisit the situation i= n the future when needed
>
> >
>
> >I tend to think that b) will actually be the most surgical and una= mbiguous change, so I lean in that direction at the moment.
>
>=C2=A0
>
> I am ok with both a) and b).
>
>=C2=A0
>
> But, in Section 4.1.8 there is the following sentence:
>
>=C2=A0
>
>=C2=A0 =C2=A0 =E2=80=9CThe createOffer method generates a blob of SDP t= hat contains an offer
>
>=C2=A0 =C2=A0 per [RFC3264] with the supported configurations for the s= ession,
>
>=C2=A0 =C2=A0 including descriptions of the media added to this PeerCon= nection, the
>
>=C2=A0 =C2=A0 codec, RTP, and RTCP options supported by this implementa= tion, and
>
>=C2=A0 =C2=A0 any candidates that have been gathered by the ICE agent.= =E2=80=9D
>
>=C2=A0
>
> What does =E2=80=9Cimplementation=E2=80=9D refer to? The browser? If s= o, wouldn=E2=80=99t that sentence have to be changed too, as it now says th= at the SDP generated using createOffer will contain the RTP and RTCP option= s supported by the implementation (not the application)?
>
>=C2=A0
>
> Regards,
>
>=C2=A0
>
> Christer
>
>=C2=A0
>
>=C2=A0
>
> On Sun, May 7, 2023 at 12:51=E2=80=AFPM Christer Holmberg <christer= .holmberg=3D40ericsson.com@dmarc.ietf.org> wrote:
>
> Hi,
>
>=C2=A0
>
> >> Are there actually some real implementation issues behind the= proposed change, or is it only
>
> >> about W3C and IETF using different terminology?
>
> >
>
> > It=E2=80=99s 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 behavi= our is to offer _everything_ the
>
> > library/stack is capable of. The W3C is creating an API point tha= t 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=E2=80=99s webRTC implementations support a lot of RT= P 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.=C2=A0 Specifically: =E2=80=99supporte= d=E2=80=99 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)
>
>=C2=A0
>
> 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 wou= ld 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.
>
>=C2=A0
>
> Regards,
>
>=C2=A0
>
> Christer=C2=A0
>
>=C2=A0
>
>=C2=A0
>
>=C2=A0
>
> Sent from Outlook for iOS
>
> 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=3D40ericsson.com@dmarc.ietf.org>
>
> Cc: rtcweb@ietf.o= rg <rtcweb@ietf= .org>
> Subject: Re: [rtcweb] JSEP-bis and WebRTC-Extensions Section 5.2
>
>=C2=A0
>
> I was also thinking about this too - and I somewhat agree.
>
>=C2=A0
>
> We could replace =E2=80=98supported' with 'supported by the cu= rrent application=E2=80=99 since at a high level what this change does is t= o differentiate between extensions that the library (libwebrtc etc) can sup= port vs extensions the current application wants to support.
>
>=C2=A0
>
> It also makes it clearer that this is an editorial change.
>
>=C2=A0
>
> T.
>
>=C2=A0
>
> On 7 May 2023, at 11:10, Christer Holmberg <christer.holmberg=3D40ericsson.= com@dmarc.ietf.org> wrote:
>
>=C2=A0
>
> Hi,
>
>=C2=A0
>
> I have issues with the proposed change.
>
>=C2=A0
>
> First, AFAIK, "enabled" is not used in any other O/A specifi= cation.
>
>=C2=A0
>
> Second, my reading of "supported" is that it is something th= at the endpoint is actually willing to/capable of using within the session.=
>
>=C2=A0
>
> Third, within the JSEP O/A procedures, "supported" is used f= or other features (e.g., FEC mechanisms). Using other terminology for one f= eature will only confuse the reader, in my opinion.
>
>=C2=A0
>
> Fourth, if it is unclear what "supported" really means we sh= ould rather clarify that.
>
>=C2=A0
>
> Regards,
>
>=C2=A0
>
> Christer
>
>=C2=A0
>
> Sent from Outlook for iOS
>
> 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.o= rg <rtcweb@ietf= .org>; supe= ruser@gmail.com <superuser@gmail.com>
> Subject: [rtcweb] JSEP-bis and WebRTC-Extensions Section 5.2
>
>=C2=A0
>
> The WebRTC W3C WG is working on an extension spec that suggests behavi= or for RTP header extension O/A that conflicts slightly with the current ve= rsion 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 st= ate). Murray was supportive of this but wanted to make sure the WG was full= y behind this change first.
>
>=C2=A0
>
> 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 resu= lt O/A negotiation should a) use only the extensions that are enabled by th= e endpoint, and b) always reoffer all extensions, rather than the previousl= y negotiated set.
>
>=C2=A0
>
> I've made a PR that captures this request at https://github.com/rtcweb-wg/jsep/pull/1033/files, and it basically = makes two surgical changes:
>
> 1) replaces the use of "supported RTP header extensions" wit= h "enabled RTP header extensions"
>
> 2) changes the text around "extensions... present in the most rec= ent answer" to instead say "extensions... enabled on the associat= ed transceiver" (similar to how codecs are handled in JSEP).
>
>=C2=A0
>
> Please let me know if this sounds reasonable to you or you have concer= ns.
>
>=C2=A0
>
> Thanks,
>
> Justin
>
>=C2=A0
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb >
>=C2=A0
>
>=C2=A0
>
> _______________________________________________
> 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
--000000000000d6c06805ffc41b87--