[jitsi-dev] JitstMeet bombing out clients


#1

Hi again!

I really appreciate you guys taking the time to look into these
issues. Really helpful for us to solve these problems.

So far, I have built a small, play-only, very simplified demo of what
i am seeing:

https://github.com/novikovmaa/jitsi-webrtc-player/blob/master/app.js

being launched in Electron, it attempts to establish 10 connections to
the room, not even playing what is being transmitted, joining just for
video. when a room is joined, it waits 5 s and initiates the next
connection, until the number reaches 10.

observations:

1) some of these users bomb out before they manage to join, about 6 to
8 manage to get made
2) 'got remote track' counter typically reaches about 90-95, probably
indicating remote track from every client that didn't bomb out before
the last one was connected. while i expect each client to get just 1
(from the presenter - which is running as a separate app), so total 10
of them. Or maybe max 20 because there is also sound.

execution log attached.

Do any of you guys have any Idea what am i doing wrong?

If you could give me any insight i'd be really helpful
:slightly_smiling_face:, also if needed i can make a similarly
small-and-dumb example of the app which does streaming itself
(presenter), while it is straightforward and unlikely can be source of
a problem. I think problem lies either in my Jitsi server
configuration, or this client player code.

Thanks again!

Mikhail

log.txt (172 KB)

···

Hi!

So far at anything over 40 participants in a room, it disconnects
participants faster than i am able to add new ones. They just randomly
disconnect.


#2

Hello again!

Some new data in:

Yeah, now i am certain these are 'each to each' connection attempts,
because if i see inside of track events, they are camera video tracks
from each of the clients (and also legit camera and audio from a
presenter). When a new client joins, all previously joined ones get a
video track from it. Obviously video is not really existing, because
these clients are not sharing anything as you can see, and yet these
events come through. It is easy to see how this overwhelm server when
there are 40-50 clients, and easy to see how it overwhelms browser for
even 10 clients.

Is there anything i can or shall do about it? Like, disable sending
these nonexistent tracks.
Is this the reason why large numbers of connections in one room are
unstable, or is there some other bug you see in this log or in my
code?

Apart from this, everything we need to see from Jitsi is working super
great, we are getting quality of both video and audio which we could
never get with Flash-based solutions, and i speak as a guy who did
whole lot of Flash-based video solutions over many years. Especially
lack of any audible audio delay feels great, surprisingly good given
it is not-p2p. Resolving this is the final problem we are facing
before we can go serving real users...

Thanks a lot for your help,

Mikhail

log2.log (180 KB)

···

On Tue, May 24, 2016 at 4:10 PM, Mikhail Novikov <novikovmaa@gmail.com> wrote:

Hi again!

I really appreciate you guys taking the time to look into these
issues. Really helpful for us to solve these problems.

So far, I have built a small, play-only, very simplified demo of what
i am seeing:

https://github.com/novikovmaa/jitsi-webrtc-player/blob/master/app.js

being launched in Electron, it attempts to establish 10 connections to
the room, not even playing what is being transmitted, joining just for
video. when a room is joined, it waits 5 s and initiates the next
connection, until the number reaches 10.

observations:

1) some of these users bomb out before they manage to join, about 6 to
8 manage to get made
2) 'got remote track' counter typically reaches about 90-95, probably
indicating remote track from every client that didn't bomb out before
the last one was connected. while i expect each client to get just 1
(from the presenter - which is running as a separate app), so total 10
of them. Or maybe max 20 because there is also sound.

execution log attached.

Do any of you guys have any Idea what am i doing wrong?

If you could give me any insight i'd be really helpful
:slightly_smiling_face:, also if needed i can make a similarly
small-and-dumb example of the app which does streaming itself
(presenter), while it is straightforward and unlikely can be source of
a problem. I think problem lies either in my Jitsi server
configuration, or this client player code.

Thanks again!

Mikhail

Hi!

So far at anything over 40 participants in a room, it disconnects
participants faster than i am able to add new ones. They just randomly
disconnect.


#3

Yet smaller update: we just tried with another team member to test
same app on 2 computers. And yes, both clients get "remote track"
events from both, so it is not because of use of same Jitsi Meet SDK
instance or anything like that, and the machines had different
physical IPs so not because of that too. Careful examination of docs
did not reveal anything which would look like connecting everyone to
everyone.

So we need to somehow turn this off. Looking at thread count, it looks
like every such connection spawns a thread, so 1000 clients will mean
a million threads which is clearly impossible. Also, even getting
events from 1000 people, and definitely some of them joining and
leaving as the broadcast is happening, to each of those people will
itself be a significant load for the clients.

