Re: [webrtc-extensions] Should setOfferedHeaderExtensions be allowed to restart stopped extensions? (#134)

The spec already says...

> In the algorithm for generating subsequent offers in [[RTCWEB-JSEP](https://w3c.github.io/webrtc-extensions/#bib-rtcweb-jsep)] section 5.2.2, replace "The RTP header extensions MUST only include those that are present in the most recent answer" with "For each RTP header extension listed in [[[HeaderExtensionsToNegotiate]]](https://w3c.github.io/webrtc-extensions/#dfn-headerextensionstonegotiate), and where [direction](https://w3c.github.io/webrtc-extensions/#dom-rtcrtpheaderextensioncapability-direction) is not "[stopped](https://www.w3.org/TR/webrtc/#dom-rtcrtptransceiverdirection-stopped)", generate an appropriate "a=extmap" line with "direction" set according to the rules of [[RFC5285](https://w3c.github.io/webrtc-extensions/#bib-rfc5285)] section 6, considering the [direction](https://w3c.github.io/webrtc-extensions/#dom-rtcrtpheaderextensioncapability-direction) in [[[HeaderExtensionsToNegotiate]]](https://w3c.github.io/webrtc-extensions/#dfn-headerextensionstonegotiate) to indicate the answerer's desired usage".

So it appears we are already allowing restarting stopped extensions. If we are OK with that, we can close this issue as WontFix. Otherwise if we want to be consistent with the [recent changes to the API](https://github.com/w3c/webrtc-extensions/pull/142) then we should just restrict the direction to what is possible rather than slow, but I'm not sure I see any benefit to not being allowed to turn something on just because it was previously missing so I think I'd rather just close this issue... thoughts?

-- 
GitHub Notification of comment by henbos
Please view or discuss this issue at https://github.com/w3c/webrtc-extensions/issues/134#issuecomment-1452155046 using your GitHub account


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

Received on Thursday, 2 March 2023 16:25:23 UTC