[jitsi-dev] Jitsi-meet and persistent JIDs


#1

Hey,

While debugging issues reported by Michael Diordiev I noticed something about our usage of JIDs and COLIBRI endpoint IDs, which leads to problems if the JIDs are persistent (e.g. if after a page refresh the MUC JID does not change).

In our regular use-case (e.g. anonymous XMPP auth, vanilla jitsi-meet code, config.useNicks=false (whatever that is)) we get a randomly generated username from the XMPP server, and we use part of it as our MUC JID:

My Jabber ID: deadbeef-030a-4a9f-92a2-3d4847900a36@domain/whatever
Joined MUC as conferencename@conference.domain/deadbeef

If the user refreshes the page, the server generates a new JID, this leads to a new MUC JID, and all is good. However if for some reason the client uses the same MUC JID (reuses "deadbeef") there are problems.
Jicofo uses the resource from the MUC JID ("deadbeef") in COLIBRI for endpoint-id and channel-bundle-id. In this case after a refresh jicofo will invite the participant as a new participant and (try to) allocate new COLIBRI channels using channel-bundle-id="deadbeef". If the "deadbeef" transport manager still exists in videobridge for some reason (as has been observed in log files), this causes a problem.

I don't know if the this happens when we use XMPP authentication (or other kinds of authentication). Pawel, what do you think?

In any case, I think we should address this. IIRC, endpoint-id's (and later channel-bundle-id's) we introduced as identifiers for, well, endpoints, and the (re-)use of the MUC JID resource was just for convenience. I suggest that we have jicofo generate a new unique identifier for each new participant and use it for endpoint-id and channel-bundle-id.

Any thoughts?

Regards,
Boris


#2

That channel should have been deallocated (expire=0) when the user left the room, no?

···

Am 29.05.2015 um 02:45 schrieb Paweł Domas:

Hi Boris,

On Fri, May 29, 2015 at 10:59 AM, Boris Grozev <boris@jitsi.org> wrote:

Hey,

While debugging issues reported by Michael Diordiev I noticed something
about our usage of JIDs and COLIBRI endpoint IDs, which leads to problems if
the JIDs are persistent (e.g. if after a page refresh the MUC JID does not
change).

In our regular use-case (e.g. anonymous XMPP auth, vanilla jitsi-meet code,
config.useNicks=false (whatever that is)) we get a randomly generated
username from the XMPP server, and we use part of it as our MUC JID:

My Jabber ID: deadbeef-030a-4a9f-92a2-3d4847900a36@domain/whatever
Joined MUC as conferencename@conference.domain/deadbeef

If the user refreshes the page, the server generates a new JID, this leads
to a new MUC JID, and all is good. However if for some reason the client
uses the same MUC JID (reuses "deadbeef") there are problems.
Jicofo uses the resource from the MUC JID ("deadbeef") in COLIBRI for
endpoint-id and channel-bundle-id. In this case after a refresh jicofo will
invite the participant as a new participant and (try to) allocate new
COLIBRI channels using channel-bundle-id="deadbeef". If the "deadbeef"
transport manager still exists in videobridge for some reason (as has been
observed in log files), this causes a problem.


#3

Hi Boris,

Hey,

While debugging issues reported by Michael Diordiev I noticed something
about our usage of JIDs and COLIBRI endpoint IDs, which leads to problems if
the JIDs are persistent (e.g. if after a page refresh the MUC JID does not
change).

In our regular use-case (e.g. anonymous XMPP auth, vanilla jitsi-meet code,
config.useNicks=false (whatever that is)) we get a randomly generated
username from the XMPP server, and we use part of it as our MUC JID:

My Jabber ID: deadbeef-030a-4a9f-92a2-3d4847900a36@domain/whatever
Joined MUC as conferencename@conference.domain/deadbeef

If the user refreshes the page, the server generates a new JID, this leads
to a new MUC JID, and all is good. However if for some reason the client
uses the same MUC JID (reuses "deadbeef") there are problems.
Jicofo uses the resource from the MUC JID ("deadbeef") in COLIBRI for
endpoint-id and channel-bundle-id. In this case after a refresh jicofo will
invite the participant as a new participant and (try to) allocate new
COLIBRI channels using channel-bundle-id="deadbeef". If the "deadbeef"
transport manager still exists in videobridge for some reason (as has been
observed in log files), this causes a problem.

I don't know if the this happens when we use XMPP authentication (or other
kinds of authentication). Pawel, what do you think?

Yes, I believe this will be the case for XMPP authentication.

In any case, I think we should address this. IIRC, endpoint-id's (and later
channel-bundle-id's) we introduced as identifiers for, well, endpoints, and
the (re-)use of the MUC JID resource was just for convenience. I suggest
that we have jicofo generate a new unique identifier for each new
participant and use it for endpoint-id and channel-bundle-id.

Any thoughts?

Yes, probably this will work and it's a good idea. Can you open an
issue for that ? I can take this task if you're ok with that.

Regards,
Pawel

···