And of course, we need to know if this is the reason why some clients
are being randomly disconnected/fail to connect, or some other one?
This is how disconnections look like:

[/modules\statistics\RTPStatsCollector.js]
<StatsCollector.processStatsReport>: 2183934099 not enough data
[/modules\statistics\RTPStatsCollector.js]
<StatsCollector.processStatsReport>: 2942143975 not enough data
[/modules\statistics\RTPStatsCollector.js]
<StatsCollector.processStatsReport>: 2183934099 not enough data
[/modules\xmpp\xmpp.js] <XMPP.connectionHandler>: (TIME) Strophe
CONNECTING: 41950.845
[/modules\xmpp\strophe.ping.js] <>: Ping timeout null
[/modules\xmpp\strophe.ping.js] <>: Ping timeout null
[/modules\xmpp\strophe.ping.js] <>: Ping timeout null
[/modules\xmpp\strophe.ping.js] <>: Ping timeout null
[/modules\xmpp\strophe.ping.js] <>: Ping timeout null
[/modules\xmpp\strophe.ping.js] <>: Ping timeout null
[/modules\xmpp\strophe.ping.js] <>: Ping timeout null
[/modules\xmpp\strophe.ping.js] <>: Ping timeout null
[/modules\xmpp\strophe.ping.js] <>: Ping timeout null
[/modules\xmpp\strophe.ping.js] <>: Ping timeout null
[/modules\xmpp\strophe.ping.js] <>: Ping timeout null
[/modules\xmpp\strophe.ping.js] <>: Ping timeout null
[/modules\xmpp\strophe.ping.js] <>: Ping timeout null
[/modules\xmpp\xmpp.js] <XMPP.connectionHandler>: (TIME) Strophe
DISCONNECTING: 74716.74500000001
[/modules\xmpp\strophe.ping.js] <>: Ping timeout null
[/modules\xmpp\xmpp.js] <XMPP.connectionHandler>: (TIME) Strophe
DISCONNECTING: 75127.785
[/modules\xmpp\xmpp.js] <XMPP.connectionHandler>: (TIME) Strophe
DISCONNECTED: 77825.77
[/modules\xmpp\strophe.ping.js]
<Object.Strophe.addConnectionPlugin.stopInterval>: Ping interval
cleared
disconnected
[/modules\xmpp\xmpp.js] <XMPP.connectionHandler>: (TIME) Strophe
DISCONNECTED: 78221.01000000001
[/modules\xmpp\strophe.ping.js]
<Object.Strophe.addConnectionPlugin.stopInterval>: Ping interval
cleared
disconnected

"disconnected" is printed in handler to
JitsiMeetJS.events.connection.CONNECTION_DISCONNECTED event

I will be very grateful for any advice which can shed light on this
matter. Me and Arian, the other developer, spent quite some time
verifying each other's code and so far we can't see anything which
could be the reason for each-to-each remote tracks and the
disconnections...

Thanks in advance,

Mikhail


#4

Hey Mikhail,

There are basically two ways you can try to resolve this.

1st: try not to create tracks anywhere but on the sending agent. All receivers start without tracks.

