getCapabilities().headerExtensions

[henbos]

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.

We've introduced direction:

partial dictionary RTCRtpHeaderExtensionCapability {
  required 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/receiving), e.g:

The list of implemented header extensions for sending, given kind, is an implementation-defined list of 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 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. Actually that's a third option:

3. Don't list things that are not enabled by default.

[fippo]

This is largely from how ORTC worked. You can infer the direction from whether the capabilities are present in either or both sender and receiver capabilities.

[henbos]

Are you suggesting it should be listed as its default value stopped (proposal 2) because you can infer capability from if you polled the RTCRtpSender capabilities, RTCRtpReceiver capabilities, both or neither? This being the only way to convey both capabilities and default values with a single attribute

[fippo]

3. Keep on not including stopped ones, use sendonly / recvonly in the respective sender/receiver caps.

I think we agreed that you can not use getCapabilities as input to setHeaderExtensionsToNegotiate a while back.

[henbos]

I think we agreed that you can not use getCapabilities as input to setHeaderExtensionsToNegotiate a while back.

getCapabilities is for feature detection not for input to that method, get/setHeaderExtensionsToNegotiate only works the list is same size and all uri's are unmodified, mirroring the get/setParameters pattern. This issue is not related to that.

What is confusing is I have several times polled getCapabilities thinking it works for feature detection only to find out it gives an incomplete result, which seems like a bug, why hide capabilities?

[henbos]

I think that implementing proposal 2 is a one-line change of removing this if-statement:
https://source.chromium.org/chromium/chromium/src/+/main:third_party/webrtc/media/base/media_engine.cc;l=85;drc=d2254677af3346db4c7a019df444f0e48e9c8b5d

[fippo]

which from w3c/webrtc-extensions#99 is non-spec behavior anyway.