Close other peer's dtls & datachannel after unload

[jan-ivar]

From #2489 (comment) it appears Firefox & Chrome 82 close other peer's datachannels after unload.

This covers closing a tab/window, navigation and reload. This seems useful to specify.

It would probably suffice to run (part of) the close algorithm on all peer-connections on the page, including iframes, on tear-down (this is what Firefox does).

[jan-ivar]

On second thought, it might be useful to only shut down the transport objects, to leave the door open to bfcaching a peer connection. @youennf thoughts?

[youennf]

Related to w3c/webrtc-extensions#200.

I do not see why we are special casing data channel here.
Isn't closing a data channel similar to stopping a transceiver?

I am not exactly sure what you mean by shutting down the transport objects.
If the DTLS connection is closed, the SCTP will get closed so the data channel will be closed, right?

If we simulate a network error or a freeze of the whole process doing networking, we would probably end up going in disconnected or failed ICE transport state after some time spent in the b/f cache (except the page will only be notified of those changes if resurrected from the b/f cache). If we just go back and forth (like I wrongly navigated and went back), the connection would probably remain the same.

[jan-ivar]

I do not see why we are special casing data channel here.

Happy to include dtls if it helps the discussion, as long as we're specific.

If the DTLS connection is closed, the SCTP will get closed

That's one way (through "close_notify alert"), the other being reception of SCTP ABORT. The pc.close algorithm mentions "sending an SCTP ABORT chunk", so I'm not 100% sure which one gets the credit.

Regardless, they're intentional termination signals. But how terminal are they to our objects?

Isn't closing a data channel similar to stopping a transceiver?

I think we're talking about closing the SctpTransport (pc.sctp), i.e. all datachannels permanently. See #2486. It's not clear to me this is recoverable. if I pc.createDataChannel("onemore") and renegotiate, what happens?

In contrast, stopping a transceiver is a negotiated property (without negotiation it sends RTCP BYE which merely mutes the remote track).

If we just go back and forth (like I wrongly navigated and went back), the connection would probably remain the same.

Then we'd need to avoid all terminal steps in the pc.close algorithm. It's a bit unclear to me what those are, but I fear it's most of them.

[alvestrand]

Seems like we have a simpler world if page.onunload() triggers pc.close() automatically. Recovery is complicated, and we have had no use cases where recovery is helpful.

Things may be different in webrtc-nv.

[jan-ivar]

Conclusion: Close pc on page unload.

[jan-ivar]

To be addressed by PR in #2516