saghul
commented
5 months ago What SDK platform are you using?
Open NimbleDev opened 5 months ago
saghul
commented
5 months ago What SDK platform are you using?
NimbleDev
commented
5 months ago What SDK platform are you using?
React Native SDK
NimbleDev
commented
5 months ago What SDK platform are you using?
Any suggestion? Does RN SDK support websocket for ios? FYI, websocket works fine on Android with RN sdk.
Looking forward to your reply eagly! Thx a lot!
saghul
commented
5 months ago WS should just work, on all platforms. Can you test the latest SDK version? That is, 2.2.1 right now.
NimbleDev
commented
5 months ago WS should just work, on all platforms. Can you test the latest SDK version? That is, 2.2.1 right now.
We have already tested the 2.2.1 SDK. The problem still exists with the latest SDK version.
NimbleDev
commented
5 months ago WS should just work, on all platforms. Can you test the latest SDK version? That is, 2.2.1 right now.
We just test the latest ios SDK, the problem also exists. The full log is listed below:
{\rtf1\ansi\ansicpg936\cocoartf2759 \cocoatextscaling0\cocoaplatform0{\fonttbl\f0\fnil\fcharset0 Menlo-Regular;} {\colortbl;\red255\green255\blue255;\red0\green0\blue0;\red255\green255\blue255;} {*\expandedcolortbl;;\csgenericrgb\c0\c0\c0;\csgenericrgb\c100000\c100000\c100000;} \paperw11900\paperh16840\margl1440\margr1440\vieww11520\viewh8400\viewkind0 \deftab593 \pard\tx593\pardeftab593\partightenfactor0
\f0\fs24 \cf2 \cb3 rn-webrtc:pc:DEBUG 0 getStats +10s\
Task <2E066B11-DDEE-42DE-8A85-C553A15EF61C>.<8> finished with error [-999] Error Domain=NSURLErrorDomain Code=-999 "cancelled" UserInfo={NSErrorFailingURLStringKey=https://clients3.google.com/generate_204?_=1718870629239, NSErrorFailingURLKey=https://clients3.google.com/generate_204?_=1718870629239, _NSURLErrorRelatedURLSessionTaskErrorKey=(\
"LocalDataTask <2E066B11-DDEE-42DE-8A85-C553A15EF61C>.<8>"\
), _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <2E066B11-DDEE-42DE-8A85-C553A15EF61C>.<8>, NSLocalizedDescription=cancelled}\
Task <4968C01D-9772-4733-BA22-8D7ADD9BD70D>.<9> resuming, timeouts(0.0, 604800.0) QOS(0x19) Voucher (null)\
[Telemetry]: Activity <nw_activity 12:2[3558CF06-1241-4705-BCF8-633371846B57] (reporting strategy default)> on Task <4968C01D-9772-4733-BA22-8D7ADD9BD70D>.<9> was not selected for reporting\
Task <4968C01D-9772-4733-BA22-8D7ADD9BD70D>.<9> waiting for setup of Connection 1\
rn-webrtc:pc:DEBUG 0 getStats +10s\
rn-webrtc:pc:DEBUG 0 getStats +10s\
Task <4968C01D-9772-4733-BA22-8D7ADD9BD70D>.<9> finished with error [-999] Error Domain=NSURLErrorDomain Code=-999 "cancelled" UserInfo={NSErrorFailingURLStringKey=https://clients3.google.com/generate_204?_=1718870649272, NSErrorFailingURLKey=https://clients3.google.com/generate_204?_=1718870649272, _NSURLErrorRelatedURLSessionTaskErrorKey=(\
"LocalDataTask <4968C01D-9772-4733-BA22-8D7ADD9BD70D>.<9>"\
), _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <4968C01D-9772-4733-BA22-8D7ADD9BD70D>.<9>, NSLocalizedDescription=cancelled}\
Task
saghul
commented
5 months ago [modules/xmpp/JingleSessionPC.js] (TIME) ICE failed JVB: 631162246.005583}
You seem to have a networking problem, not a WS problem.
NimbleDev
commented
5 months ago [modules/xmpp/JingleSessionPC.js] (TIME) ICE failed JVB: 631162246.005583}
You seem to have a networking problem, not a WS problem.
But it just happens with websocket enabled in ios RN sdk.
With bosh mode in ios RN sdk, such problem never happens.
NimbleDev
commented
5 months ago [modules/xmpp/JingleSessionPC.js] (TIME) ICE failed JVB: 631162246.005583}
You seem to have a networking problem, not a WS problem.
In addition, below is the RN SDK log, as you can see, ICE failed after Websocket closed unexpectedly.
{\rtf1\ansi\ansicpg936\cocoartf2759 \cocoatextscaling0\cocoaplatform0{\fonttbl\f0\fnil\fcharset0 Monaco;} {\colortbl;\red255\green255\blue255;\red255\green255\blue255;\red0\green0\blue0;} {*\expandedcolortbl;;\cssrgb\c100000\c100000\c100000;\cssrgb\c0\c0\c0;} \paperw11900\paperh16840\margl1440\margr1440\vieww11520\viewh8400\viewkind0 \deftab720 \pard\pardeftab720\partightenfactor0
\f0\fs24 \cf0 \cb2 \expnd0\expndtw0\kerning0
\outl0\strokewidth0 \strokec3 Type Time PID Tag Message\
13:58:39.298 89291 nimbleMeeting rn-webrtc:pc:DEBUG 0 getStats +10s\
13:57:49.231 89291 nimbleMeeting rn-webrtc:pc:DEBUG 0 getStats +10s\
13:57:39.215 89291 nimbleMeeting rn-webrtc:pc:DEBUG 0 getStats +10s\
13:57:29.198 89291 nimbleMeeting rn-webrtc:pc:DEBUG 0 getStats +10s\
13:57:19.180 89291 nimbleMeeting rn-webrtc:pc:DEBUG 0 getStats +10s\
13:56:19.099 89291 nimbleMeeting rn-webrtc:pc:DEBUG 0 getStats +10s\
13:56:09.082 89291 nimbleMeeting rn-webrtc:pc:DEBUG 0 getStats +10s\
13:55:59.080 89291 nimbleMeeting rn-webrtc:pc:DEBUG 0 getStats +10s\
13:54:18.916 89291 nimbleMeeting rn-webrtc:pc:DEBUG 0 getStats +10s\
13:53:58.883 89291 nimbleMeeting rn-webrtc:pc:DEBUG 0 getStats +10s\
13:52:48.783 89291 nimbleMeeting rn-webrtc:pc:DEBUG 0 getStats +10s\
13:50:58.617 89291 nimbleMeeting rn-webrtc:pc:DEBUG 0 getStats +10s\
13:50:08.534 89291 nimbleMeeting rn-webrtc:pc:DEBUG 0 getStats +10s\
13:57:18.456 89291 nimbleMeeting [VideoTrackAdapter] Mute event for pc 0 track 04f9685d-2247-4759-a4fd-4266315a5625-1\
13:57:28.548 89291 nimbleMeeting Invalid RCTFontWeight '120'. should be one of: (\
100,\
200,\
300,\
400,\
500,\
600,\
700,\
800,\
900,\
bold,\
normal\
)\
13:57:28.551 89291 nimbleMeeting Could not locate shadow view with tag #1185, this is probably caused by a temporary inconsistency between native views and shadow views.\
13:53:58.296 89291 nimbleMeeting Could not locate shadow view with tag #1013, this is probably caused by a temporary inconsistency between native views and shadow views.\
13:57:28.509 89291 nimbleMeeting '\uc0\u30475 \u30475 size', 200\
13:58:37.300 89291 nimbleMeeting '2024-06-20T05:58:37.298Z', '[modules/connectivity/IceFailedHandling.js]', '
saghul
commented
5 months ago Task .<53> finished with error [-999] Error Domain=NSURLErrorDomain Code=-999 "cancelled" UserInfo={NSErrorFailingURLStringKey=https://clients3.google.com/generate_204?_=1718870989836, NSErrorFailingURLKey=https://clients3.google.com/generate_204?_=1718870989836, _NSURLErrorRelatedURLSessionTaskErrorKey=( "LocalDataTask .<53>" ), _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask .<53>, NSLocalizedDescription=cancelled} Task .<53> done setting up Connection 33 Connection 33: cleaning up Task .<53> can retry(N) with reason(2) for error [1:89] Connection 33: done Task .<53> HTTP load canceled, 0/0 bytes (error code: -999 [1:89]) Task <5FBAF4C9-5938-4852-9B6F-6869673EBD40>.<54> resuming, timeouts(0.0, 604800.0) QOS(0x19) Voucher (null) [Telemetry]: Activity <nw_activity 12:2[920709DD-055B-4529-8EB8-BB682A53950B] (reporting strategy default)> on Task <5FBAF4C9-5938-4852-9B6F-6869673EBD40>.<54> was not selected for reporting
Not sure why, but all other requests also fail for you, see this one which detects if you are online or not. Are you using the netowork conditioner in any way?
NimbleDev
commented
5 months ago Task .<53> finished with error [-999] Error Domain=NSURLErrorDomain Code=-999 "cancelled" UserInfo={NSErrorFailingURLStringKey=https://clients3.google.com/generate_204?_=1718870989836, NSErrorFailingURLKey=https://clients3.google.com/generate_204?_=1718870989836, _NSURLErrorRelatedURLSessionTaskErrorKey=( "LocalDataTask .<53>" ), _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask .<53>, NSLocalizedDescription=cancelled} Task .<53> done setting up Connection 33 Connection 33: cleaning up Task .<53> can retry(N) with reason(2) for error [1:89] Connection 33: done Task .<53> HTTP load canceled, 0/0 bytes (error code: -999 [1:89]) Task <5FBAF4C9-5938-4852-9B6F-6869673EBD40>.<54> resuming, timeouts(0.0, 604800.0) QOS(0x19) Voucher (null) [Telemetry]: Activity <nw_activity 12:2[920709DD-055B-4529-8EB8-BB682A53950B] (reporting strategy default)> on Task <5FBAF4C9-5938-4852-9B6F-6869673EBD40>.<54> was not selected for reporting
Not sure why, but all other requests also fail for you, see this one which detects if you are online or not. Are you using the netowork conditioner in any way?
No. I think it's not the network problem. We've test many ios devices, websocket connection just failed after around 10 minutes every time. As I mentioned before, when we switched to BOSH mode, every things worked just fine.
saghul
commented
5 months ago Your logs above show many unrelated requests also failing (gravatar, etc). Not sure how to explain that.
NimbleDev
commented
5 months ago Your logs above show many unrelated requests also failing (gravatar, etc). Not sure how to explain that.
I did some further tests which turns out the problem should be related to some server side setting instead of ios app itself.
I changed the backend to your official site 'https://meet.jit.si' and the problem just disappeared.
Are there any server side configs related to websocket connection which may cause such problem?
saghul
commented
5 months ago You never said you were using your own server 😅
How did you install it? What versions of all components are you running?
NimbleDev
commented
5 months ago You never said you were using your own server 😅
How did you install it? What versions of all components are you running?
We install it by docker. The image version for all components is -stable-8615.
saghul
commented
5 months ago That release is a bit over a year old now: https://github.com/jitsi/docker-jitsi-meet/releases/tag/stable-8615
That is too old for us to go try and debug this, specially since you checked it's working on a newer version.
Please update to the latest image version.
NimbleDev
commented
5 months ago That release is a bit over a year old now: https://github.com/jitsi/docker-jitsi-meet/releases/tag/stable-8615
That is too old for us to go try and debug this, specially since you checked it's working on a newer version.
Please update to the latest image version.
Further investigaton reveals that the problem is related to prosody smack settings. Currently relevant settings are listed below. I increase some of them and the connection can hold on for significantly longer time. What's the best setting for these params? Or how do you set them on the official site meet.jit.si?
smacks_max_unacked_stanzas = 5; smacks_hibernation_time = 60; smacks_max_hibernated_sessions = 1; smacks_max_old_sessions = 1;
saghul
commented
5 months ago Those are the settings we use yeah: https://github.com/jitsi/docker-jitsi-meet/blob/e22b4f343b22b0aaf1c2b4e6e98c690ef87fcae6/prosody/rootfs/defaults/conf.d/jitsi-meet.cfg.lua#L125
NimbleDev
commented
4 months ago Those are the settings we use yeah: https://github.com/jitsi/docker-jitsi-meet/blob/e22b4f343b22b0aaf1c2b4e6e98c690ef87fcae6/prosody/rootfs/defaults/conf.d/jitsi-meet.cfg.lua#L125
So strange. To make client connected from ios app lasts for longer time, we have to increase smacks_hibernation_time. That is , if we set smacks_hibernation_time to 3600, the ios client can keep the connection for a bit longer than 3600s, afterwards, it will disconnect automatically.
For other normal endpoints connected from Android app, we found below debug log periodically, but for endpoints from ios app, we cann't find similar log. Any tips on that?
2024-06-24 08:40:51 c2s5648f18f1370 info Client connected 2024-06-24 08:40:51 c2s5648f18f1370 info Authenticated as 2a1b4748-f631-4445-a160-aa91c089b33a@meet.jitsi
saghul
commented
4 months ago What RN version are you using?
NimbleDev
commented
4 months ago What RN version are you using?
0.72.3
saghul
commented
4 months ago Sorry for the back and forth, I forgot something important! On that version of RN you need to patch RN so timers work in the background.
Apply the react native patch from here: https://github.com/jitsi/jitsi-meet/tree/master/patches you can use patch-package just like we do.
I submitted it upstream and it's merged in RN, but not in that version.
On native SDKs we can apply the patch ourselves, but on the RN SDK it's not possible to do so.
@Calinteodor please document this when you get a chance.
NimbleDev
commented
3 months ago Sorry for the back and forth, I forgot something important! On that version of RN you need to patch RN so timers work in the background.
Apply the react native patch from here: https://github.com/jitsi/jitsi-meet/tree/master/patches you can use
patch-packagejust like we do.I submitted it upstream and it's merged in RN, but not in that version.
On native SDKs we can apply the patch ourselves, but on the RN SDK it's not possible to do so.
@Calinteodor please document this when you get a chance.
We applied the patch, but nothing changed......
saghul
commented
3 months ago We released a new RN SDK version last week, did you check that? Note you still need to apply the aforementioned patch.
NimbleDev
commented
3 months ago We released a new RN SDK version last week, did you check that? Note you still need to apply the aforementioned patch.
Finally, we found that the problem is caused by network check in ResumeTask.js as listed below. Somehow, on iOS app, NetworkInfo.isOnline() always returns false which will disable websocket connection resume though the network is actually fine. Any suggestion to solve this? Thx a lot!
/**
* Called by {@link XmppConnection} when the connection drops and it's a signal it wants to schedule a reconnect.
*
* @returns {void}
*/
schedule() {
this._cancelResume();
this._resumeRetryN += 1;
this._networkOnlineListener
= NetworkInfo.addCancellableListener(
NETWORK_INFO_EVENT,
({ isOnline }) => {
if (isOnline) {
this._scheduleResume();
} else {
this._cancelResume();
}
});
NetworkInfo.isOnline() && this._scheduleResume();
}Good digging! That is very unusual! Are you on some kind of air-gapped environment?
NimbleDev
commented
3 months ago Good digging! That is very unusual! Are you on some kind of air-gapped environment?
No. Just nomal env. As a temp solution, we just remove "NetworkInfo.isOnline() && " so it will reconnect all the time. Everything goes fine now. Will it cause some other problem or you have some better suggestion?
saghul
commented
3 months ago That should do it yeah. I don't have a better suggestion, sorry.
NimbleDev
commented
3 months ago That should do it yeah. I don't have a better suggestion, sorry.
ok, thx a lot for your patience~
saghul
commented
3 months ago No problem!
@Calinteodor can you PTAL and see if you can repro?
Calinteodor
commented
2 months ago Not repro with meet.jit.si.
SSzzPP
commented
1 month ago I had the same problem. After turning off the firewall, this error disappeared.
What happened?
When websocket is enabled on iOS mobile app, meeting connection would be disconnected after around 10 minutes. The key error log is listed below:
Ping error threshold exceeded - killing the WebSocket
Is there any way to avoid this error? Or can we just disalbe ping function?
Platform
Browser / app / sdk version
1.0.2
Relevant log output
No response
Reproducibility
More details?
No response