W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > December 2020

Re: [webrtc-pc] Add note to getCapabilities to avoid InvalidModificationError (#2617)

From: henbos via GitHub <sysbot+gh@w3.org>
Date: Tue, 15 Dec 2020 08:49:50 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-745144937-1608022189-sysbot+gh@w3.org>
> @henbos I don't see anything in the existing spec suggesting "the same", so I don't think a note can say that.

The sameness is not called out in the spec, but is inferred from the intended use cases of the APIs. For example, we have recommended the Perfect Negotiation pattern. But if the user of this API has to do a dance of calling negotiation methods before getCapabilities() works, then we can no longer "abstract away negotiation" from the application, and methods like setCodecPreferences() become "special" methods.

First of all, you are entirely correct that this isn't called out in the spec. But let me remind everybody that there is also nothing suggesting that I have to call createOffer() in order for getCapabilities() to work. So why would you? For example, it would be reasonable to expect the following code snippet to work:

// Setup code.
pc.onnegotiationneeded = (perfect negotiation pattern);
// Application code.
const transceiver = pc.addTransceiver("video");
let codecs = getCapabilities().codecs;
codecs = getCodecsWithH264First(codecs);

Or, here's another example, that doesn't even involve Perfect Negotiation, but where SDP wouldn't have been created by your peer connection before getCapabilities():

await pc.setRemoteDescription(remoteOffer);
// Transceiver created by offer.
const transceiver = pc.getTransceivers()[0];
let codecs = getCapabilities().codecs;
codecs = getCodecsWithH264First(codecs);
const answer = await pc.createAnswer();

All of this being said though, I agree with the sentiments:

> Since getCapabilities is synchronous and so trivial to call, why respect results that predate the current run of the event loop that calls the synchronous setCodecPreferences?

This is good. I can't think of any use case where you would have to remember "old" codecs. And if it is only to be used within the same event loop cycle, this would be consistent with get/setParameters() semantics.

However, we cannot simply assume that createOffer() or createAnswer() has already been called. It might have been setRemoteDescription() that was the first call.

GitHub Notification of comment by henbos
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/pull/2617#issuecomment-745144937 using your GitHub account

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 15 December 2020 08:49:51 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 6 May 2023 21:19:52 UTC