Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remote tracks removed instead of 'added' when the third user enter #689

Closed
nathando opened this issue Jan 17, 2018 · 12 comments
Closed

Remote tracks removed instead of 'added' when the third user enter #689

nathando opened this issue Jan 17, 2018 · 12 comments

Comments

@nathando
Copy link
Contributor

nathando commented Jan 17, 2018

Hi guys,

First, amazing work, thanks for the effort!
I am currently using lib-jitsi-meet to create my own customized UI.
There is some strange behavior:

The system work fine 2 person connected with video using token authentication. Once a third person joined, I received a TRACK_REMOVED event instead of a TRACK_ADDED even though the USER_JOINED event received.

And the TRACK_REMOVED was the existing track that is currently in the room.
It almost seems like there is a limit number of users that can join the room ?

Not sure if there is a simple max_users setting somewhere that I've missed ?

@saghul
Copy link
Member

saghul commented Jan 17, 2018

Do you have P2P enabled? I wonder if what you are seeing is the tracks being moved from the P2P connection onto the JVB connection, once the 3rd participant joins.

@nathando
Copy link
Contributor Author

@saghul Hi how do I check that ? Is it a server configuration or a client one ? Sorry I am still new on this.
I think it might be enabled because P2P appeared a lot in the console log

@saghul
Copy link
Member

saghul commented Jan 17, 2018

If you don't know, then it's enabled, because that's the default. Do you get a TRACK_ADDED immediately after?

@nathando
Copy link
Contributor Author

No I did not get the TRACK_ADDED at all

@saghul
Copy link
Member

saghul commented Jan 17, 2018

Any other error?

@nathando
Copy link
Contributor Author

nathando commented Jan 17, 2018

Okay here is what I've got in an existing connection

VidChatFullCtrl User joined 98d6792b e
Logger.js:125 [JitsiConference.js] <r._maybeStartOrStopP2P>:  P2P? isModerator: true, peerCount: 2 => false
angular.js:13424 VidChatFullCtrl On remote track removed t audio
angular.js:13424 VidChatFullCtrl Index and id of removed track 0 remote-trackscd312534
Logger.js:125 [modules/connectivity/ParticipantConnectionStatus.js] <e.value>:  Detector on remote track removed: cd312534
Logger.js:125 [modules/connectivity/ParticipantConnectionStatus.js] <e.value>:  Assuming connection active by JVB - no notification
Logger.js:125 [modules/connectivity/ParticipantConnectionStatus.js] <e.value>:  Figure out conn status for cd312534, is video muted: true is active(jvb): true video track frozen: false p2p mode: true is in last N: true currentStatus => newStatus: active => active
angular.js:13424 VidChatFullCtrl On remote track removed t video
Logger.js:125 [modules/RTC/TraceablePeerConnection.js] <r.trace>:  stop undefined
Logger.js:125 [modules/connectivity/ParticipantConnectionStatus.js] <e.value>:  Assuming connection active by JVB - no notification
Logger.js:125 [modules/connectivity/ParticipantConnectionStatus.js] <e.value>:  Figure out conn status for cd312534, is video muted: true is active(jvb): true video track frozen: false p2p mode: false is in last N: true currentStatus => newStatus: active => active
Logger.js:125 [modules/connectivity/ParticipantConnectionStatus.js] <e.value>:  Assuming connection active by JVB - no notification
Logger.js:125 [modules/connectivity/ParticipantConnectionStatus.js] <e.value>:  Figure out conn status for 98d6792b, is video muted: true is active(jvb): true video track frozen: false p2p mode: false is in last N: true currentStatus => newStatus: active => active
Logger.js:125 [modules/statistics/AvgRTPStatsReporter.js] <n._onP2PStatusChanged>:  Resetting average stats calculation
Logger.js:125 [modules/RTC/TraceablePeerConnection.js] <r.trace>:  oniceconnectionstatechange closed
Logger.js:125 [modules/RTC/TraceablePeerConnection.js] <r.trace>:  onsignalingstatechange closed

There is a warning at the end, not sure if this provide more info.

