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

[Harald Alvestrand <[e-mail]>]

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=[e-mail]>
> *Sent:* Wednesday, 10 May 2023 11.01
> *To:* Justin Uberti <[e-mail]>; Christer Holmberg 
> <[e-mail]>
> *Cc:* [e-mail]
> *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=[e-mail] 
> <mailto:[e-mail]>> 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 <[e-mail]
>         <mailto:[e-mail]>> on behalf of Tim Panton
>         <[e-mail] <mailto:[e-mail]>>
>         *Sent:* Sunday, May 7, 2023 1:16:27 PM
> 
>         *To:*Christer Holmberg
>         <christer.holmberg=[e-mail]
>         <mailto:[e-mail]>>
> 
>         *Cc:*[e-mail] <mailto:[e-mail]> <[e-mail]
>         <mailto:[e-mail]>>
>         *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=[e-mail]
>             <mailto:[e-mail]>> 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 <[e-mail]
>             <mailto:[e-mail]>> on behalf of Justin Uberti
>             <[e-mail] <mailto:[e-mail]>>
>             *Sent:* Saturday, May 6, 2023 3:30:33 AM
>             *To:* [e-mail] <mailto:[e-mail]>
>             <[e-mail] <mailto:[e-mail]>>;
>             [e-mail] <mailto:[e-mail]>
>             <[e-mail] <mailto:[e-mail]>>
>             *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
>             [e-mail] <mailto:[e-mail]>
>             https://www.ietf.org/mailman/listinfo/rtcweb
>             <https://www.ietf.org/mailman/listinfo/rtcweb>
> 
>     _______________________________________________
>     rtcweb mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/rtcweb
>     <https://www.ietf.org/mailman/listinfo/rtcweb>
> 
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb