Problem on TURN not falling back to JVB

Hi there,
I noticed a problem on Chrome (latest version as of today 81.04044.92 64bits) on Windows 8.
It fails to connect to TURN (expected because of network conditions) but then Chrome does not try directly over JVB.
It works on Firefox though on the same PC and network (falls back to JVB and connects). Of course it works for us in all other platforms (chrome windows 10, android app, iOS app…) and that’s why I’m surprised.

Here’s the Chrome console…

Logger.js:154 2020-04-13T09:51:06.598Z [modules/xmpp/XmppConnection.js] <t.value>:  Stream resume enabled, but WebSockets are not enabled
Logger.js:154 2020-04-13T09:51:06.601Z [modules/xmpp/xmpp.js] <t.value>:  (TIME) Strophe connected:	 3859.594998881221
Logger.js:154 2020-04-13T09:51:06.603Z [modules/xmpp/xmpp.js] <t.value>:  My Jabber ID: 2116f1e0-...@__ourowndomain__.com/r3gjNWIi
Logger.js:154 2020-04-13T09:51:06.752Z [modules/xmpp/strophe.jingle.js] getting turn credentials failed 
Logger.js:154 2020-04-13T09:51:06.754Z [modules/xmpp/strophe.jingle.js] is mod_turncredentials or similar installed?
Logger.js:154 2020-04-13T09:51:06.759Z [modules/xmpp/strophe.ping.js] <t.value>:  XMPP pings will be sent every 10000 ms

Here it ends the log. Nothing else happens.

Just in network I can see petitions (they end in 200 OK) to http-bind…
<body xmlns:stream='http://etherx.jabber.org/streams' xmlns='http://jabber.org/protocol/httpbind' sid='2cae0b85-...'><iq type='result' to='2116f1e0-...@__ourowndomain__.com/r3gjNdgs' from=__ourowndomain__.com' id='1b070021-...:sendIQ' xmlns='jabber:client'/></body>

Any idea on this?

This means mod_turncredentials is not enabled and there are no turn servers configured.

If you are using secure domain to secure your deployment, make sure you enable the turncredentials module for the guest virtual host.

Hi @damencho, sorry for my mediocre explanation… in that case the mod_turncredentials was not enabled, right.
What I wanted to stress out is that in that particular case (Windows 8 Chrome 81.0.4044.92 64 bits) Jitsi did NOT fallback to JVB (so it was unable to connect), while Firefox did (in the same exact computer, tried several times in both browsers alternatively) and connected without problems.
Any idea on how to trace an error like that?

Is this about p2p call?

Well… config.js was configured as “p2p.enabled=true” although then mod_turncredentials was not enabled.
Anyway… Chrome should have fell back to JVB the same way Firefox did, right?
If that was your question… yes it was a 1-on-1 call.

I suppose so, I’m just trying to figure out the case, were there only two people in the call when this happen or were more? Firefox currently does not have p2p.

Yeah if it is a p2p call and turn is not available it should fallback to jvb … Opening 3 tabs from that failed chrome, it connects?

1-on-1 call.
Even the first tab on Chrome could not connect.
After that “Logger.js:154 2020-04-13T09:51:06.754Z [modules/xmpp/strophe.jingle.js] is mod_turncredentials or similar installed?” in Chrome’s console nothing else happened…
The screen was just showing “The videocall was interrupted because… Choose permit in your browser…” (maybe not literal, I’m translating from spanish).

Hum … By any chance that is either a PC with no camera or Windows 10 machine … If it is windows does chrome open https://test.webrtc.org?

It was a Windows 8 PC with camera (laptop). As I told you with Firefox worked fine.
I’ll ask the user to test https://test.webrtc.org/ both on Chrome and Firefox and let you know.

I asked cause I saw a few reports of people having problems with Windows settings and Chrome, where it cannot open the camera and they stayed on the permissions overlay …

When opening https://test.webrtc.org this happens…

I think these results are the same in other computers (but it works ok for them).
Coult the reflexive connectivity issue due to CarrierGradeNAT (a.k.a. LargeScaleNAT) connections?
The video bandwith issue… if it works in Firefox it could not really be a bandwidth problem I think.

Anyway… it seems not an explanation for Jitsi not falling back from TURN/STUN to JVB.

Did you ever solve this?