2nd: this whole setup is a very corner case for meet so I am not sure you are actually benefiting that much from using it (and you definitely are getting a lot of things that you wouldn't use). So you might also want to go and only take the bridge, then setup your channels using REST. You can have a look at how this works here (I just added a complete example the Brian Baldino sent to me a couple of weeks ago. Thanks Brian!):
https://github.com/jitsi/jitsi-videobridge/blob/master/doc/rest-videobridge.md

You may still end up using XMPP for connecting new participants ... or you may end up doing this a completely different way, but that's a separate choice

Emil

···

On 24.05.16 г. 10:57, Mikhail Novikov wrote:

Yet smaller update: we just tried with another team member to test
same app on 2 computers. And yes, both clients get "remote track"
events from both, so it is not because of use of same Jitsi Meet SDK
instance or anything like that, and the machines had different
physical IPs so not because of that too. Careful examination of docs
did not reveal anything which would look like connecting everyone to
everyone.

So we need to somehow turn this off. Looking at thread count, it looks
like every such connection spawns a thread, so 1000 clients will mean
a million threads which is clearly impossible. Also, even getting
events from 1000 people, and definitely some of them joining and
leaving as the broadcast is happening, to each of those people will
itself be a significant load for the clients.

And of course, we need to know if this is the reason why some clients
are being randomly disconnected/fail to connect, or some other one?
This is how disconnections look like:

[/modules\statistics\RTPStatsCollector.js]
<StatsCollector.processStatsReport>: 2183934099 not enough data
[/modules\statistics\RTPStatsCollector.js]
<StatsCollector.processStatsReport>: 2942143975 not enough data
[/modules\statistics\RTPStatsCollector.js]
<StatsCollector.processStatsReport>: 2183934099 not enough data
[/modules\xmpp\xmpp.js] <XMPP.connectionHandler>: (TIME) Strophe
CONNECTING: 41950.845
[/modules\xmpp\strophe.ping.js] <>: Ping timeout null
[/modules\xmpp\xmpp.js] <XMPP.connectionHandler>: (TIME) Strophe
DISCONNECTING: 74716.74500000001
[/modules\xmpp\strophe.ping.js] <>: Ping timeout null
[/modules\xmpp\xmpp.js] <XMPP.connectionHandler>: (TIME) Strophe
DISCONNECTING: 75127.785
[/modules\xmpp\xmpp.js] <XMPP.connectionHandler>: (TIME) Strophe
DISCONNECTED: 77825.77
[/modules\xmpp\strophe.ping.js]
<Object.Strophe.addConnectionPlugin.stopInterval>: Ping interval
cleared
disconnected
[/modules\xmpp\xmpp.js] <XMPP.connectionHandler>: (TIME) Strophe
DISCONNECTED: 78221.01000000001
[/modules\xmpp\strophe.ping.js]
<Object.Strophe.addConnectionPlugin.stopInterval>: Ping interval
cleared
disconnected

"disconnected" is printed in handler to
JitsiMeetJS.events.connection.CONNECTION_DISCONNECTED event

I will be very grateful for any advice which can shed light on this
matter. Me and Arian, the other developer, spent quite some time
verifying each other's code and so far we can't see anything which
could be the reason for each-to-each remote tracks and the
disconnections...

Thanks in advance,

Mikhail

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

--
https://jitsi.org


#5

Thanks!

1) "try not to create tracks anywhere but on the sending agent" -
How? See https://github.com/novikovmaa/jitsi-webrtc-player/blob/master/app.js
- i don't (explicitly) create any local tracks at all. Maybe they are
implicitly created by lib-jitsi-meet? If so, how do i turn them off?

2) I had that idea - using JVB without Meet, but didn't know where to
start. I will give it a try if (1) doesn't work.

Thank you again,

Mikhail

···

On Tue, May 24, 2016 at 10:51 PM, Emil Ivov <emcho@jitsi.org> wrote:

Hey Mikhail,

There are basically two ways you can try to resolve this.

1st: try not to create tracks anywhere but on the sending agent. All
receivers start without tracks.

