call.on("close") not triggered

[alfonsograziano]

Hi, i have a p2p connection and when i do call.close(), on("close",...) is triggered only on the peer that calls che close function. How can i trigger both the peers? Thank's!

[protyze]

I can confirm the report of @LOKK3D. I have the same issue.

Description
Unexpected behaviour when closing a MedieConnection between two peers.

Steps to reproduce

1. Establish a MediaConnection between 2 peers
2. Execute "call.close()" on peer 1.
3. Listen to "close" and "error" events on peer 2.
4. Observe which events are triggered on peer 2 after step 2.

Expected Result
Peer 2 should receive a "close" event after peer 1 closed the call. An error event should not be fired.

Actual Result
Peer 2 received an "error" event: "Error: Connection to disconnected."

Is this intentional?

[cliqer]

So, how do we close the call?
MediaConnection.close does never gets fired.
Is this a bug? Any workarounds?

[MoradAbdelgaber]

same problem here . Listen to "close" and "error" events on peer 2. nothing happened if peer 1 close call !!

[cliqer]

@MoradAbdelgaber, just send a signal to destroy the peer through WebSocket.
No other way around it.

[AlvaroHerrero]

Same problem here

[albertogcatalan]

Same here!

[mactunechy]

And same here

[xtrars]

and same here

[mactunechy]

I found a way that worked for me, I'm using peerjs alongside socket.io, so when i kill the call by peer.close(), I then emit an event "close" via socket.io and the other peer will subscribe to that event with socket.on("close",()=>{})

[amanKumar689]

same problem here . Listen to "close" and "error" events on peer 2. nothing happened if peer 1 close call !!

yeah bro me same problem i think its a bug

[sbehrends]

I am seeing same unexpected behavior where call.on('close', () => {}) is not being called when call is dropped.
If it is useful I can provide some kind of Codepen or similar to replicate the issue

[YoussF]

Same issue here :)

[azlogs]

I have a workaround solution that I answered in stackoverflow
https://stackoverflow.com/questions/64651890/peerjs-close-video-call-not-firing-close-event/66518772#66518772

[rkhaslarov]

same issue...

[naonvl]

I have a workaround solution that I answered in stackoverflow
https://stackoverflow.com/questions/64651890/peerjs-close-video-call-not-firing-close-event/66518772#66518772

is there any workaround without websocket?

[chadwallacehart]

I use the public peerjs server. I was able to manually close the peerConnections by getting them from peer.connections. I noticed that the dataConnection close event still fires, so I wait for this and then close all open peerConnections:

function handlePeerDisconnect() {
  // manually close the peer connections
  for (let conns in peer.connections) {
    peer.connections[conns].forEach((conn, index, array) => {
      console.log(`closing ${conn.connectionId} peerConnection (${index + 1}/${array.length})`, conn.peerConnection);
      conn.peerConnection.close();

      // close it using peerjs methods
      if (conn.close)
        conn.close();
    });
  }
}

peer.on('connection', conn => {
    let call = peer.call(peerToCall, localStream);
   
    // peerjs bug prevents this from firing: https://github.com/peers/peerjs/issues/636
    call.on('close', () => {
        console.log("call close event");
        handlePeerDisconnect();
    });
}

    // this one works
    conn.on('close', () => {
        console.log("conn close event");
        handlePeerDisconnect();
    });
});

I also responded here: https://stackoverflow.com/questions/64651890/peerjs-close-video-call-not-firing-close-event/67404616#67404616

[wilsonfurtado2000]

I use the public peerjs server. I was able to manually close the peerConnections by getting them from peer.connections. I noticed that the dataConnection close event still fires, so I wait for this and then close all open peerConnections:

function handlePeerDisconnect() {
  // manually close the peer connections
  for (let conns in peer.connections) {
    peer.connections[conns].forEach((conn, index, array) => {
      console.log(`closing ${conn.connectionId} peerConnection (${index + 1}/${array.length})`, conn.peerConnection);
      conn.peerConnection.close();

      // close it using peerjs methods
      if (conn.close)
        conn.close();
    });
  }
}

peer.on('connection', conn => {
    let call = peer.call(peerToCall, localStream);
   
    // peerjs bug prevents this from firing: https://github.com/peers/peerjs/issues/636
    call.on('close', () => {
        console.log("call close event");
        handlePeerDisconnect();
    });
}

    // this one works
    conn.on('close', () => {
        console.log("conn close event");
        handlePeerDisconnect();
    });
});

I also responded here: https://stackoverflow.com/questions/64651890/peerjs-close-video-call-not-firing-close-event/67404616#67404616

what is the conn variable here ??
could you help me i am facing the same

