[rtcweb] Is support for two-byte RTP header extensions mandatory?

[Philipp Hancke <[e-mail]>]

This spawned from a discussion with Harald Alvestand.

Neither
  https://www.rfc-editor.org/rfc/rfc5285.html
nor its successor
  https://www.rfc-editor.org/rfc/rfc8285
nor the RTP usage draft
  https://datatracker.ietf.org/doc/html/rfc8834#name-header-extensions
provide guidance on whether WebRTC mandates two byte header extensions and
how/if this is negotiated using offer-answer.
Nor is this negotiated as extmap-allow-mixed only implies support (if you
can mix one-byte and two-byte versions you must support both)

Another issue here is how an implementation that does not support two-byte
extensions should deal with an extension id 15
which is forbidden in the one-byte variant. Should offerers skip this id
when generating offers?

Firefox rejects ids greater than or equal to 15
  https://github.com/web-platform-tests/wpt/pull/41843
complaining libWebRTC does not support two-byte extensions (which it does).

libWebRTC-based browsers implement and can negotiate up to 16 extensions
these days (with some not enabled by default yet)
This is not a practical problem yet since some of those extensions are not
very useful when used together which means
most real-world scenarios need less than 15 extensions.

The path forward seems to agree that two-byte extensions are a thing and
cross fingers that implementations will continue to need less than 15
extensions for long enough to get Firefox fixed.

Thoughts?

Philipp