2nd: this whole setup is a very corner case for meet so I am not sure you
are actually benefiting that much from using it (and you definitely are
getting a lot of things that you wouldn't use). So you might also want to go
and only take the bridge, then setup your channels using REST. You can have
a look at how this works here (I just added a complete example the Brian
Baldino sent to me a couple of weeks ago. Thanks Brian!):
https://github.com/jitsi/jitsi-videobridge/blob/master/doc/rest-videobridge.md

You may still end up using XMPP for connecting new participants ... or you
may end up doing this a completely different way, but that's a separate
choice

Emil

On 24.05.16 г. 10:57, Mikhail Novikov wrote:

Yet smaller update: we just tried with another team member to test
same app on 2 computers. And yes, both clients get "remote track"
events from both, so it is not because of use of same Jitsi Meet SDK
instance or anything like that, and the machines had different
physical IPs so not because of that too. Careful examination of docs
did not reveal anything which would look like connecting everyone to
everyone.

So we need to somehow turn this off. Looking at thread count, it looks
like every such connection spawns a thread, so 1000 clients will mean
a million threads which is clearly impossible. Also, even getting
events from 1000 people, and definitely some of them joining and
leaving as the broadcast is happening, to each of those people will
itself be a significant load for the clients.

And of course, we need to know if this is the reason why some clients
are being randomly disconnected/fail to connect, or some other one?
This is how disconnections look like:

[/modules\statistics\RTPStatsCollector.js]
<StatsCollector.processStatsReport>: 2183934099 not enough data
[/modules\statistics\RTPStatsCollector.js]
<StatsCollector.processStatsReport>: 2942143975 not enough data
[/modules\statistics\RTPStatsCollector.js]
<StatsCollector.processStatsReport>: 2183934099 not enough data
[/modules\xmpp\xmpp.js] <XMPP.connectionHandler>: (TIME) Strophe
CONNECTING: 41950.845
[/modules\xmpp\strophe.ping.js] <>: Ping timeout null
[/modules\xmpp\strophe.ping.js] <>: Ping timeout null
[/modules\xmpp\strophe.ping.js] <>: Ping timeout null
[/modules\xmpp\strophe.ping.js] <>: Ping timeout null
[/modules\xmpp\strophe.ping.js] <>: Ping timeout null
[/modules\xmpp\strophe.ping.js] <>: Ping timeout null
[/modules\xmpp\strophe.ping.js] <>: Ping timeout null
[/modules\xmpp\strophe.ping.js] <>: Ping timeout null
[/modules\xmpp\strophe.ping.js] <>: Ping timeout null
[/modules\xmpp\strophe.ping.js] <>: Ping timeout null
[/modules\xmpp\strophe.ping.js] <>: Ping timeout null
[/modules\xmpp\strophe.ping.js] <>: Ping timeout null
[/modules\xmpp\strophe.ping.js] <>: Ping timeout null
[/modules\xmpp\xmpp.js] <XMPP.connectionHandler>: (TIME) Strophe
DISCONNECTING: 74716.74500000001
[/modules\xmpp\strophe.ping.js] <>: Ping timeout null
[/modules\xmpp\xmpp.js] <XMPP.connectionHandler>: (TIME) Strophe
DISCONNECTING: 75127.785
[/modules\xmpp\xmpp.js] <XMPP.connectionHandler>: (TIME) Strophe
DISCONNECTED: 77825.77
[/modules\xmpp\strophe.ping.js]
<Object.Strophe.addConnectionPlugin.stopInterval>: Ping interval
cleared
disconnected
[/modules\xmpp\xmpp.js] <XMPP.connectionHandler>: (TIME) Strophe
DISCONNECTED: 78221.01000000001
[/modules\xmpp\strophe.ping.js]
<Object.Strophe.addConnectionPlugin.stopInterval>: Ping interval
cleared
disconnected

"disconnected" is printed in handler to
JitsiMeetJS.events.connection.CONNECTION_DISCONNECTED event

I will be very grateful for any advice which can shed light on this
matter. Me and Arian, the other developer, spent quite some time
verifying each other's code and so far we can't see anything which
could be the reason for each-to-each remote tracks and the
disconnections...

Thanks in advance,

Mikhail

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

--
https://jitsi.org

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


#6

Thanks!

1) "try not to create tracks anywhere but on the sending agent" -
How? See https://github.com/novikovmaa/jitsi-webrtc-player/blob/master/app.js
- i don't (explicitly) create any local tracks at all. Maybe they are
implicitly created by lib-jitsi-meet? If so, how do i turn them off?

2) I had that idea - using JVB without Meet, but didn't know where to
start. I will give it a try if (1) doesn't work.

The link that I posted below contains a complete example of a conference establishment over REST. That's a great place to start

Emil

···

On 24.05.16 г. 15:00, Mikhail Novikov wrote:

Thank you again,

Mikhail

On Tue, May 24, 2016 at 10:51 PM, Emil Ivov <emcho@jitsi.org> wrote:

Hey Mikhail,

There are basically two ways you can try to resolve this.

1st: try not to create tracks anywhere but on the sending agent. All
receivers start without tracks.

