Re: [webrtc-pc] Remove stopped transceivers from getTransceivers() (#2092)

I said yesterday in review I was having [doubts about this]( I've slept on it, and I see a problem: stats.

Stats closely [model internal object lifetimes](, so this isn't just for people who care about stats. Today, our model is that the majority of [monitored objects]( live for the lifetime of the peer connection, beyond `pc.close()` so apps can query what happened posthumously. Only objects actively *replaced*—TrackAttachmentStats by *replaceTrack*, and CandidateStats by *iceRestart*—get removed and fired in [statsended](, to curtail bloat over time (sound familiar?)


Would related sender, receiver, rtp and candidate stats disappear from `pc.getStats()` on *stop()* now? On SRD(offer) with port=0? That might be hard to foresee. On *close()*? That might fire events after *close()*, something we've avoided thus far. What if I keep a reference to a *sender* and call `sender.getStats()` on it? Does it succeed?

In short, the lifetime question is harder than removing stopped transceiver from *getTransceivers()*. We have to specify when related objects become garbage collectable, in a way that doesn't let JS detect garbage collection.

If we *don't* remove the stats, we arguably haven't fully solved the transceiver bloat problem.

The silver lining here is that stats has already solved this once, just not this way.

GitHub Notification of comment by jan-ivar
Please view or discuss this issue at using your GitHub account

Received on Wednesday, 13 March 2019 14:38:13 UTC