Quick question about relationship of JitsiConnection and JitsiConference

We are building our own client using lib-jitsi-meet. Our use case involves users leaving one conference and joining another.
We’d assumed that we could keep the same JitsiConnection, call leave on the conference and then join another. Howeverm if we try that, while the client gets a CONFERENCE_JOINED event, it receives no other events. The JiCoFo log has
Expiring [conference user jid] channels - no RESULT for session-initiate

Are we doing something wrong or are just supposed to kill the connection too every time we need to switch conference?

This is how it is supposed to work. Reusing JitsiConnection should be fine. But as we do not have such use-case maybe we broke it at some point, if you find it we will be happy to review a PR, thanks.
As we already have some tests running the best will be to implement and tests for such cases so in the future we do not break it.
And the tests will serve as an example of how to use it in such cases. I suppose tests can run some simple xmpp server … just an idea :slight_smile:

Hi, I got a chance to have a look and have a better idea about what the problem might be.Unfortunately, I’m working off the minified file right now so debugging it is not easy.

In any case, the second time around, we get a session-initiate and the CALL_INCOMING event is emitted. However, it seems to still have the listeners from the previous conference attached, which are called first.
So, when it gets to onIncomingCall, this.room is null, it throws an error and never gets to the listeners of the current room.

In fact, I did have a quick look at the code, and I can’t see that the listener for this event is ever removed.

I imagine that should happen on the leave function? However, I’m not familiar enough with the code to do a PR, should I log it as a bug?

Hi, I got a chance to have a look and have a better idea about what the problem might be.Unfortunately, I’m working off the minified file right now so debugging it is not easy.

In any case, the second time around, we get a session-initiate and the CALL_INCOMING event is emitted. However, it seems to still have the listeners from the previous conference attached, which are called first.
So, when it gets to onIncomingCall, this.room is null, it throws an error and never gets to the listeners of the current room.

In fact, I did have a quick look at the code, and I can’t see that the listener for this event is ever removed.

I imagine that should happen on the leave function? However, I’m not familiar enough with the code to do a PR, should I log it as a bug?

P.S. Or am I missing something? I assumed we only have to call conference.leave but is there some way to remove the conference from the connection?

Maybe that is the bug with the listeners you had spotted, it needs more debugging the lib-jitsi-meet.

Looking at the code everything seems fine.
Listeners are removed on leave:


And new ones are added when new conference is being created: https://github.com/jitsi/lib-jitsi-meet/blob/2e1436e20d4d8fb6020497a87b2714dff38a6c86/JitsiConference.js#L235

This is really strange, I checked the code and, of course, you are right. I was originally looking at the minified file and the code is missing from there, even though I thought we had built it from that source code.

In fact, the code about _delayedIceFailed was also missing.

I just rebuilt it and the missing code is there. I suppose we must have copied over an older version of the file by accident though I can’t see where we could have got it from. We just downloaded the code, built it and haven’t touched it since.

Really sorry about the confusion.

Are you using a version from npmjs? We have never uploaded it there, and we had some discussions to remove the version that was uploaded years ago by someone … but those were stuck and nobody removed that version.
The best approach is to download the version from your deployment, the same way jitsi-meet is using it. The library is updated with the deployment, and follows the deployment changes.

I did not set our project up but am pretty certain that we are not using the npmjs version, we downloaded the project from git-hub and built/minified it locally. We are planning on doing what you suggest once we get all the moving pieces together.

The issue might also explain some other problems we’ve had, where the functionality doesn’t seem to quite match the documentation.

Like I said, it’s really strange, the minified version definitely did not match the code we built from, but now I did it again, it does. Again, sorry for the confusion.

No worries, glad we helped.