2nd: this whole setup is a very corner case for meet so I am not sure you
are actually benefiting that much from using it (and you definitely are
getting a lot of things that you wouldn't use). So you might also want to go
and only take the bridge, then setup your channels using REST. You can have
a look at how this works here (I just added a complete example the Brian
Baldino sent to me a couple of weeks ago. Thanks Brian!):
https://github.com/jitsi/jitsi-videobridge/blob/master/doc/rest-videobridge.md

You may still end up using XMPP for connecting new participants ... or you
may end up doing this a completely different way, but that's a separate
choice

Emil

On 24.05.16 г. 10:57, Mikhail Novikov wrote:

Yet smaller update: we just tried with another team member to test
same app on 2 computers. And yes, both clients get "remote track"
events from both, so it is not because of use of same Jitsi Meet SDK
instance or anything like that, and the machines had different
physical IPs so not because of that too. Careful examination of docs
did not reveal anything which would look like connecting everyone to
everyone.

So we need to somehow turn this off. Looking at thread count, it looks
like every such connection spawns a thread, so 1000 clients will mean
a million threads which is clearly impossible. Also, even getting
events from 1000 people, and definitely some of them joining and
leaving as the broadcast is happening, to each of those people will
itself be a significant load for the clients.

And of course, we need to know if this is the reason why some clients
are being randomly disconnected/fail to connect, or some other one?
This is how disconnections look like:

[/modules\statistics\RTPStatsCollector.js]
<StatsCollector.processStatsReport>: 2183934099 not enough data
[/modules\statistics\RTPStatsCollector.js]
<StatsCollector.processStatsReport>: 2942143975 not enough data
[/modules\statistics\RTPStatsCollector.js]
<StatsCollector.processStatsReport>: 2183934099 not enough data
[/modules\xmpp\xmpp.js] <XMPP.connectionHandler>: (TIME) Strophe
CONNECTING: 41950.845
[/modules\xmpp\strophe.ping.js] <>: Ping timeout null
[/modules\xmpp\xmpp.js] <XMPP.connectionHandler>: (TIME) Strophe
DISCONNECTING: 74716.74500000001
[/modules\xmpp\strophe.ping.js] <>: Ping timeout null
[/modules\xmpp\xmpp.js] <XMPP.connectionHandler>: (TIME) Strophe
DISCONNECTING: 75127.785
[/modules\xmpp\xmpp.js] <XMPP.connectionHandler>: (TIME) Strophe
DISCONNECTED: 77825.77
[/modules\xmpp\strophe.ping.js]
<Object.Strophe.addConnectionPlugin.stopInterval>: Ping interval
cleared
disconnected
[/modules\xmpp\xmpp.js] <XMPP.connectionHandler>: (TIME) Strophe
DISCONNECTED: 78221.01000000001
[/modules\xmpp\strophe.ping.js]
<Object.Strophe.addConnectionPlugin.stopInterval>: Ping interval
cleared
disconnected

"disconnected" is printed in handler to
JitsiMeetJS.events.connection.CONNECTION_DISCONNECTED event

I will be very grateful for any advice which can shed light on this
matter. Me and Arian, the other developer, spent quite some time
verifying each other's code and so far we can't see anything which
could be the reason for each-to-each remote tracks and the
disconnections...

Thanks in advance,

Mikhail

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

--
https://jitsi.org

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

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

--
https://jitsi.org


#7

Hi Mikhail,

About 1):
Have you tried with the latest version of lib-jitsi-meet? We fixed an issue
a couple of days ago that may cause the problem with the remote tracks that
you are describing. I've just tested with our doc/example/example.js to
comment createLocalTracks function calls and I had 2 participants in a call
without any tracks.

Regards,
Hristo.

···

On Tue, May 24, 2016 at 3:00 PM, Mikhail Novikov <novikovmaa@gmail.com> wrote:

Thanks!

1) "try not to create tracks anywhere but on the sending agent" -
How? See
https://github.com/novikovmaa/jitsi-webrtc-player/blob/master/app.js
- i don't (explicitly) create any local tracks at all. Maybe they are
implicitly created by lib-jitsi-meet? If so, how do i turn them off?

2) I had that idea - using JVB without Meet, but didn't know where to
start. I will give it a try if (1) doesn't work.

Thank you again,

Mikhail

