- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Mon, 25 Feb 2019 16:15:27 +0000
- To: public-webrtc-logs@w3.org
> The Chrome implementers interpreted the transceiver being added by addTrack as one of the conditions. Firefox does the same, because that is what the spec says, and it was intentional, as I recall. The thinking was: if you add a transceiver, you mean to add a new transceiver. If you add a track, then your expectation is (historically) more likely to be symmetrical. By having both methods you get to choose. > This forced the application to do workarounds like adding media at a later stage or discouraging you from using the addTransceiver API. This is why *addTrack* is still in the spec. FWIW I cover both ways of answering in [my blog](https://blog.mozilla.org/webrtc/rtcrtptransceiver-explored/), search for *"How to answer ONLY with transceivers"* if you must use *addTransceiver*, and yes, it's highly asymmetrical. > Proposal: Transceivers are associated based on their own merits, not which API caused its creation. I personally think this has some merit, but one would need to weigh the trade-offs, and I don't see any new information here. -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2108#issuecomment-467073312 using your GitHub account
Received on Monday, 25 February 2019 16:15:29 UTC