Logger.js:125 [modules/xmpp/strophe.jingle.js] <s.value>:  invalid session id <iq xmlns=​"jabber:​client" type=​"set" to=​"87837adc-e154-4bc8-b9f8-c06c6cd0fb5c@jitsi.mydomain.com/​5665f477-30fa-458d-ac2c-987875998d08" from=​"2kuoe1515595333@conference.jitsi.mydomain.com/​cd312534" id=​"xxxxtokenxxxx">​…​</iq>​
n @ Logger.js:125

@paweldomas
Copy link
Member

It must a problem with the JVB connection. Can you check for any errors in /var/log/jitsi/jvb.log ? Also Jicofo logs could be useful /var/log/jitsi/jicofo.log.

@nathando
Copy link
Contributor Author

@paweldomas
Nothing's special on jvb.log but there is exception on jicofo.log

jvb.log

JVB 2018-01-13 06:25:12.814 FINE: [126] org.jitsi.videobridge.xmpp.ComponentImpl.processIQ() (serving component 'JitsiVideobridge') Processing IQ (packetId 81u7v-175313): <iq id="81u7v-175313" type="result" to="jitsi-videobridge.jitsi.mydomain.com" from="jitsi.mydomain.com"/>
JVB 2018-01-13 06:25:12.814 FINE: [126] org.jitsi.videobridge.xmpp.ComponentImpl.log() RECV: <iq id="81u7v-175313" type="result" to="jitsi-videobridge.jitsi.mydomain.com" from="jitsi.mydomain.com"/>
JVB 2018-01-13 06:25:22.814 FINE: [127] org.jitsi.videobridge.xmpp.ComponentImpl.processIQ() (serving component 'JitsiVideobridge') Processing IQ (packetId 81u7v-175315): <iq id="81u7v-175315" type="result" to="jitsi-videobridge.jitsi.mydomain.com" from="jitsi.mydomain.com"/>
JVB 2018-01-13 06:25:22.814 FINE: [127] org.jitsi.videobridge.xmpp.ComponentImpl.log() RECV: <iq id="81u7v-175315" type="result" to="jitsi-videobridge.jitsi.mydomain.com" from="jitsi.mydomain.com"/>
JVB 2018-01-13 06:25:32.814 FINE: [128] org.jitsi.videobridge.xmpp.ComponentImpl.processIQ() (serving component 'JitsiVideobridge') Processing IQ (packetId 81u7v-175317): <iq id="81u7v-175317" type="result" to="jitsi-videobridge.jitsi.mydomain.com" from="jitsi.mydomain.com"/>
JVB 2018-01-13 06:25:32.814 FINE: [128] org.jitsi.videobridge.xmpp.ComponentImpl.log() RECV: <iq id="81u7v-175317" type="result" to="jitsi-videobridge.jitsi.mydomain.com" from="jitsi.mydomain.com"/>
JVB 2018-01-13 06:25:42.815 FINE: [129] org.jitsi.videobridge.xmpp.ComponentImpl.processIQ() (serving component 'JitsiVideobridge') Processing IQ (packetId 81u7v-175319): <iq id="81u7v-175319" type="result" to="jitsi-videobridge.jitsi.mydomain.com" from="jitsi.mydomain.com"/>
JVB 2018-01-13 06:25:42.815 FINE: [129] org.jitsi.videobridge.xmpp.ComponentImpl.log() RECV: <iq id="81u7v-175319" type="result" to="jitsi-videobridge.jitsi.mydomain.com" from="jitsi.mydomain.com"/>
JVB 2018-01-13 06:25:52.814 FINE: [130] org.jitsi.videobridge.xmpp.ComponentImpl.processIQ() (serving component 'JitsiVideobridge') Processing IQ (packetId 81u7v-175321): <iq id="81u7v-175321" type="result" to="jitsi-videobridge.jitsi.mydomain.com" from="jitsi.mydomain.com"/>

jicofo.log