On Fri, May 29, 2015 at 10:59 AM, Boris Grozev <boris@jitsi.org> wrote:


#4

Just a note that there is one known situation for me when this
transport manager may not be disposed and it was described here:

https://github.com/jitsi/jicofo/blob/master/src/org/jitsi/jicofo/JitsiMeetConference.java#L439

So we can either change endpoint allocation method to be unique or I
can try fixing this issue. Probably it may be better to have the issue
fixed.

Regards,
Pawel

···

On Fri, May 29, 2015 at 10:59 AM, Boris Grozev <boris@jitsi.org> wrote:

Hey,

While debugging issues reported by Michael Diordiev I noticed something
about our usage of JIDs and COLIBRI endpoint IDs, which leads to problems if
the JIDs are persistent (e.g. if after a page refresh the MUC JID does not
change).

In our regular use-case (e.g. anonymous XMPP auth, vanilla jitsi-meet code,
config.useNicks=false (whatever that is)) we get a randomly generated
username from the XMPP server, and we use part of it as our MUC JID:

My Jabber ID: deadbeef-030a-4a9f-92a2-3d4847900a36@domain/whatever
Joined MUC as conferencename@conference.domain/deadbeef

If the user refreshes the page, the server generates a new JID, this leads
to a new MUC JID, and all is good. However if for some reason the client
uses the same MUC JID (reuses "deadbeef") there are problems.
Jicofo uses the resource from the MUC JID ("deadbeef") in COLIBRI for
endpoint-id and channel-bundle-id. In this case after a refresh jicofo will
invite the participant as a new participant and (try to) allocate new
COLIBRI channels using channel-bundle-id="deadbeef". If the "deadbeef"
transport manager still exists in videobridge for some reason (as has been
observed in log files), this causes a problem.


#5

Sure! I honestly didn't know if this is the right solution, that's why I posted here. Issue created:
https://github.com/jitsi/jicofo/issues/17

Thanks, Pawel!

Regards,
Boris

···

On 29/05/15 12:45, Paweł Domas wrote:

Hi Boris,

On Fri, May 29, 2015 at 10:59 AM, Boris Grozev <boris@jitsi.org> wrote:

Hey,

While debugging issues reported by Michael Diordiev I noticed something
about our usage of JIDs and COLIBRI endpoint IDs, which leads to problems if
the JIDs are persistent (e.g. if after a page refresh the MUC JID does not
change).

In our regular use-case (e.g. anonymous XMPP auth, vanilla jitsi-meet code,
config.useNicks=false (whatever that is)) we get a randomly generated
username from the XMPP server, and we use part of it as our MUC JID:

My Jabber ID: deadbeef-030a-4a9f-92a2-3d4847900a36@domain/whatever
Joined MUC as conferencename@conference.domain/deadbeef

If the user refreshes the page, the server generates a new JID, this leads
to a new MUC JID, and all is good. However if for some reason the client
uses the same MUC JID (reuses "deadbeef") there are problems.
Jicofo uses the resource from the MUC JID ("deadbeef") in COLIBRI for
endpoint-id and channel-bundle-id. In this case after a refresh jicofo will
invite the participant as a new participant and (try to) allocate new
COLIBRI channels using channel-bundle-id="deadbeef". If the "deadbeef"
transport manager still exists in videobridge for some reason (as has been
observed in log files), this causes a problem.

I don't know if the this happens when we use XMPP authentication (or other
kinds of authentication). Pawel, what do you think?

Yes, I believe this will be the case for XMPP authentication.

In any case, I think we should address this. IIRC, endpoint-id's (and later
channel-bundle-id's) we introduced as identifiers for, well, endpoints, and
the (re-)use of the MUC JID resource was just for convenience. I suggest
that we have jicofo generate a new unique identifier for each new
participant and use it for endpoint-id and channel-bundle-id.

Any thoughts?

Yes, probably this will work and it's a good idea. Can you open an
issue for that ? I can take this task if you're ok with that.


#6

Hi Phillip,

···

On Fri, May 29, 2015 at 8:01 PM, Philipp Hancke <fippo@goodadvice.pages.de> wrote:

Am 29.05.2015 um 02:45 schrieb Paweł Domas:

Hi Boris,

On Fri, May 29, 2015 at 10:59 AM, Boris Grozev <boris@jitsi.org> wrote:

Hey,

While debugging issues reported by Michael Diordiev I noticed something
about our usage of JIDs and COLIBRI endpoint IDs, which leads to problems
if
the JIDs are persistent (e.g. if after a page refresh the MUC JID does
not
change).

In our regular use-case (e.g. anonymous XMPP auth, vanilla jitsi-meet
code,
config.useNicks=false (whatever that is)) we get a randomly generated
username from the XMPP server, and we use part of it as our MUC JID:

My Jabber ID: deadbeef-030a-4a9f-92a2-3d4847900a36@domain/whatever
Joined MUC as conferencename@conference.domain/deadbeef

