1

This seems to be a quite common issue with Simple-peer. I have simple video chat app which connects 2 peers using WebRTC, Socket.io and Simple-peer. When I peer 1 calls Peer 2 for the first time, everything is fine. Same with 2nd call (so reconnection isn't an issue) but the 3rd time it throws an error

Uncaught Error: cannot signal after peer is destroyed

I'm not destroying the peer in my code either end i.e. no peer.destroy() being called either end.

My question is, if there are 2 users logged into the app. can they stay logged in and call each other repeatedly without having to refresh/reload the app?

Or is the Socket.id that's issued to each new user that needs refreshing before each call?

In other terms -- If 2 peers made a connection, had a video call and ended the call. Is there a way to reconstruct the peer object between the same 2 peers for a new call without refreshing/reloading the app?

Many thanks in advance. Sorry I haven't included the code because I thought its more of a concept question.

KiranM
  • 35
  • 4
  • Same here; any solutions? – Max Kachanov Apr 20 '22 at 14:09
  • 1
    You create a WebRTC Transport for each new subscription. If a user broadcasting closes themselves you close the transport and create a new one if they come back. You're limited to 500 transports per domain most browsers so be sure to fatal error if a user hasn't refreshed and has a crazy RTCPeerConnection list. – BGPHiJACK Apr 20 '22 at 22:26
  • 1
    So in your case just create a websocket server. User can request, create, close a transport at any time. Your front end will handle and close the streams and re-load new ones as they come. Issue if you keep transports open is sometimes they may not be needed any further so keep it clean. – BGPHiJACK Apr 20 '22 at 22:28
  • Thanks for the reply BGPHiJACK! I've some how managed to issue new socket.ID to each logged in user on hanging up from the video call, using UseEffect React hook. So when they call the same user again second or more time they're calling with a new Socket.id, hence new peer object is being created with each call. Also calling the peer.destroy() both ends when the user decides to end the call. Do yo reckon that'd be sufficient to clean up the residue transports once the call has ended? – KiranM Apr 21 '22 at 09:01
  • @ Max Kachanov -- Let me know if you're still stuck, I can show you how I managed to go around this issue. Not sure its the best solution but don't get "cannot signal after peer is destroyed" error anymore. And 2 users can call each other repeatedly without having to reload the app or login again. – KiranM Apr 21 '22 at 09:03

0 Answers0