JVB 2018-01-19 08:30:20.896 FINE: [167] org.jitsi.videobridge.xmpp.ComponentImpl.processIQ() (serving component 'JitsiVideobridge') Processing IQ (packetId 81u7v-280489): <iq id="81u7v-280489" type="result" to="jitsi-videobridge.jitsi.mydomain.com" from="jitsi.mydomain.com"/>
JVB 2018-01-19 08:30:20.896 FINE: [167] org.jitsi.videobridge.xmpp.ComponentImpl.log() RECV: <iq id="81u7v-280489" tJicofo 2018-01-19 06:25:12.914 SEVERE: [41] org.jitsi.impl.protocol.xmpp.XmppProtocolProvider.log() Failed to connect/login: No response received within reply timeout. Timeout was 15000ms (~15s). While waiting for establishing TLS
org.jivesoftware.smack.SmackException$NoResponseException: No response received within reply timeout. Timeout was 15000ms (~15s). While waiting for establishing TLS
        at org.jivesoftware.smack.SmackException$NoResponseException.newWith(SmackException.java:93)
        at org.jivesoftware.smack.SynchronizationPoint.checkForResponse(SynchronizationPoint.java:270)
        at org.jivesoftware.smack.SynchronizationPoint.checkIfSuccessOrWait(SynchronizationPoint.java:155)
        at org.jivesoftware.smack.SynchronizationPoint.checkIfSuccessOrWaitOrThrow(SynchronizationPoint.java:126)
        at org.jivesoftware.smack.AbstractXMPPConnection.connect(AbstractXMPPConnection.java:382)
        at org.jitsi.impl.protocol.xmpp.XmppProtocolProvider.doConnect(XmppProtocolProvider.java:248)
        at org.jitsi.impl.protocol.xmpp.XmppProtocolProvider.access$000(XmppProtocolProvider.java:57)
        at org.jitsi.impl.protocol.xmpp.XmppProtocolProvider$1.call(XmppProtocolProvider.java:229)
        at org.jitsi.impl.protocol.xmpp.XmppProtocolProvider$1.call(XmppProtocolProvider.java:224)
        at org.jitsi.retry.RetryStrategy$TaskRunner.run(RetryStrategy.java:193)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)

Look like my auth setting for jicofo was wrong ? any pointer to what was wrong though ?

@paweldomas
Copy link
Member

It seems that Jicofo is not able to reach Prosody or some problem with the certificates. I would make sure that the "--host" argument mentioned here https://github.com/jitsi/jicofo#run-arguments-descripton is correct. It's configured in /etc/jitsi/jicofo/config under JICOFO_HOST. It could be also a problem with JICOFO_AUTH_DOMAIN (or certificate for this domain in Prosody/Jicofo), but I've never seen this error, so I'm not sure.

@nathando
Copy link
Contributor Author

Hi guys,
Managed to fix that particular errors, turned out the self-signed certs were missing and not added to the ca-certificates folder
But the result is still the same currently with this jicofo log:

Jicofo 2018-01-24 07:08:01.495 INFO: [126] org.jitsi.jicofo.FocusManager.log() Created new focus for 2zxko1516271225@conference.jitsi.mydomain.com@auth.jitsi.mydomain.com conferences count: 1 options:
    enableLipSync: true
    openSctp: true
    disableRtx: false
Jicofo 2018-01-24 07:08:01.495 INFO: [126] org.jitsi.jicofo.JitsiMeetConferenceImpl.log() Lip-sync enabled in 2zxko1516271225@conference.jitsi.mydomain.com
Jicofo 2018-01-24 07:08:18.707 INFO: [13] org.jitsi.jicofo.FocusManager.log() Focus idle timeout for 2zxko1516271225@conference.jitsi.mydomain.com
Jicofo 2018-01-24 07:08:18.708 SEVERE: [13] org.jitsi.jicofo.JitsiMeetConferenceImpl.log() Chat room already left!
Jicofo 2018-01-24 07:08:18.708 INFO: [13] org.jitsi.jicofo.FocusManager.log() Disposed conference for room: 2zxko1516271225@conference.jitsi.mydomain.com conference count: 0

Main error is SEVERE: [13] org.jitsi.jicofo.JitsiMeetConferenceImpl.log() Chat room already left! but all are still connected. I still received the user connected event as usual.

@paweldomas
Copy link
Member

hmm I don't remember what was this issue about exactly... any new errors in JS console ? Is Jicofo's user an admin ?

@nathando
Copy link
Contributor Author

nathando commented Jan 26, 2018

hi guys, as it turned out it was because video bridge wasn't configured in the client.
After previous error, server settings were correct.
This line here:

bridge: 'jitsi-videobridge.jitsi.mydomain.com'

Thank for helping out!!! I am closing this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants