2

When I am trying to close the WebRTC connection after a call using rtc.close(), I recognize that about:webrtc-internals in Chrome and about:webrtc keep the connections listed. In Firefox, they are marked as closed, while in Chrome I could not see such a denotation.

I am asking because this seems to have a significant performance impact after some time. After having done a lot of calls, the performance is significantly impaired and webrtc-internals lists a large number of connections.

Is there anything more to closing a WebRTC connection than .close() to make the browser fully forget about the connection?

nexus
  • 150
  • 3
  • 13
  • https://stackoverflow.com/questions/63630821/webrtc-internals-calling-close-with-a-reference-to-null-does-not-erase-the-clos – GiantKs Aug 28 '20 at 09:26
  • https://stackoverflow.com/questions/63630821/webrtc-internals-calling-close-with-a-reference-to-null-does-not-erase-the-clos – GiantKs Aug 28 '20 at 09:29

1 Answers1

5

You should see the peer connection go to ICEConnectionStateClosed and SignalingStateClosed. One thing that you should do is ensure that you're stopping all local media stream tracks. If you don't, the browser will keep them open, because they aren't closed when a peer connection is closed.

pc closed

xdumaine
  • 10,096
  • 6
  • 62
  • 103
  • Thanks, but I still wonder: Even though all connections are supposed to be closed, Conn-Audio-1-0 still keeps being written in bold and "googActiveConnection" is true. Doesn't that mean that still some processing is taking place? – nexus Jan 13 '16 at 18:45
  • It's interesting you should say that, because I'm running into an issue where my peer connections aren't being closed properly either. I suspect this is either a chrome bug or a bug with a library that we may both happen to be using. I'll dig a little more. – xdumaine Jan 13 '16 at 19:13
  • In Firefox they are definitely closed. about:webrtc keeps snapshots around after close for debugging reasons. A "Clear" button is planned. – jib Jan 15 '16 at 03:17