[rodrigomarcell]

I use the public peerjs server. I was able to manually close the peerConnections by getting them from peer.connections. I noticed that the dataConnection close event still fires, so I wait for this and then close all open peerConnections:

function handlePeerDisconnect() {
  // manually close the peer connections
  for (let conns in peer.connections) {
    peer.connections[conns].forEach((conn, index, array) => {
      console.log(`closing ${conn.connectionId} peerConnection (${index + 1}/${array.length})`, conn.peerConnection);
      conn.peerConnection.close();

      // close it using peerjs methods
      if (conn.close)
        conn.close();
    });
  }
}

peer.on('connection', conn => {
    let call = peer.call(peerToCall, localStream);
   
    // peerjs bug prevents this from firing: https://github.com/peers/peerjs/issues/636
    call.on('close', () => {
        console.log("call close event");
        handlePeerDisconnect();
    });
}

    // this one works
    conn.on('close', () => {
        console.log("conn close event");
        handlePeerDisconnect();
    });
});

I also responded here: https://stackoverflow.com/questions/64651890/peerjs-close-video-call-not-firing-close-event/67404616#67404616

yeah but where you are getting the peer id from to close the current disconnected peer call?

[chadwallacehart]

@wilsonfurtado2000 - when you create a peer with new Peer(someId), the peer object keeps an array of all the connections you make. If I recall correctly, the connections are stored in some kind of generator object. You cann grab each of them individually - that is what the conn variable is in the handlePeerDisconnect function above. I had to do some inspectionn to find these.

@rodrigomarcell - in tht example I am closing every connection associted with the given peer. You should be able to close specific peers by ID with something like the below:

    function manualClose(TARGET_ID) {
        // close the peer connections
        for (let conns in peer.connections) {
            peer.connections[conns].forEach((conn, index, array) => {

                // Manually close the peerConnections b/c peerJs MediaConnect close not called bug: https://github.com/peers/peerjs/issues/636
                if (conn.peer === TARGET_ID) {
                    console.log(`closing ${conn.connectionId} peerConnection (${index + 1}/${array.length})`, conn.peerConnection);
                    conn.peerConnection.close();

                    // close it using peerjs methods
                    if (conn.close) {
                        conn.close();
                    }
                }
            });
        }
    }

[MaxPao]

Maybe I confuse this issue.
but I face this same problem, and I resolve it.

my project has 2 block script , one is [connect to], one is [listen connect]
if in those 2 way you set 'close' event .
then it can fired when other side to close event.

when I get this issue, I only write one side 'close' event....

[matallui]

Just encountered this same issue. Any progress on this?

[rodrigomarcell]

Just encountered this same issue. Any progress on this?

I guess the messages above may help you.

[matallui]

I understand there's workarounds for this. But any updates on whether this is going to be fixed? Looks like this issue has been open since 2020.

[matallui]

Not sure what the real fix for this will be, but I managed to get this working with this patch.

If you want to give it a try you should be able to install my patched version of peerjs:

npm i matallui/peerjs#fix_mediastream_close

The solution involved creating a RTCDataChannel for each MediaConnection, similar to what is done to the DataConnection. I still would love to figure out a cleaner way of doing that, but at least this is working for now.

[JoleMile]

Not sure what the real fix for this will be, but I managed to get this working with this patch.

If you want to give it a try you should be able to install my patched version of peerjs:

npm i matallui/peerjs#fix_mediastream_close

The solution involved creating a RTCDataChannel for each MediaConnection, similar to what is done to the DataConnection. I still would love to figure out a cleaner way of doing that, but at least this is working for now.

Not sure how this is working, but it seems to be working great. Thank you :)

[AllanPinheiroDeLima]

Not sure what the real fix for this will be, but I managed to get this working with this patch.

If you want to give it a try you should be able to install my patched version of peerjs:

npm i matallui/peerjs#fix_mediastream_close

The solution involved creating a RTCDataChannel for each MediaConnection, similar to what is done to the DataConnection. I still would love to figure out a cleaner way of doing that, but at least this is working for now.

I was about to make this myself. Why don't you open a pull request for them ? Your solution works great!
Thank you!

[matallui]

@AllanPinheiroDeLima I was just trying to make sure this is the correct solution. I assume at some point the remote close() functionality was working, so would like to understand why it stopped working. I was hoping to figure out a better way without having to create that extra channel. But I guess I can open a PR and go from there.

[matallui]

@jonasgloning just tested this and have a couple of comments:

1- this (kind of) fixes the issue but it's not good enough in my case... it's only disconnecting when we get the ICE disconnect event, which takes a few seconds after I actually stop the MediaConnection on the sharing side. With the extra DataChannel at least we get an instant disconnect as soon as one side calls MediaConnection.close(), which is the behavior I'd expect according to the docs.

