Let createOffer and createAnswer resolve with RTCSessionDescription instead of RTCSessionDescriptionInit

[foolip]

https://w3c.github.io/webrtc-pc/#interface-definition

Both Blink and Gecko use RTCSessionDescription here, at least in the IDL:
https://github.com/mozilla/gecko-dev/blob/d3b37a02baa51459a8745ef9449c234cd26f8d1c/dom/webidl/RTCPeerConnection.webidl#L99
https://chromium.googlesource.com/chromium/src/+/b3ccf01a59d182eee56040de8624d4b1b01abe73/third_party/WebKit/Source/modules/peerconnection/RTCPeerConnection.idl#71

@jan-ivar

[fippo]

Wouldn't this imply that .type is readonly which would disallow changing the type of answer to pranswer?
See createAnswer, in particular
An answer can be marked as provisional, as described in [JSEP] (section 4.1.7.1.), by setting the type to pranswer.

[jan-ivar]

@foolip This would appear to make the problem you mention in #573 (comment) more common.

[foolip]

OK, so there's a use case for modifying the return value. (I know little about the semantics and am just noticing differences between spec and implementations, so pardon if this was obvious.)

The way it's implemented in Blink is to create a new RTCSessionDescription instance, and because its attributes are mutable it would work. But to change RTCSessionDescription to be immutable without without also changing RTCSessionDescription to RTCSessionDescriptionInit in these contexts would be risky.

So, I conclude that if the RTCSessionDescription changes turn out not be web compatible and need to be reverted, then that would be the time to change this as well. Does that sound about right? If so, this can be closed for now, and be revisited if #573 doesn't work out.

[alvestrand]

PR-Answer is being discussed in RTCWEB. That discussion may converge in Korea.

[alvestrand]

Is this solved by #949?

[jan-ivar]

This issue basically observes that implementations are behind the spec, which I'm about to fix.

@foolip said this could be closed, and I agree. #949 was about the legacy callbacks.

[alvestrand]

OK, closing.

[fippo]

I have a question related to this which was introduced in #574 after Chrome was just updated to "follow the spec" which broke because toJSON can no longer be called.

• How is toJSON supposed to be used now?
• How is returning a dictionary consistent with emitting a candidate object in the iceevent?

I'll note that returning RTCSessionDescription has not been a problem for anyone for the last eight years despite Firefox and Safari not doing so. Most web developers who have been around for a while stopped trusting toJSON after this issue

[jan-ivar]

• How is toJSON supposed to be used now?

No need. It was a workaround. You now have the object toJSON() would have returned #2969.

toJSON is a detail function in service of JSON.stringify(), not normally meant to be called directly.

• How is returning a dictionary consistent with emitting a candidate object in the iceevent?

It is consistent with apps' desire to mutate the offer or answer returned while pc.localDescription.sdp and sender.transport.iceTransport.getSelectedCandidatePair().remote.candidate remain immutable. #573

I'll note that returning RTCSessionDescription has not been a problem for anyone for the last eight years despite Firefox and Safari not doing so. Most web developers who have been around for a while stopped trusting toJSON after this issue

What are they doing then?

[fippo]

Thank you, this is starting to make sense!
I assume the wrong notion of "toJSON is something developers should call" comes from this MDN article which also does 😡 callback APIs

We still should have better tests than "createAnswer works", i'll take that.