If the user refreshes the page, the server generates a new JID, this
leads
to a new MUC JID, and all is good. However if for some reason the client
uses the same MUC JID (reuses "deadbeef") there are problems.
Jicofo uses the resource from the MUC JID ("deadbeef") in COLIBRI for
endpoint-id and channel-bundle-id. In this case after a refresh jicofo
will
invite the participant as a new participant and (try to) allocate new
COLIBRI channels using channel-bundle-id="deadbeef". If the "deadbeef"
transport manager still exists in videobridge for some reason (as has
been
observed in log files), this causes a problem.

That channel should have been deallocated (expire=0) when the user left the
room, no?

Yes, it is now deallocated.


#7

Hey, Paweł.

Thanks for the last commit of jicofo, it seems to solves that issue,
but it generates another one, now the dominant speaker is not
detected. Downgrading to jicofo 1.0-93-1 solves this.

Phillip, as I reported to Boris, sometimes window.unload is not
triggered, and [1] is not executed. As a result when this user enter
again the room he cannot be connected till the JVB terminates the
channel.

Regards,
Zalmoxisus

[1] https://github.com/jitsi/jitsi-meet/blob/master/modules/xmpp/xmpp.js#L193

···

On Fri, May 29, 2015 at 10:28 PM, Paweł Domas <pawel.domas@jitsi.org> wrote:

Hi Phillip,

On Fri, May 29, 2015 at 8:01 PM, Philipp Hancke > <fippo@goodadvice.pages.de> wrote:

Am 29.05.2015 um 02:45 schrieb Paweł Domas:

Hi Boris,

On Fri, May 29, 2015 at 10:59 AM, Boris Grozev <boris@jitsi.org> wrote:

Hey,

While debugging issues reported by Michael Diordiev I noticed something
about our usage of JIDs and COLIBRI endpoint IDs, which leads to problems
if
the JIDs are persistent (e.g. if after a page refresh the MUC JID does
not
change).

In our regular use-case (e.g. anonymous XMPP auth, vanilla jitsi-meet
code,
config.useNicks=false (whatever that is)) we get a randomly generated
username from the XMPP server, and we use part of it as our MUC JID:

My Jabber ID: deadbeef-030a-4a9f-92a2-3d4847900a36@domain/whatever
Joined MUC as conferencename@conference.domain/deadbeef

If the user refreshes the page, the server generates a new JID, this
leads
to a new MUC JID, and all is good. However if for some reason the client
uses the same MUC JID (reuses "deadbeef") there are problems.
Jicofo uses the resource from the MUC JID ("deadbeef") in COLIBRI for
endpoint-id and channel-bundle-id. In this case after a refresh jicofo
will
invite the participant as a new participant and (try to) allocate new
COLIBRI channels using channel-bundle-id="deadbeef". If the "deadbeef"
transport manager still exists in videobridge for some reason (as has
been
observed in log files), this causes a problem.

That channel should have been deallocated (expire=0) when the user left the
room, no?

Yes, it is now deallocated.

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#8

Phillip, as I reported to Boris, sometimes window.unload is not
triggered, and [1] is not executed. As a result when this user enter
again the room he cannot be connected till the JVB terminates the
channel.

Use websockets, they terminate better. BOSH is a hack which is not required in any browser supporting WebRTC.


#9

Hi Michael,

···

On Sat, May 30, 2015 at 1:08 PM, Michael Diordiev <zalmoxisus@gmail.com> wrote:

Hey, Paweł.

Thanks for the last commit of jicofo, it seems to solves that issue,
but it generates another one, now the dominant speaker is not
detected. Downgrading to jicofo 1.0-93-1 solves this.

Thanks for the report ! I had to revert the change and need to think
of improving current impl rather than new endpoint id generation
strategy.

Regards,
Pawel


#10

Indeed. Thanks, Philipp, that helped!

Regards,
Zalmoxisus

···

On Sun, May 31, 2015 at 10:41 AM, Philipp Hancke <fippo@goodadvice.pages.de> wrote:

Phillip, as I reported to Boris, sometimes window.unload is not
triggered, and [1] is not executed. As a result when this user enter
again the room he cannot be connected till the JVB terminates the
channel.

Use websockets, they terminate better. BOSH is a hack which is not required
in any browser supporting WebRTC.

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#11

Hi Paweł,

I see. Actually, just using websockets works for me, and I do not see
any disadvantages, so dev should take it into consideration.
Other solutions may cause having multiple instances of the same user
in one conference, which will not be good.

Regards,
Zalmoxisus

···

On Mon, Jun 1, 2015 at 9:24 AM, Paweł Domas <pawel.domas@jitsi.org> wrote:

Hi Michael,

On Sat, May 30, 2015 at 1:08 PM, Michael Diordiev <zalmoxisus@gmail.com> wrote:

Hey, Paweł.

Thanks for the last commit of jicofo, it seems to solves that issue,
but it generates another one, now the dominant speaker is not
detected. Downgrading to jicofo 1.0-93-1 solves this.

Thanks for the report ! I had to revert the change and need to think
of improving current impl rather than new endpoint id generation
strategy.

Regards,
Pawel

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev