[webrtc-pc] getCapabilities().headerExtensions (#3078)

henbos has just created a new issue for https://github.com/w3c/webrtc-pc:

== getCapabilities().headerExtensions ==
We're in the process of moving the header extensions API to webrtc-pc, see #3060, so I'm filing this here (webrtc-pc), but the header header extension extension API is currently described [here](https://w3c.github.io/webrtc-extensions/#rtp-header-extension-control).

We've introduced "direction":
```
partial dictionary [RTCRtpHeaderExtensionCapability](https://www.w3.org/TR/webrtc/#dom-rtcrtpheaderextensioncapability) {
  required [RTCRtpTransceiverDirection](https://www.w3.org/TR/webrtc/#dom-rtcrtptransceiverdirection) direction;
};
```
Which is `required` and very well defined in the context of get/setHeaderExtensionsToNegotiate(). But we never really spell out what "direction" means in the context of `getCapabilities()`.

The only language we have is from webrtc-pc here (for [sending](https://w3c.github.io/webrtc-pc/#dfn-list-of-implemented-header-extensions-for-sending)/[receiving](https://w3c.github.io/webrtc-pc/#dfn-list-of-implemented-header-extensions-for-receiving)), e.g:
> The list of implemented header extensions for sending, given kind, is an [implementation-defined](https://infra.spec.whatwg.org/#implementation-defined) list of [RTCRtpHeaderExtensionCapability](https://w3c.github.io/webrtc-pc/#dom-rtcrtpheaderextensioncapability) dictionaries representing the most optimistic view of the header extensions the user agent supports for sending media of the given kind (video or audio).

The [dependency descriptor](https://aomediacodec.github.io/av1-rtp-spec/#dependency-descriptor-rtp-header-extension) is a good example of a header extension that (I think) everyone supports but which is not negotiated by default, so `getHeaderExtensionsToNegotiate()` returns it with `direction: "stopped"`. But what should `getCapabilities()` say?
1. It should say `sendrecv` because support is implemented for both sending and receiving and the most "optimistic view" would include both sending and receiving.
2. It should say `stopped` because it's not used by default, the fact that it is listed is proof in and of itself that DD is supported for feature detection purposes.

We should probably spell this out as part of the move. Also I found that Chrome doesn't list stopped header extensions at all when getCapabilities is called, which seems like a mistake.

Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/3078 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 8 October 2025 12:34:21 UTC