Implementations only update getParameters().codecs when negotiation has finished

[jan-ivar]

(I'll refer to the https://www.w3.org/TR/webrtc version of the spec here to avoid the #2956 regression on github tip.)

When I test Chrome, Edge, and Safari with https://jsfiddle.net/jib1/9kz2bf85/ by selecting "VP9" and clicking Negotiate, I see (because it uses setCodecPreferences with a truncated array for brevity):

Switching codec to video/VP9
In "have-local-offer", tc1.sender.getParameters().codecs = []
In "have-local-offer", tc1.receiver.getParameters().codecs = []
In "have-remote-offer", tc2.sender.getParameters().codecs = []
In "have-remote-offer", tc2.receiver.getParameters().codecs = []
In "stable", tc1.sender.getParameters().codecs = [
  {
    "clockRate": 90000,
    "mimeType": "video/VP9",
    "sdpFmtpLine": "profile-id=0",
    "payloadType": 98
  }
]
In "stable", tc1.receiver.getParameters().codecs = [
  {
    "clockRate": 90000,
    "mimeType": "video/VP9",
    "sdpFmtpLine": "profile-id=0",
    "payloadType": 98
  }
]
pc1 is sending video/VP9
pc2 is sending video/VP9

All three browsers return an empty codec array until initial negotiation has finished ("stable").

If I now select "H264" and hit Negotiate again, instead of empty codecs, I see "VP9" until renegotiation has finished and it's replaced with "H264".

This seems nice and simple: sender/receiver.getParameters().codecs reflects what's been (fully) negotiated.

We should probably align the spec to say this.

Fixing the spec means:

1. Stop updating [[ReceiveCodecs]] in sLD
2. Only update [[ReceiveCodecs]] in the answer (where [[SendCodecs]] is already updated)
3. Remove [[LastStableStateReceiveCodecs]] and associated rollback code

[alvestrand]

Seems like we want this getter to reflect the content of the currently negotiated SDP description, and this is independent of the SendCodecs and ReceiveCodecs (it's a shorthand for an SDP parser).

[jan-ivar]

Seems like we want this getter to reflect the content of the currently negotiated SDP description,

Yes, that seems a useful way to look at it.

and this is independent of the SendCodecs and ReceiveCodecs (it's a shorthand for an SDP parser).

Internal slots are cheap, as long as we're not confusing things we can do it a couple of ways.

But for consistency with 1.0 (and TR) we may wish to keep [[SendCodecs]] and [[ReceiveCodecs]] the same, doing their old job of reflecting currentDescription (at least as implemented when it comes to [[ReceiveCodecs]]). E.g. start out empty (when currentDescription is null).

In #2956 (comment) I proposed some new internal slots.

[alvestrand]

Having slept on it, it seems that we've been using SendCodecs and ReceiveCodecs for two different things:

• Representing the capabilities of the transceiver (used to be the capabilities of the platform)
• Representing the current set of negotiated codecs
  It seems logical that this needs to be two different internal slots. The "current set of negotiated codecs" doesn't need the Enabled bit - it can be just a simple representation of what's in the currently valid SDP.

Suggested new names:
[[NegotiatedCodecs]] - occurs both in sender and receiver (has PT, does not have Enabled)
[[AvailableCodecs]] - occurs both in sender and receiver (has Enabled, does not have PT)