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

Christer,

One implementation change, unrelated to terminology, is that in the
subsequent offers, all enabled RTP extensions are offered, vs. only the
extensions accepted by the last answer. I think this is a good change since
it brings RTP extension negotiation in line with CODEC negotiation. It also
solves some issues with 3PCC scenarios.

Best Regards,
_____________
Roman Shpount

On Sun, May 7, 2023 at 8:16 AM Christer Holmberg <christer.holmberg=
40ericsson.com@dmarc.ietf.org> wrote:

> Hi,
>
> I don’t think you would use O/A as a mechanism to indicate what your
> library can support in general. For example, your library may support
> video, but you are not going to offer video unless you intend to use it.
>
> Regarding your suggestion, would it be only for the RTP header extensions?
> If so, we would say “supported by the application” for one feature and
> “supported” for the other features, which I still think would be confusing.
>
> Are there actually some real implementation issues behind the proposed
> change, or is it only about W3C and IETF using different terminology?
>
> 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
>