W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > February 2018

[webrtc-pc] Semi-sync replaceTrack API pre-initial-negotiation is bizarre.

From: jan-ivar via GitHub <sysbot+gh@w3.org>
Date: Mon, 12 Feb 2018 15:54:50 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issues.opened-296425333-1518450889-sysbot+gh@w3.org>
jan-ivar has just created a new issue for https://github.com/w3c/webrtc-pc:

== Semi-sync replaceTrack API pre-initial-negotiation is bizarre. ==
As mentioned in this [chrome bug](https://bugs.chromium.org/p/chromium/issues/detail?id=811265), `replaceTrack` is spec'ed to be [semi-synchronous when](https://w3c.github.io/webrtc-pc/#dom-rtcrtpsender-replacetrack) the *"transceiver is not yet associated with a media description"*.

As I recall, this was a compromise reached long ago out of concern there'd be no way to synchronously set a track in time for createOffer, and was made before createOffer became impervious to these timing issues.

But this leaves users with a bizarre API: **if an error happens,  they won't know which one until later**. So it's never a fully synchronous API even in the pre-negotiation phase.

Users would have to write:
if (sender.track != newTrack) {
  throw Error("An error happened, but we don't know which one (yet)!");
...if they were called synchronously and are expected to throw an exception for errors.

Of course, if they're not then they can get the error after the fact:
let p = sender.replaceTrack(newTrack);
if (sender.track != newTrack) {
  await p; // rejects
... but then it begs the question why they're not just using:
await sender.replaceTrack(newTrack);

FWIW I think we'd be happy to change Firefox to match Chrome here, and fix the spec.

Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1769 using your GitHub account
Received on Monday, 12 February 2018 15:54:54 UTC

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