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

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

== Should setOfferedHeaderExtensions be allowed to restart stopped extensions? ==
Spinoff from #132 since we should decide what makes sense.

JSEP section 5.2.2 says that subsequent offer/answer can only use the set of header extensions from the initial offer/answer - no adding header extensions later.

We modify (in section 6.1) the procedures for subsequent offers indicating that it is OK to turn on header extensions later.
If this is needed in a realistic scenario, we should support it; if it's not needed, there's no real reason for changing JSEP on this point.

Possible approaches are:

1. Allow turning on header extensions later (overriding current JSEP text)
2. Let SetOfferedHeaderExtensions throw an InvalidStateError if the negotiation state is not "new" and the call attempts to change an extensions that is not in [[HeaderExtensionsNegotiated]] from "stopped" to something else
3. Let the algorithm in section 6.1 iterate over [[HeaderExtensionsNegotiated]] rather than over [[HeaderExtensionsToOffer]], effectively following the current JSEP rule, but providing no feedback to the user that he attempted something impossible

My current thinking is that I think favor approach \#2, possibly also doing \#3. I'm sure there are other possible approaches.

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

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

Received on Sunday, 4 December 2022 13:29:24 UTC