Container build 4627 does not accept meeting calls from the Android client if authentication is enabled.

[coridonhenshaw]

There appears to be a bug which prevents build 4627 of the Jitsi meet container from accepting calls to a meeting room from the Android client (build 4129209) if mandatory authentication is enabled. This occurs both when attempting to host a new meeting room and when attempting to join a meeting room when guest access is disabled.

Symptoms, from client:

After entering a valid userid and password into the authentication dialog, the client stalls for several seconds before returning the error Ooops! Something went wrong and we couldn't connect to the conference: connection.otherError item-not-found.

Console output, from server:

web_1 | 192.168.0.3 - - [24/Jun/2020:09:55:17 -0700] "GET /config.js?room=testroom HTTP/2.0" 200 7731 "-" "okhttp/3.12.1" prosody_1 | mod_bosh info New BOSH session, assigned it sid '956e9a1a-869b-4d96-8eda-608df0836f52' web_1 | 192.168.0.3 - - [24/Jun/2020:09:55:18 -0700] "POST /http-bind?room=testroom HTTP/2.0" 200 681 "-" "okhttp/3.12.1" prosody_1 | bosh956e9a1a-869b-4d96-8eda-608df0836f52 info Authenticated as uwxsfa4gzskend2w@guest.jitsi-meet.example.com web_1 | 192.168.0.3 - - [24/Jun/2020:09:55:20 -0700] "POST /http-bind?room=testroom HTTP/2.0" 200 364 "-" "okhttp/3.12.1" web_1 | 192.168.0.3 - - [24/Jun/2020:09:55:20 -0700] "POST /http-bind?room=testroom HTTP/2.0" 200 668 "-" "okhttp/3.12.1" web_1 | 192.168.0.3 - - [24/Jun/2020:09:55:21 -0700] "POST /http-bind?room=testroom HTTP/2.0" 200 495 "-" "okhttp/3.12.1" web_1 | 192.168.0.3 - - [24/Jun/2020:09:55:22 -0700] "POST /http-bind?room=testroom HTTP/2.0" 200 435 "-" "okhttp/3.12.1" web_1 | 192.168.0.3 - - [24/Jun/2020:09:55:23 -0700] "POST /http-bind?room=testroom HTTP/2.0" 200 1205 "-" "okhttp/3.12.1" jicofo_1 | Jicofo 2020-06-24 09:55:23.812 INFO: [65] org.jitsi.jicofo.xmpp.FocusComponent.log() Focus request for room: testroom@muc.meet.jitsi web_1 | 192.168.0.3 - - [24/Jun/2020:09:55:24 -0700] "POST /http-bind?room=testroom HTTP/2.0" 200 675 "-" "okhttp/3.12.1" web_1 | 192.168.0.3 - - [24/Jun/2020:09:55:30 -0700] "POST /http-bind?room=testroom HTTP/2.0" 200 313 "-" "okhttp/3.12.1" jicofo_1 | Jicofo 2020-06-24 09:55:30.633 INFO: [72] org.jitsi.jicofo.xmpp.FocusComponent.log() Focus request for room: testroom@muc.meet.jitsi web_1 | 192.168.0.3 - - [24/Jun/2020:09:55:30 -0700] "POST /http-bind?room=testroom HTTP/2.0" 200 675 "-" "okhttp/3.12.1" web_1 | 192.168.0.3 - - [24/Jun/2020:09:55:34 -0700] "POST /http-bind?room=testroom HTTP/2.0" 200 499 "-" "okhttp/3.12.1" web_1 | 192.168.0.3 - - [24/Jun/2020:09:55:36 -0700] "POST /http-bind?room=testroom HTTP/2.0" 200 313 "-" "okhttp/3.12.1" jicofo_1 | Jicofo 2020-06-24 09:55:36.633 INFO: [74] org.jitsi.jicofo.xmpp.FocusComponent.log() Focus request for room: testroom@muc.meet.jitsi web_1 | 192.168.0.3 - - [24/Jun/2020:09:55:36 -0700] "POST /http-bind?room=testroom HTTP/2.0" 200 675 "-" "okhttp/3.12.1" prosody_1 | mod_bosh info New BOSH session, assigned it sid '80007068-831a-4a7b-989b-caf3b2d14403' web_1 | 192.168.0.3 - - [24/Jun/2020:09:55:42 -0700] "POST /http-bind?room=testroom HTTP/2.0" 200 716 "-" "okhttp/3.12.1" web_1 | 192.168.0.3 - - [24/Jun/2020:09:55:42 -0700] "POST /http-bind?room=testroom HTTP/2.0" 200 313 "-" "okhttp/3.12.1" jicofo_1 | Jicofo 2020-06-24 09:55:42.289 INFO: [81] org.jitsi.jicofo.xmpp.FocusComponent.log() Focus request for room: testroom@muc.meet.jitsi web_1 | 192.168.0.3 - - [24/Jun/2020:09:55:42 -0700] "POST /http-bind?room=testroom HTTP/2.0" 200 675 "-" "okhttp/3.12.1" web_1 | 192.168.0.3 - - [24/Jun/2020:09:55:43 -0700] "POST /http-bind?room=testroom HTTP/2.0" 200 549 "-" "okhttp/3.12.1" web_1 | 192.168.0.3 - - [24/Jun/2020:09:56:43 -0700] "POST /http-bind?room=testroom HTTP/2.0" 504 229 "-" "okhttp/3.12.1" web1 | 2020/06/24 09:56:43 [error] 229#229: *1 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 192.168.0.3, server: , request: "POST /http-bind?room=testroom HTTP/2.0", upstream: "http://172.19.0.3:5280/http-bind?room=testroom", host: "{SERVER NAME REDACTED}" prosody_1 | mod_bosh info Client tried to use sid '80007068-831a-4a7b-989b-caf3b2d14403' which we don't know about

