- From: Harald Alvestrand via GitHub <sysbot+gh@w3.org>
- Date: Tue, 22 Feb 2022 11:28:42 +0000
- To: public-webrtc@w3.org
alvestrand has just created a new issue for https://github.com/w3c/webrtc-extensions: == Should RtcRtpHeaderExtensionCapabilities offer an "enabled" member? == Current text on RTCRtpHeaderExtensionCapabilities says that each entry contains only the URL. The default header extensions to offer is constructed by this text: "Let [[HeaderExtensionsToOffer]] be an internal slot of the [RTCRtpTransceiver](https://www.w3.org/TR/webrtc/#dom-rtcrtptransceiver), initialized to the platform-specific list of implemented RTP header extensions. The [direction](https://w3c.github.io/webrtc-extensions/#dom-rtcrtpheaderextensioncapability-direction) attribute for all extensions that are mandatory to use MUST be initialized to an appropriate value other than "[stopped](https://www.w3.org/TR/webrtc/#dom-rtcrtptransceiverdirection-stopped)". The direction attribute for extensions that will not be offered by default in an initial offer MUST be initialized to "stopped"." This doesn't seem to offer the option of figuring out what header extensions can be set. Suggestion: Add a string "defaultDirection" to the RTCRtpHeaderExtensionCapabilities, and modify the text quoted above to say "initialized to the value of [[defaultHeaderExtensionCapabilities]]" with "direction" set to "defaultDirection". If we don't modify capabilities, there seems to be an inconsistency between capabilities as returned by "getCapabilities" and the information returned by creating a Transceiver and querying its HeaderExtensionsToOffer parameter. Please view or discuss this issue at https://github.com/w3c/webrtc-extensions/issues/99 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 22 February 2022 11:28:44 UTC