So i have a two way call setup, one person creates the stream as publisher and subscribes to the stream as well so the other person can publish for a two way call.
When the second person disconnects from subscribing to the first publisher (for example leaves the page) i am not getting an event to the first publisher to say that the subscriber has left, this then causes issues because the first publisher is still subscribed to the second publisher’s stream which has now frozen.
I was expecting an event to come through to say the person they are subscribed to has disconnected from the session so it can be unsubscribed.
I see the following in the vidu server log
[INFO] 2022-07-19 11:07:57,237 [AbstractJsonRpcClientWebSocket-reqResEventExec-e2-t1061] io.openvidu.server.kurento.core.KurentoParticipantEndpointConfig - KMS event [MediaStateChangedEvent]: → endpoint: str_CAM_DukC_con_D5rzr63FOW (publisher) | oldState: CONNECTED | newState: DISCONNECTED | timestamp: 1658228877236
But the browser doesn’t get told about it.
Of course there are events for the behavior you are describing. In fact, knowing when a user has stopped publishing or has left the session is one of the most basic things you must take into account in your OpenVidu application. Please, take a look to the documentation more in depth. You have both streamDestroyed and connectionDestroyed events in openvidu-browser: SessionEventMap | OpenVidu Browser - v2.22.0
Except looking at the first publisher who starts the stream in the browser console o see no debug message from open vidu browser saying it received one of those events when the subscriber is gone
If you want an event stating “this user has unsubscribed from this stream”, generated by the user subscribing and reaching the user publishing: that does not exist.
Event streamDestroyed triggered by openvidu-browser only happens when the Publisher is destroyed, whatever the reason. This is what the documentation states: SessionEventMap | OpenVidu Browser - v2.22.0
But if the subscriber “is gone” (those are your own words), then all participants of the session will receive a connectionDestroyed event. If that event is not received, then your participant is not really gone, and is still connected to the session.
So then how do i handle where the second user leaves the page in the browser and the original publisher sees a frozen video because the subscriber just left? It doesn’t unsubscribe to it. Then if i try to come back on to the stream where the user had left, it then messes everything up and duplicates the stream on the original publisher end.
So here like this:
Publisher 1 - publishes a stream and subscribes to the subscriber video
Publisher 2 - Comes in from another location, makes their own publish to the same stream and subscribes to publisher 1
Now both are having a 2 way call.
Publisher 2 - closes the browser, or it crashes, whatever, their stream is now gone but on Publisher 1 side the video they subscribed to for publisher 2 now is frozen from the last frame before publisher 2 left. That subscription would need to be somehow destroyed and started with a fresh one waiting for the subscriber to come back.
What i’ve noticed in the situation in my last reply is that if the subscriber comes back and gets a new token from vidu, for some reason it duplicates the video elements on both sides.
If i saved the original token and used that to connect, would it connect the subscriber back to the original stream instead of duplicating it?
UPDATE
So this is an iOS issue again, same with the switching the camera track loses the sound input, when you leave the session on an iphone say to a different page on the browser, it doesn’t send the disconnected signal. It works fine on android and on mac safari, chome etc…but the iphone just doesn’t disconnect from the session when leaving the page
Update: So it seems this is an iOS issue, not an openvidu issue as such, although vidu does seem to ignore the fact the session vanished when it’s iOS.
What i did in the end was implement window:beforeunload and window:pagehide (for ios) and force the session to be closed.