- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Tue, 22 Sep 2020 18:39:13 +0000
- To: public-webrtc-logs@w3.org
Having tranceivers sometimes (but not always) disappear on return from `transceiver.stop()` might be more confusing, not less. Unless someone can point to some assumption that falls apart, it seems less surprising for the stopped transceiver to linger and disappear at answer time, just like it would were it `stop()`ed later. To address the two arguments for a change: > This means that pc.getTransceivers() will contain an element that is irrelevant to the current offer/answer exchange. Sure, but that's not unusual, since transceivers can be added by JS at any time, whether there's an ongoing O/A or not. > If my transceiver was instantly removed, there wouldn't be a pointless follow-up offer. If my transceiver wasn't removed, I'd have to do a follow-up O/A exchange that says "here's an inactive and stopped m= section for you, there you go" As @alvestrand points out [above](https://github.com/w3c/webrtc-pc/issues/2576#issuecomment-696572432) this does not cause a follow-up O/A, so not an issue. So I don't think I see enough arguments here for a change (which would be a normative one). JSEP clearly tolerates the presence of stopped transceivers, which I interpret to mean that having them linger was by design. -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2576#issuecomment-696906493 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 22 September 2020 18:39:15 UTC