2- I'm getting a TS build error now saying the MediaConnection.answer() requires a mandatory stream argument. Not sure at what point things have changed, but this used to be an optional argument and we could still answer calls without sharing a stream back. Any ideas what happened with that?

[matallui]

This commit seems to be where index.d.ts got removed and the interface for MediaConnection.answer() changed.

[jonasgloning]

Thanks for testing, @matallui!

1- this (kind of) fixes the issue but it's not good enough in my case... it's only disconnecting when we get the ICE disconnect event, which takes a few seconds after I actually stop the MediaConnection on the sharing side. With the extra DataChannel at least we get an instant disconnect as soon as one side calls MediaConnection.close(), which is the behavior I'd expect according to the docs.

You’re right, the delay is to large. So this isn’t a complete solution. Unfortunately, I won’t have the time to look into it the next few weeks. But I would merge a PR with your solution, at least in rc for further testing.

2- I'm getting a TS build error now saying the MediaConnection.answer() requires a mandatory stream argument. Not sure at what point things have changed, but this used to be an optional argument and we could still answer calls without sharing a stream back. Any ideas what happened with that?

There were some inconsistencies with the handwritten types, so I switched to autogenerating them in your linked commit. Turns out the types in the source weren’t accurate either. Fixed in 666dcd9, more type improvements 2b53de2.

[matallui]

@jonasgloning thanks for the prompt response and for fixing 2). I will submit a PR soon with my fixes for 1) so we can test it in RC and we'll go from there.

[matallui]

@jonasgloning PR submitted. Thanks again for all the help!

[alibawazeer611]

when i calling video the peer close by self why this happend'

[bioshazard]

Hello from 2023, I can't seem to get any on event to trigger when closing one of the peer tabs ungracefully.

[neilyoung]

Maybe I confuse this issue. but I face this same problem, and I resolve it.

my project has 2 block script , one is [connect to], one is [listen connect] if in those 2 way you set 'close' event . then it can fired when other side to close event.

when I get this issue, I only write one side 'close' event....

What?

[dugiwarc]

Yes, this still seems to be an issue, none of the 'on' events gets triggered. Only solution is to use web sockets for now.

[hayelom123]

Is it fixed?,or should I use just the webrtc

[neilyoung]

Is it fixed?,or should I use just the webrtc

I recommend https://github.com/feross/simple-peer

It's less buggy

[briannydegger]

I personally use something like:

this.conn = this.peer.call(this.anotherid, stream);

this.conn.on('iceStateChanged', (state) => {
    if (state === 'disconnected') {
        this.endCall();
    }
});

Just have to wait few seconds to have the result.

Best regards

[github-actions]

🎉 This issue has been resolved in version 1.5.0-rc.1 🎉

The release is available on:

• npm package (@rc dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[hayelom123]

Thanks, I'll check it out!

…

On Mon, 14 Aug 2023, 4:05 pm github-actions[bot], ***@***.***> wrote: 🎉 This issue has been resolved in version 1.5.0-rc.1 🎉 The release is available on: - npm package ***@***.*** dist-tag) <https://www.npmjs.com/package/peerjs/v/1.5.0-rc.1> - GitHub release <https://github.com/peers/peerjs/releases/tag/v1.5.0-rc.1> Your *semantic-release <https://github.com/semantic-release/semantic-release>* bot 📦🚀 — Reply to this email directly, view it on GitHub <#636 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQYO2F5SFKEPJYILR3ZXFYLXVIO73ANCNFSM4LSZVAAQ> . You are receiving this because you commented.Message ID: ***@***.***>

[jonasgloning]

I've published the update in version v1.5 on npm now.

---

I’m sorry it took so long. And I’m deeply sorry for the lack of communication on my part.

Despite the correctness of the patch, it didn't work consistently across different platforms and browsers on my end. I wanted to ensure its reliability, so I advanced a long-planned E2E test suite, but I significantly underestimated the time this would take me.

Months later, after setting everything up, the tests really did fail randomly. Both dde08f0 and 573d7d7, unrelated to the code of this PR, were necessary in the end – that was just a lucky guess. The code was fine all along, but there was a bug in the build process.

The test suite indicates the close events still aren’t consistently emitted on old Chrome versions. However, since they function well on modern versions and on Firefox, I'm attributing this to a browser bug.

I didn't have anything to update you with other than "blocked on something unrelated" and "should be working, isn’t for unknown reasons" and so I didn’t. However, I should have kept you updated regardless. I will strive to be better next time.