The most relevant lines appear to be the web_1 timeout error and prosody_1 mod_bosh complaining that the client tried to use a sid that prosody didn't recognize, despite the fact that mod_bosh issued that very sid several seconds earlier.

I have no issues connecting to this Jitsi container with the Android client when authentication is not required (i.e. as a guest joining an authenticated meeting that has already been authorized by a host user). I also have no issues authenticating to this Jitsi container from a web browser running on a desktop platform.

[ErroneousBosch]

Possibly related, I am seeing the same thing while trying to setup for use with FoundryVTT:

jitsi-web | 172.18.0.5 - - [15/Jul/2020:17:50:52 +0000] "OPTIONS /http-bind HTTP/1.1" 200 0 "https://foundryvtt.example.com/game" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.116 Safari/537.36" jitsi-prosody | mod_bosh info New BOSH session, assigned it sid '15e68ccf-7330-46fd-bfbd-b55f650be0d4' jitsi-web | 172.18.0.5 - - [15/Jul/2020:17:50:52 +0000] "POST /http-bind HTTP/1.1" 200 383 "https://foundryvtt.example.com/game" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.116 Safari/537.36" jitsi-web | 172.18.0.5 - - [15/Jul/2020:17:50:53 +0000] "OPTIONS /http-bind HTTP/1.1" 200 0 "https://foundryvtt.example.com/game" "Mozilla/5.0 (X11; Linux x8664) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.116 Safari/537.36" jitsi-web | 2020/07/15 17:51:53 [error] 228#228: *125 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 172.18.0.5, server: , request: "POST /http-bind HTTP/1.1", upstream: "http://172.23.0.2:5280/http-bind", host: "jitsi.example.com", referrer: "https://foundryvtt.example.com/game" jitsi-web | 172.18.0.5 - - [15/Jul/2020:17:51:53 +0000] "POST /http-bind HTTP/1.1" 504 590 "https://foundryvtt.example.com/game" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.116 Safari/537.36" jitsi-web | 172.18.0.5 - - [15/Jul/2020:17:51:53 +0000] "OPTIONS /http-bind HTTP/1.1" 200 0 "https://foundryvtt.example.com/game" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.116 Safari/537.36" jitsi-web | 172.18.0.5 - - [15/Jul/2020:17:51:53 +0000] "POST /http-bind HTTP/1.1" 200 148 "https://foundryvtt.example.com/game" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.116 Safari/537.36" jitsi-web | 172.18.0.5 - - [15/Jul/2020:17:51:53 +0000] "OPTIONS /http-bind HTTP/1.1" 200 0 "https://foundryvtt.example.com/game" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.116 Safari/537.36"

I am behind a dockerized nginx reverse proxy, but address resolution seems to be coming through. I am wondering if there is something with the host name? does it have to match the external address?

[ErroneousBosch]

I am seeing a header access control issue in the response:

Access to XMLHttpRequest at 'https://jitsi.example.com/http-bind' from origin 'https://foundryvtt.example.com' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.

I tried adding the following to my proxy nginx config:

location = /http-bind { add_header 'Access-Control-Allow-Origin' '*'; add_header 'Access-Control-Allow-Credentials' 'true'; add_header 'Access-Control-Allow-Methods' 'GET,HEAD,OPTIONS,POST,PUT'; add_header 'Access-Control-Allow-Headers' 'Access-Control-Allow-Headers, Origin,Accept, X-Requested-With, Content-Type, Access-Control-Request-Method, Access-Control-Request-Headers'; }

But this causes the entire client to be unable to connect to meetings. JS logs in the jitsi web connection show that POST requests return a 404 at that point. No difference in the error I see in Foundry, but the requests aren't getting past the proxy. (no record in Jitsi logs). The Proxy is showing a 405 Method not allowed for OPTIONS

I have also added these options to the '/' location, which doesn't generate any further errors, though I am seeing in the proxy:

nginx.1 | 2020/07/15 14:17:31 [error] 59#59: *428 no live upstreams while connecting to upstream, client: 75.118.86.1, server: jitsi.example.com, request: "OPTIONS /http-bind HTTP/2.0", upstream: "HTTPS://jitsi.example.com/http-bind", host: "jitsi.example.com", referrer: "https://foundryvtt.example.com/game" nginx.1 | jitsi.example.com 75.118.86.1 - - [15/Jul/2020:14:17:31 -0400] "OPTIONS /http-bind HTTP/2.0" 502 559 "https://foundryvtt.example.com/game" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.116 Safari/537.36"

[ErroneousBosch]

Working on this more I have tried adding the access control headers in the Reverse Proxy and in meet.conf for the web container. What I have (infuriatingly ) found is this:

If set in the rproxy only, 'Access-Control-Allow-Origin' does not get set in such a way to pass preflight (says it is not set). If set in meet.conf only, 'Access-Control-Allow-Origin' does not get set in such a way to pass preflight (says it is not set). If set in both, 'Access-Control-Allow-Origin' is set twice, once in each place.

I do not know enough about nginx to understand why it ONLY gets added if in both places, but if done that way, it gets set twice. according to the nginx documentation, it should get set if put in either place. This bizarre XAND behavior is strange.

[abnp]

The problem described by @coridonhenshaw still persists in the current version 4857.

I just set it up completely from scratch and enabled internal authentication and guest access. When I try to host a room using the Android app I am getting exactly the same log entries like @coridonhenshaw

Opening a room using a desktop browser or the desktop app works fine as well as joining an existing room using the Android app. The log of the Android app just contains the information "item-not-found" thrown by the Strophe component.

I am happy to test further if any more information would be needed!