Webrtc-pc: createOffer(): Built-in certificate behavior

[aboba]

            <code>RTCPeerConnection</code> is used to produce a set of
            certificate fingerprints. These certificate fingerprints are
            used in the construction of SDP and as input to requests for
            identity assertions.

This isn't quite correct, since automatically generated certificates don't appear in the RTCConfiguration.

[fippo]

related question, in "set a configuration" we have

If server.urls is a string, let server.urls be a list consisting of just that string.

If the "set a configuration algorithm does that change, is it reflected in the configuration returned by getConfiguration or not?

[taylor-b]

That's my assumption. And that makes the implementation simpler, since it doesn't need to remember "was I given urls as a string or a list?"; it will always be returned as a list.

[fippo]

Yes, but it makes the following assumption invalid:

var pc = new RTCPeerConnection(someConfiguration);
var config = pc.getConfiguration();
// someConfiguration deep equals config

which would also be violated if getConfiguration were to return the generated certificates.

(i'm fine with violating that assumption)

[jan-ivar]

@fippo That assumption is already invalid, because WebIDL normalizes various things already, like default values and empty dictionaries in place of their absence. E.g. with

var pc = new RTCPeerConnection({iceServers:[]});

pc.getConfiguration() will at minimum produce:

{
  bundlePolicy: "balanced",
  iceCandidatePoolSize: 0,
  iceServers: [],
  iceTransportPolicy: "all",
  rtcpMuxPolicy: "require",
};

This came up before in https://github.com/w3c/mediacapture-main/issues/360. I support fewer ways of reading the same data.

[fippo]

@jan-ivar webidl doesn't take care of {urls: "stun:..."}) though ;-)