On Tue, May 24, 2016 at 10:51 PM, Emil Ivov <emcho@jitsi.org> wrote:
> Hey Mikhail,
>
> There are basically two ways you can try to resolve this.
>
> 1st: try not to create tracks anywhere but on the sending agent. All
> receivers start without tracks.
>
> 2nd: this whole setup is a very corner case for meet so I am not sure you
> are actually benefiting that much from using it (and you definitely are
> getting a lot of things that you wouldn't use). So you might also want
to go
> and only take the bridge, then setup your channels using REST. You can
have
> a look at how this works here (I just added a complete example the Brian
> Baldino sent to me a couple of weeks ago. Thanks Brian!):
>
https://github.com/jitsi/jitsi-videobridge/blob/master/doc/rest-videobridge.md
>
> You may still end up using XMPP for connecting new participants ... or
you
> may end up doing this a completely different way, but that's a separate
> choice
>
> Emil
>
>
> On 24.05.16 г. 10:57, Mikhail Novikov wrote:
>>
>> Yet smaller update: we just tried with another team member to test
>> same app on 2 computers. And yes, both clients get "remote track"
>> events from both, so it is not because of use of same Jitsi Meet SDK
>> instance or anything like that, and the machines had different
>> physical IPs so not because of that too. Careful examination of docs
>> did not reveal anything which would look like connecting everyone to
>> everyone.
>>
>> So we need to somehow turn this off. Looking at thread count, it looks
>> like every such connection spawns a thread, so 1000 clients will mean
>> a million threads which is clearly impossible. Also, even getting
>> events from 1000 people, and definitely some of them joining and
>> leaving as the broadcast is happening, to each of those people will
>> itself be a significant load for the clients.
>>
>> And of course, we need to know if this is the reason why some clients
>> are being randomly disconnected/fail to connect, or some other one?
>> This is how disconnections look like:
>>
>> [/modules\statistics\RTPStatsCollector.js]
>> <StatsCollector.processStatsReport>: 2183934099 not enough data
>> [/modules\statistics\RTPStatsCollector.js]
>> <StatsCollector.processStatsReport>: 2942143975 not enough data
>> [/modules\statistics\RTPStatsCollector.js]
>> <StatsCollector.processStatsReport>: 2183934099 not enough data
>> [/modules\xmpp\xmpp.js] <XMPP.connectionHandler>: (TIME) Strophe
>> CONNECTING: 41950.845
>> [/modules\xmpp\strophe.ping.js] <>: Ping timeout null
>> [/modules\xmpp\strophe.ping.js] <>: Ping timeout null
>> [/modules\xmpp\strophe.ping.js] <>: Ping timeout null
>> [/modules\xmpp\strophe.ping.js] <>: Ping timeout null
>> [/modules\xmpp\strophe.ping.js] <>: Ping timeout null
>> [/modules\xmpp\strophe.ping.js] <>: Ping timeout null
>> [/modules\xmpp\strophe.ping.js] <>: Ping timeout null
>> [/modules\xmpp\strophe.ping.js] <>: Ping timeout null
>> [/modules\xmpp\strophe.ping.js] <>: Ping timeout null
>> [/modules\xmpp\strophe.ping.js] <>: Ping timeout null
>> [/modules\xmpp\strophe.ping.js] <>: Ping timeout null
>> [/modules\xmpp\strophe.ping.js] <>: Ping timeout null
>> [/modules\xmpp\strophe.ping.js] <>: Ping timeout null
>> [/modules\xmpp\xmpp.js] <XMPP.connectionHandler>: (TIME) Strophe
>> DISCONNECTING: 74716.74500000001
>> [/modules\xmpp\strophe.ping.js] <>: Ping timeout null
>> [/modules\xmpp\xmpp.js] <XMPP.connectionHandler>: (TIME) Strophe
>> DISCONNECTING: 75127.785
>> [/modules\xmpp\xmpp.js] <XMPP.connectionHandler>: (TIME) Strophe
>> DISCONNECTED: 77825.77
>> [/modules\xmpp\strophe.ping.js]
>> <Object.Strophe.addConnectionPlugin.stopInterval>: Ping interval
>> cleared
>> disconnected
>> [/modules\xmpp\xmpp.js] <XMPP.connectionHandler>: (TIME) Strophe
>> DISCONNECTED: 78221.01000000001
>> [/modules\xmpp\strophe.ping.js]
>> <Object.Strophe.addConnectionPlugin.stopInterval>: Ping interval
>> cleared
>> disconnected
>>
>> "disconnected" is printed in handler to
>> JitsiMeetJS.events.connection.CONNECTION_DISCONNECTED event
>>
>> I will be very grateful for any advice which can shed light on this
>> matter. Me and Arian, the other developer, spent quite some time
>> verifying each other's code and so far we can't see anything which
>> could be the reason for each-to-each remote tracks and the
>> disconnections...
>>
>> Thanks in advance,
>>
>> Mikhail
>>
>> _______________________________________________
>> dev mailing list
>> dev@jitsi.org
>> Unsubscribe instructions and other list options:
>> http://lists.jitsi.org/mailman/listinfo/dev
>>
>
> --
> https://jitsi.org
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev

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

--
Regards,
Hristo.


#8

Hi, i just did, and i see no change in behavior. Log attached, i see
95 remote tracks while i don't create any tracks in the viewer client
at all (see https://github.com/novikovmaa/jitsi-webrtc-player ), and
many of the clients are still disconnected by the server forcibly.
There is no way i can make even 10 clients work reliably.

It looks like i see either some problem with the Jitsi Meet itself, or
some deficiency in the documentation which prevents me to understand
something important. Is there a way i can have a (paid) teamviewer
session with some of you guys to get around the problems i am facing?
Or maybe you have a complete end-to-end code sample for my use case
(large number of viewers in 1 room and 1 broadcaster). Either using
Meet or JVB without Meet.

Thanks!

log.txt (161 KB)

···

Have you tried with the latest version of lib-jitsi-meet? We fixed an issue
a couple of days ago that may cause the problem with the remote tracks that
you are describing. I've just tested with our doc/example/example.js to
comment createLocalTracks function calls and I had 2 participants in a call
without any tracks.


#9

Hi, i just did, and i see no change in behavior. Log attached, i see
95 remote tracks while i don't create any tracks in the viewer client
at all (see https://github.com/novikovmaa/jitsi-webrtc-player ), and
many of the clients are still disconnected by the server forcibly.
There is no way i can make even 10 clients work reliably.

It looks like i see either some problem with the Jitsi Meet itself, or
some deficiency in the documentation which prevents me to understand
something important. Is there a way i can have a (paid) teamviewer
session with some of you guys to get around the problems i am facing?
Or maybe you have a complete end-to-end code sample for my use case
(large number of viewers in 1 room and 1 broadcaster). Either using
Meet or JVB without Meet.

No, we don't, because that's not a use case that meet was built for. Hence
my siggestion for using the bridge directly.

Emil

···

On Wednesday, 25 May 2016, Mikhail Novikov <novikovmaa@gmail.com> wrote:

Thanks!

> Have you tried with the latest version of lib-jitsi-meet? We fixed an
issue
> a couple of days ago that may cause the problem with the remote tracks
that
> you are describing. I've just tested with our doc/example/example.js to
> comment createLocalTracks function calls and I had 2 participants in a
call
> without any tracks.

--
sent from my mobile


#10

I have also tried changing channelLastN from -1 to 2 (as i have max 2
tracks from a presenter - video and audio) - and it didn't change
anything either.

···

On Wed, May 25, 2016 at 1:23 PM, Mikhail Novikov <novikovmaa@gmail.com> wrote:

Hi, i just did, and i see no change in behavior. Log attached, i see
95 remote tracks while i don't create any tracks in the viewer client
at all (see https://github.com/novikovmaa/jitsi-webrtc-player ), and
many of the clients are still disconnected by the server forcibly.
There is no way i can make even 10 clients work reliably.

It looks like i see either some problem with the Jitsi Meet itself, or
some deficiency in the documentation which prevents me to understand
something important. Is there a way i can have a (paid) teamviewer
session with some of you guys to get around the problems i am facing?
Or maybe you have a complete end-to-end code sample for my use case
(large number of viewers in 1 room and 1 broadcaster). Either using
Meet or JVB without Meet.

Thanks!

Have you tried with the latest version of lib-jitsi-meet? We fixed an issue
a couple of days ago that may cause the problem with the remote tracks that
you are describing. I've just tested with our doc/example/example.js to
comment createLocalTracks function calls and I had 2 participants in a call
without any tracks.


#11

Even receive-only endpoint advertise an SSRC (used for RTCP reports), which in our system gets propagated to everyone and not just to the intended sender. This doesn't mean there is any media flow between receivers.

Boris

···

On 25/05/16 06:06, Mikhail Novikov wrote:

I have also tried changing channelLastN from -1 to 2 (as i have max 2
tracks from a presenter - video and audio) - and it didn't change
anything either.

On Wed, May 25, 2016 at 1:23 PM, Mikhail Novikov <novikovmaa@gmail.com> wrote:

Hi, i just did, and i see no change in behavior. Log attached, i see
95 remote tracks while i don't create any tracks in the viewer client
at all (see https://github.com/novikovmaa/jitsi-webrtc-player ), and
many of the clients are still disconnected by the server forcibly.
There is no way i can make even 10 clients work reliably.

It looks like i see either some problem with the Jitsi Meet itself, or
some deficiency in the documentation which prevents me to understand
something important. Is there a way i can have a (paid) teamviewer
session with some of you guys to get around the problems i am facing?
Or maybe you have a complete end-to-end code sample for my use case
(large number of viewers in 1 room and 1 broadcaster). Either using
Meet or JVB without Meet.

Thanks!

Have you tried with the latest version of lib-jitsi-meet? We fixed an issue
a couple of days ago that may cause the problem with the remote tracks that
you are describing. I've just tested with our doc/example/example.js to
comment createLocalTracks function calls and I had 2 participants in a call
without any tracks.

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


#12

OK. Any idea why the clients bomb out? see "disconnected" lines in my
log. I am not sure this is anyhow linked to the problem of 'fake
remote tracks', probably not.

Thanks

···

Even receive-only endpoint advertise an SSRC (used for RTCP reports), which
in our system gets propagated to everyone and not just to the intended
sender. This doesn't mean there is any media flow between receivers.


#13

No, I don't have any idea why they disconnect.

Boris

···

On 25/05/16 08:22, Mikhail Novikov wrote:

OK. Any idea why the clients bomb out? see "disconnected" lines in my
log. I am not sure this is anyhow linked to the problem of 'fake
remote tracks', probably not.


#14

What i am worrying about... the number of connections in my test have
been very low (only 11). So this is not a 'corner case' of Jitsi Meet
yet, a group video call of 11 people is okay, i am sure Jitsi Meet
easily supports that many. And yet i am losing connections. Arian did
a separate post here 4 days ago reporting some of his problems, it
seems like he is having exactly same problems as me: everything works
except sometimes the client disconnect without visible reason. Suppose
i will do my own logic, and don't use Meet, just invoking the REST API
of JVB (this is what i am researching now) - won't i get similar
problem?

Also do you have any sample code for streaming and receiving a stream
by using only JVB? Even having the doc you given a link to, it seems
like a long learning curve.

Thanks!

···

On Wed, May 25, 2016 at 4:30 PM, Boris Grozev <boris@jitsi.org> wrote:

On 25/05/16 08:22, Mikhail Novikov wrote:

OK. Any idea why the clients bomb out? see "disconnected" lines in my
log. I am not sure this is anyhow linked to the problem of 'fake
remote tracks', probably not.

No, I don't have any idea why they disconnect.

Boris

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


#15

What i am worrying about... the number of connections in my test have
been very low (only 11). So this is not a 'corner case' of Jitsi Meet

No but I suspect the way you test it might be.

yet, a group video call of 11 people is okay, i am sure Jitsi Meet
easily supports that many. And yet i am losing connections. Arian did
a separate post here 4 days ago reporting some of his problems, it
seems like he is having exactly same problems as me: everything works
except sometimes the client disconnect without visible reason. Suppose
i will do my own logic, and don't use Meet, just invoking the REST API
of JVB (this is what i am researching now) - won't i get similar
problem?

No, the disconnect you are getting is from the xmpp/web server and is not
related to the bridge.

Also do you have any sample code for streaming and receiving a stream
by using only JVB? Even having the doc you given a link to, it seems
like a long learning curve.

Give it a try. It's not that complicated.

Emil

···

On Wednesday, 25 May 2016, Mikhail Novikov <novikovmaa@gmail.com> wrote:

Thanks!

On Wed, May 25, 2016 at 4:30 PM, Boris Grozev <boris@jitsi.org > <javascript:;>> wrote:
> On 25/05/16 08:22, Mikhail Novikov wrote:
>>
>> OK. Any idea why the clients bomb out? see "disconnected" lines in my
>> log. I am not sure this is anyhow linked to the problem of 'fake
>> remote tracks', probably not.
>
>
> No, I don't have any idea why they disconnect.
>
> Boris
>
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org <javascript:;>
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev

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

--
sent from my mobile


#16

Also do you have any sample code for streaming and receiving a stream
by using only JVB? Even having the doc you given a link to, it seems
like a long learning curve.

Give it a try. It's not that complicated.

I am on it for a day and so far don't understand much. It looks too
complicated, i can't get the complete picture. Are you really sure
there is no sample code for it anywhere? Like 'connect with JVB and
send a videostream', 'connect with JVB and play a videostream someone
else streams'? Maybe contacts of anyone who did it and could help for
a fee?


#17

OK it is clear that there is no easy way to it. I found myself
painfully reverse-engineering lib-jitsi-meet to find out how it works
and what to remove to get where i want to be, but it may take
unpredictable amount of time, if work at all. Is there really nothing
of sample code to help me?

···

On Thu, May 26, 2016 at 4:11 PM, Mikhail Novikov <novikovmaa@gmail.com> wrote:

Also do you have any sample code for streaming and receiving a stream
by using only JVB? Even having the doc you given a link to, it seems
like a long learning curve.

Give it a try. It's not that complicated.

I am on it for a day and so far don't understand much. It looks too
complicated, i can't get the complete picture. Are you really sure
there is no sample code for it anywhere? Like 'connect with JVB and
send a videostream', 'connect with JVB and play a videostream someone
else streams'? Maybe contacts of anyone who did it and could help for
a fee?