Re: [webrtc-pc] pc.addTrack/removeTrack can be described in terms of Transceivers. This may be good for understanding them. from Jan-Ivar Bruaroey via GitHub on 2018-07-11 (public-webrtc-logs@w3.org from July 2018)

From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
Date: Wed, 11 Jul 2018 17:52:12 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-404256319-1531331531-sysbot+gh@w3.org>

Again, I'm not advocating we remove `addTrack` entirely, as it has some advantages when answering—It lets you add tracks ahead of an incoming offer in the trivial case, or in every case if you don't care about the number of m-lines produced). But it's behavior there is confusing, which can cause media to happen on new m-lines you weren't expecting.

In contrast, answering completely without `addTrack` is highly asymmetric, as I show in [my blog](https://blog.mozilla.org/webrtc/rtcrtptransceiver-explored/) if you scroll down a bit, but is also the only abstraction that doesn't leak.

I'm mostly concerned about users reading the spec, attempting to grok its model. We could start by deemphasizing use of `addTrack` in examples at least.


-- 
GitHub Notification of comment by jan-ivar
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1758#issuecomment-404256319 using your GitHub account

Received on Wednesday, 11 July 2018 17:52:31 UTC