Unclear whether XxxTransport is really closed or not

[ibc]

In WebRTC 1.0 calling peerconnection.close() is required even if it fires a "failed" "oniceconnectionstatechange" event, otherwise it is not freed.

In ORTC, and with a recent change, a RTCDtlsTransport may fire a "closed" ondtlsstatechange event (without the user having called stop() on it).

Also, a RTCIceTransport may fire "failed" or "closed" onicestatechange...

So, when should the user assume that a RTCDtlsTransport and a RTCIceTransport has been definitely closed (and "freed")?

If for example the remote peer sends me a DTLS close alert and my RTCDtlsTransport fires "closed" ondtlsstatechange, should I call stop() on it or not?

[ibc]

I would extend this question to all the object within the ORTC spec. The draft should clearly define the lifetime of them and clarify which method and/or events free the object.

[aboba]

If dtlsTransport.state is already "closed" then calling stop() will not change the value of state. The dtlsTransport will not be garbage collected until references are removed, so calling stop() has no effect and is not necessary.

[ibc]

Clear. However, and given that RTCPeerConnection is not GC'd until stop() is called, I suggest adding the above information into the ORTC draft.

[robin-raymond]

I think there is confusion about an object being able to garbage collect its internal state vs when an object itself can be GC'ed. In ORTC, an object's internal state can be GC'ed when it goes into the final state (eg. "closed"). Each ORTC object itself can be GCed when no further reference to the object exists. The caveat is that some ORTC objects keep a reference to other ORTC objects. For example, the programmer holding a reference to the DataChannel indirectly also holds a reference to the SctpTransport, DtlsTransport, IceTransport and IceGatherer. So which are we trying to clarify here as I think the documentation for this is different depending on the context.

[robin-raymond]

Further comment: The pull request #400 is accurate but is missing some important information. We need to define which ORTC objects internally keep references to other ORTC objects to the GC is very clear.