[webrtc-pc] What holds on to RTCOfferOptions and its iceRestart member (#3028)

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

== What holds on to RTCOfferOptions and its iceRestart member ==
https://w3c.github.io/webrtc-pc/#dictionary-rtcofferoptions-members defines a bunch of semantics, but it's not entirely clear what's meant to reference it.

It makes mention to "the relevant `RTCPeerConnection` object" — presumably this is the `RTCPeerConnection` instance which had its `createOffer(optional RTCOfferOptions options = {})` called with that `RTCOfferOptions` dictionary, but is this just held together via some magic internal property (on the dictionary) or is it held together in some other way?

It's also not immediately clear as someone slightly detached from WebRTC "generated description" is meant to be — it's the only time the phrase appears, which is potentially surprising given it's far from the only thing that affects constructing an offer.

https://w3c.github.io/webrtc-pc/#dfn-final-steps-to-create-an-offer says:

> Given the information that was obtained from previous inspection, the current state of connection and its RTCRtpTransceivers, generate an SDP offer, sdpString, as described in [RFC9429] (section 5.2.).

Is it part of the current state of the connection? Because it's not obviously part of the state, especially given it's not referenced in [State Definitions](https://w3c.github.io/webrtc-pc/#state-definitions) — nothing made it part of the state, it just magically changes the description?

And https://www.rfc-editor.org/rfc/rfc9429#section-5.2.3 actually directly specifies behaviour based on the `RTCOfferOptions` object, again as if it's magically been passed across (and somehow it changes from the `iceRestart` member to presumably equivalent the `IceRestart` member, despite these being separate IDL dictionary keys).

From a spec point-of-view, it seems like RFC9429 is meant to read up the call stack, across an [in parallel](https://html.spec.whatwg.org/multipage/infrastructure.html#in-parallel) call, from:

 * RFC9429 5.2 Constructing an Offer
 * The final steps to create an offer
 * The in-parallel steps to create an offer
 * To create an offer
 * The `createOffer` method steps

Only the top-most algorithm — the `createOffer` method steps — actually receives the `RTCOfferOptions` dictionary as an argument (and then doesn't do anything with it), thus presumably the ultimate reference in RFC9429 just magically walks the call stack?

This doesn't seem ideal from a specification point of view to have things magically reading up to what parent algorithms got as arguments — if the arguments are relevant, they should be passed down the call stack.

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


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

Received on Friday, 6 December 2024 01:50:23 UTC