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

[Justin Uberti <[e-mail]>]

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 AM Sean Turner <[e-mail]> wrote:

> Thanks Justin!
>
> spt
>
> > On Jun 4, 2023, at 21:41, Justin Uberti <justin=
> [e-mail]> wrote:
> >
> >
> >
> > On Wed, May 10, 2023 at 1:37 AM Christer Holmberg <
> [e-mail]> 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=[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 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]> 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
> >
> > From: rtcweb <[e-mail]> on behalf of Tim Panton <
> [e-mail]>
> > Sent: Sunday, May 7, 2023 1:16:27 PM
> >
> > To: Christer Holmberg <christer.holmberg=[e-mail]>
> >
> > Cc: [e-mail] <[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]> 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 <[e-mail]> on behalf of Justin Uberti <
> [e-mail]>
> > Sent: Saturday, May 6, 2023 3:30:33 AM
> > To: [e-mail] <[e-mail]>; [e-mail] <
> [e-mail]>
> > Subject: [rtcweb] JSEP-bis and WebRTC-Extensions Section 5.2
> >
> >
> >
> > The WebRTC W3C WG is working on an extension spec 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, 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]
> > https://www.ietf.org/mailman/listinfo/rtcweb
> >
> >
> >
> >
> >
> > _______________________________________________
> > rtcweb mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/rtcweb
> >
> > _______________________________________________
> > rtcweb mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/rtcweb
>
>