Docker Server Api Call ERROR - Strophe: Server did not yet offer a supported authentication mechanism. Sending a blank poll request

I am using Docker Jitsi server and it is working nicely… though I am running it in local environment I made the connection secure with custom certificate for https://fuji (in private ip by configuring /etc/hosts).

secure jitsi docker server pic (working fine normally)

And I am calling external api (to create a room in that server) from an angular app running at my https://localhost:4200

secured angular app connection pic

now while calling the api I am getting error in console log :

"Strophe: Server did not yet offer a supported authentication mechanism. Sending a blank poll request"

and the after a while (1 min, though it was successful sometimes) :

"blocked by CORS policy: No ‘Access-Control-Allow-Origin’ header is present on the requested resource"



Though I did everything like :

  • consider_bosh_secure = true
  • cross_domain_bosh = true
  • made secure https connection for both jitsi and angular server
  • curl -i https://fuji says it is working

what is the problem actually about? I thought it was just a certificate problem but now I am afraid because I am totally stuck here for few days and couldn’t find any suitable solution anywhere… what should I do ? it is totally working fine normally but the problem occurs when api is called from angular app.I asked earlier but everyone thought it was a certificate pb then. Plz help …!!
edit : I am creating the API by giving a custom layer in front of lib-jitsi-meet
@saghul @damencho @Boris_Grozev
Thanx in advance for any help :heart: :slightly_smiling_face:

@saghul @damencho
I also put consider_bosh_secure=true in prosody.cfg.lua



-- Prosody Example Configuration File
--
-- Information on configuring Prosody can be found on our
-- website at http://prosody.im/doc/configure
--
-- Tip: You can check that the syntax of this file is correct
-- when you have finished by running: luac -p prosody.cfg.lua
-- If there are any errors, it will let you know what and where
-- they are, otherwise it will keep quiet.
--
-- The only thing left to do is rename this file to remove the .dist ending, and fill in the
-- blanks. Good luck, and happy Jabbering!


---------- Server-wide settings ----------
-- Settings in this section apply to the whole server and are the default settings
-- for any virtual hosts

-- This is a (by default, empty) list of accounts that are admins
-- for the server. Note that you must create the accounts separately
-- (see http://prosody.im/doc/creating_accounts for info)
-- Example: admins = { "user1@example.com", "user2@example.net" }
admins = { }

-- Enable use of libevent for better performance under high load
-- For more information see: http://prosody.im/doc/libevent
--use_libevent = true;

-- This is the list of modules Prosody will load on startup.
-- It looks for mod_modulename.lua in the plugins folder, so make sure that exists too.
-- Documentation on modules can be found at: http://prosody.im/doc/modules
modules_enabled = {
		"muc_size";
	-- Generally required
		"roster"; -- Allow users to have a roster. Recommended ;)
		"saslauth"; -- Authentication for clients and servers. Recommended if you want to log in.
		"tls"; -- Add support for secure TLS on c2s/s2s connections
		"dialback"; -- s2s dialback support
		"disco"; -- Service discovery

	-- Not essential, but recommended
		"private"; -- Private XML storage (for room bookmarks, etc.)
		"vcard"; -- Allow users to set vCards
	
	-- These are commented by default as they have a performance impact
		--"privacy"; -- Support privacy lists
		--"compression"; -- Stream compression (Debian: requires lua-zlib module to work)

	-- Nice to have
		"version"; -- Replies to server version requests
		"uptime"; -- Report how long server has been running
		"time"; -- Let others know the time here on this server
		"ping"; -- Replies to XMPP pings with pongs
		"pep"; -- Enables users to publish their mood, activity, playing music and more
		"register"; -- Allow users to register on this server using a client and change passwords

	-- Admin interfaces
		"admin_adhoc"; -- Allows administration via an XMPP client that supports ad-hoc commands
		--"admin_telnet"; -- Opens telnet console interface on localhost port 5582
	
	-- HTTP modules
		--"bosh"; -- Enable BOSH clients, aka "Jabber over HTTP"
		--"http_files"; -- Serve static files from a directory over HTTP

	-- Other specific functionality
		"posix"; -- POSIX functionality, sends server to background, enables syslog, etc.
		--"groups"; -- Shared roster support
		--"announce"; -- Send announcement to all online users
		--"welcome"; -- Welcome users who register accounts
		--"watchregistrations"; -- Alert admins of registrations
		--"motd"; -- Send a message to users when they log in
		--"legacyauth"; -- Legacy authentication. Only used by some old clients and bots.
        
};

https_ports = { }

-- These modules are auto-loaded, but should you want
-- to disable them then uncomment them here:
modules_disabled = {
	-- "offline"; -- Store offline messages
	-- "c2s"; -- Handle client connections
	-- "s2s"; -- Handle server-to-server connections
};

enable_roomsize_token_verification=false;

-- Disable account creation by default, for security
-- For more information see http://prosody.im/doc/creating_accounts
allow_registration = false;

daemonize = false;

pidfile = "/config/data/prosody.pid";


-- Force clients to use encrypted connections? This option will
-- prevent clients from authenticating unless they are using encryption.

c2s_require_encryption = false;


--The traditional solution to solving the same-origin problem is to have the web server that serves the app script also act as a proxy to the real BOSH server at some URL.
consider_bosh_secure = true

--There is a relatively new HTTP extension that allows web servers to tell browsers that cross-domain requests are ok and permitted, called CORS.
cross_domain_bosh = true

-- Force certificate authentication for server-to-server connections?
-- This provides ideal security, but requires servers you communicate
-- with to support encryption AND present valid, trusted certificates.
-- NOTE: Your version of LuaSec must support certificate verification!
-- For more information see http://prosody.im/doc/s2s#security

s2s_secure_auth = false;

-- Many servers don't support encryption or have invalid or self-signed
-- certificates. You can list domains here that will not be required to
-- authenticate using certificates. They will be authenticated using DNS.

--s2s_insecure_domains = { "gmail.com" }

-- Even if you leave s2s_secure_auth disabled, you can still require valid
-- certificates for some domains by specifying a list here.

--s2s_secure_domains = { "jabber.org" }

-- Select the authentication backend to use. The 'internal' providers
-- use Prosody's configured data storage to store the authentication data.
-- To allow Prosody to offer secure authentication mechanisms to clients, the
-- default provider stores passwords in plaintext. If you do not trust your
-- server please see http://prosody.im/doc/modules/mod_auth_internal_hashed
-- for information about using the hashed backend.

authentication = "internal_plain";

-- Select the storage backend to use. By default Prosody uses flat files
-- in its configured data directory, but it also supports more backends
-- through modules. An "sql" backend is included by default, but requires
-- additional dependencies. See http://prosody.im/doc/storage for more info.

--storage = "sql" -- Default is "internal" (Debian: "sql" requires one of the
-- lua-dbi-sqlite3, lua-dbi-mysql or lua-dbi-postgresql packages to work)

-- For the "sql" backend, you can uncomment *one* of the below to configure:
--sql = { driver = "SQLite3", database = "prosody.sqlite" } -- Default. 'database' is the filename.
--sql = { driver = "MySQL", database = "prosody", username = "prosody", password = "secret", host = "localhost" }
--sql = { driver = "PostgreSQL", database = "prosody", username = "prosody", password = "secret", host = "localhost" }

-- Logging configuration
-- For advanced logging see http://prosody.im/doc/logging
--
-- Debian:
--  Logs info and higher to /var/log
--  Logs errors to syslog also



log = {
	{ levels = {min = "info"}, to = "console"};
}



component_interface = { "*" }

data_path = "/config/data"

Include "conf.d/*.cfg.lua"

but nothing worked,same error… is this can be any problem from api? bcz I am not finding any difficulties creating room by going to server… the problem occurs when I make a external api call? should I update strophe.js or make some change in middleware ? or there is a sequence issue creating this problem?
Thanx in advance :heart:

The problem here is you are accessing your app at localhost:4200 and bosh is using localhost:8080. Make them use the same port.

1 Like

Oh…! I actually have little knowledge about how bosh works :confused: and dependent to calling origin port…!
But I am having same problem after running the angular app at https://localhost:8080 but same “Strophe:server did not…” is this

Error Message pic

actually what is happening here…! I m getting so depressed stucking here :upside_down_face:
we are not having problem calling https://meet.jit.si from this app then why not my https://fuji …!
is there something silly mistake I am doing? is there any other issue possible while calling from an app? is this problem for docker only?

Network while calling

isnt bosh working in 5280 port? but if I wanna run angular app in this port,it says “port already in use” as expected :slightly_smiling_face:
Plz help me @damencho and srry for late reply…!! @saghul
Thanx in advance for any suggestion and instruction :heart: :upside_down_face:

@saghul
I added : ports:
- “5280:5280”
in prosody service in docker compose yml file to access the 5280 port of internal network…
http
can that be a pb running angular app in same port? but

  • the api call is working for https://meet.jit.si from my angular app and
  • my docker jitsi server is working normally fine without api call
    then where the pb can be?

I think this is my type of issue : https://github.com/jitsi/docker-jitsi-meet/issues/87 which go unnoticed,plz take a look
is this about server config? I did add consider bosh secure and cross domain bosh secure at top of prosody general config…
I am just getting mad :disappointed:

Hi @saghul @damencho
I solved the issue primarily by following exactly https://github.com/jitsi/docker-jitsi-meet/issues/87 solution
I had to edit the “hosts” portion in the api that I made from lib-jitsi-meet :

hosts: {
        domain: "meet.jitsi", //meet.jitsi is the internal network of docker-compose
        muc: "muc.meet.jitsi", //check to use muc.meet.jitsi as it is conference.your.domain for normal 
        anonymousdomain: "meet.jitsi" //don't need if no anonymus is allowed
       },
      bosh: "https://fuji/http-bind" //here "fuji" is 192.168.0.149 which is the private ip of mine, and I edited /etc/hosts to access the ip with name "fuji" and this is the name used for hosting the docker jitsi server
}

now I am good with calling from the angular app and working fine with 2 or more user in my pc with differenet tabs in chrome.

working pic

" But, The problem is, it is having problem accessing from another pc in same network. My angular app is showing that another user has joined but there is no audio/video incoming/outgoing, just a instance ".
in console log in that pc :

Bridge Channel send : no opened channel

in the container log :

SCTP connection with ${participants_id} not ready
No available transport channel, can't send a message

Any idea ? should I create new topic about this as this is docker issue and api from lib jitsi meet? :slightly_smiling_face:

@damencho I did some digging and found out that may b this is happening because my jvb container port 4443/tcp,10000/udp is unaccessible from public (even in same network)?
I can access web,prosody container ports both from inside and outside my ip.
I cant even access these jvb container ports locally from my pc :confused: though it works fine in my pc, pb occurs when other pc in same network make the api call. when 3rd participant joins,one need to reconnect. actually the pb is may b the jvb bcz I tried after stopping the jvb container in my pc and the same result what happened from other pc…

Detailed pic of port stats, container stats and accesibility to ports

what should I do ? I tried enabling firewall and opening that ports but same result.
Thanx in advance :heart:

You cannot telnet to port 10000 because that’s UDP.

how can I solve it? as it is working fine in my pc in different chrome tabs bt not among different pc in same network?

Looks like you are exporting the Docker ports just fine. Do you have a firewall in your machine? Run ufw status to check.

yeah… I enabled but ufw was not enabled first… then I enabled every port I needed bt same
ufw
I ran without jvb container only and the output was same… so I thought may be the problem mainly is about jvb container port which isn’t accessible… may be…! any idea?
last time I was trying some changes and suddenly it was working with two machines… but then suddenly not… may be simple bt imp misconfiguration…! should I try using 4443/tcp rather than 10000/udp? will there be any benifit? because for the first two user (p2p) it is working fine with 2 machines…! when the 3rd user comes,some problems start occuring…
Thanx in advance :heart:

@saghul Now I am seeing that in normal access is not happening when two machines connect to same room in https://fuji :slightly_smiling_face:
when the 3rd user joins… video/audio gone and no open bridge channel error …!
plz help…! @damencho

@saghul
solved the issue…env file I didnt uncomment the

#DOCKER_HOST_ADDRESS=192.168.0.149

because I ran by this before … and by inspecting I saw it was set randomly whether I set it by my private ip or not…
and then I saw it was not having problem passing audio/video from my pc(different chrome tabs) in my ip bt pb occurs when another pc in same network connects and dont pass audio/video… actually what is the pb?
should I set it to my private ip for now? and if so when I am gonna deploy it in production server what ip should I use for dockerhost? Thanx in advance… ! I didnt even think it would cause such problem…

zone-evergreen.js:2845 POST https://localhost:8443/http-bind net::ERR_FAILED
localhost/:1 Access to XMLHttpRequest at ‘https://localhost:8443/http-bind’ from origin ‘http://localhost:4200’ 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.

meet.config

location / {
ssi on
}

BOSH
location /http-bind {
add_header ‘Access-Control-Allow-Origin’ ‘’;
add_header ‘Access-control-allow-methods’ '
’;
add_header ‘Access-control-allow-headers’ ‘*’;
proxy_pass {{ .Env.XMPP_BOSH_URL_BASE }}/http-bind;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header Host {{ .Env.XMPP_DOMAIN }};
}

jitsi meet docker prosody_1

The directory /config/data is not owned by the current user, won't be able to write files to it

The directory /config/data is not owned by the current user, won't be able to write files to it

mv: cannot stat '/config/data/*.crt': No such file or directory

mv: cannot stat '/config/data/*.key': No such file or directory
certmanager error SSL/TLS: Failed to load ‘/config/certs/meet.jitsi.key’: Check that the path is correct, and the file exists. (for meet.jitsi)

please help me on this errors

are you running docker jitsi server at https://localhost:8443/http-bind and call api to to create room from http://localhost:4200 ?
if so then can you plz share your .env file. are you using lib-jitsi-meet api to create room? if so then plz share the “hosts” object like mine was :

hosts:{
domain:"meet.jitsi",
muc: "muc.meet.jitsi",
anonymousdomain: "meet.jitsi"
},
bosh: "https://fuji/http-bind"

also try using belows in prosody.cfg.lua

c2s_require_encryption = false;


--The traditional solution to solving the same-origin problem is to have the web server that serves the app script also act as a proxy to the real BOSH server at some URL.
consider_bosh_secure = true

--There is a relatively new HTTP extension that allows web servers to tell browsers that cross-domain requests are ok and permitted, called CORS.
cross_domain_bosh = true

s2s_secure_auth = false;

also do below thing

add_header 'Access-Control-Allow-Origin' '*';
//or add_header 'Access-Control-Allow-origin' 'http://localhost:4200';

if problem persist after all of this inspect whether there is a firewall problem I was asked earlier in this thread. and plz describe the detailed things you have done and tried but failed. seems like u are also having trouble executing command, make sure you have rights to necessary directory to write or simply execute command as a super user (use “sudo” before any command).

This are Hosts:

hosts: {
domain: ‘localhost:8443’,
muc: ‘conference.localhost:8443’ // FIXME: use XEP-0030
anonymousdomain: “localhost:8443”
},
bosh: ‘https://localhost:8443/http-bind’, // FIXME: use xep-0156 for that

env. var file

Security

Set these to strong passwords to avoid intruders from impersonating a service account

The service(s) won’t start unless these are specified

Running ./gen-passwords.sh will update .env with strong passwords

You may skip the Jigasi and Jibri passwords if you are not using those

DO NOT reuse passwords

XMPP component password for Jicofo

JICOFO_COMPONENT_SECRET=a8124d3911c48c2982107a20a0228e02

XMPP password for Jicofo client connections

JICOFO_AUTH_PASSWORD=b354326ead219f6496606ffbe8c31287

XMPP password for JVB client connections

JVB_AUTH_PASSWORD=4412c1d264f9951ac89f20574229335d

XMPP password for Jigasi MUC client connections

JIGASI_XMPP_PASSWORD=a777d6370bad28f9dc8632110a395341

XMPP recorder password for Jibri client connections

JIBRI_RECORDER_PASSWORD=069fc3773b1ad94b4ef82f4e86ae2dae

XMPP password for Jibri client connections

JIBRI_XMPP_PASSWORD=8f16c188f295f743a86e1090ed96de00

Basic configuration options

Directory where all configuration will be stored

CONFIG=D:/.jitsi-meet-cfg

Exposed HTTP port

HTTP_PORT=8002

Exposed HTTPS port

HTTPS_PORT=8443

System time zone

TZ=Asia/Kolkata

Public URL for the web service

#PUBLIC_URL=https://meet.example.com

IP address of the Docker host

See the “Running behind NAT or on a LAN environment” section in the README

#DOCKER_HOST_ADDRESS=192.168.1.1

Let’s Encrypt configuration

Enable Let’s Encrypt certificate generation

#ENABLE_LETSENCRYPT=1

Domain for which to generate the certificate

#LETSENCRYPT_DOMAIN=meet.example.com

E-Mail for receiving important account notifications (mandatory)

#LETSENCRYPT_EMAIL=alice@atlanta.net

Etherpad integration (for document sharing)

Set etherpad-lite URL (uncomment to enable)

#ETHERPAD_URL_BASE=http://etherpad.meet.jitsi:9001

Basic Jigasi configuration options (needed for SIP gateway support)

SIP URI for incoming / outgoing calls

#JIGASI_SIP_URI=test@sip2sip.info

Password for the specified SIP account as a clear text

#JIGASI_SIP_PASSWORD=passw0rd

SIP server (use the SIP account domain if in doubt)

#JIGASI_SIP_SERVER=sip2sip.info

SIP server port

#JIGASI_SIP_PORT=5060

SIP server transport

#JIGASI_SIP_TRANSPORT=UDP

Authentication configuration (see README for details)

Enable authentication

#ENABLE_AUTH=1

Enable guest access

#ENABLE_GUESTS=1

Select authentication type: internal, jwt or ldap

#AUTH_TYPE=internal

JWT authentication

Application identifier

#JWT_APP_ID=my_jitsi_app_id

Application secret known only to your token

#JWT_APP_SECRET=my_jitsi_app_secret

(Optional) Set asap_accepted_issuers as a comma separated list

#JWT_ACCEPTED_ISSUERS=my_web_client,my_app_client

(Optional) Set asap_accepted_audiences as a comma separated list

#JWT_ACCEPTED_AUDIENCES=my_server1,my_server2

LDAP authentication (for more information see the Cyrus SASL saslauthd.conf man page)

LDAP url for connection

#LDAP_URL=ldaps://ldap.domain.com/

LDAP base DN. Can be empty

#LDAP_BASE=DC=example,DC=domain,DC=com

LDAP user DN. Do not specify this parameter for the anonymous bind

#LDAP_BINDDN=CN=binduser,OU=users,DC=example,DC=domain,DC=com

LDAP user password. Do not specify this parameter for the anonymous bind

#LDAP_BINDPW=LdapUserPassw0rd

LDAP filter. Tokens example:

%1-9 - if the input key is user@mail.domain.com, then %1 is com, %2 is domain and %3 is mail

%s - %s is replaced by the complete service string

%r - %r is replaced by the complete realm string

#LDAP_FILTER=(sAMAccountName=%u)

LDAP authentication method

#LDAP_AUTH_METHOD=bind

LDAP version

#LDAP_VERSION=3

LDAP TLS using

#LDAP_USE_TLS=1

List of SSL/TLS ciphers to allow

#LDAP_TLS_CIPHERS=SECURE256:SECURE128:!AES-128-CBC:!ARCFOUR-128:!CAMELLIA-128-CBC:!3DES-CBC:!CAMELLIA-128-CBC

Require and verify server certificate

#LDAP_TLS_CHECK_PEER=1

Path to CA cert file. Used when server certificate verify is enabled

#LDAP_TLS_CACERT_FILE=/etc/ssl/certs/ca-certificates.crt

Path to CA certs directory. Used when server certificate verify is enabled

#LDAP_TLS_CACERT_DIR=/etc/ssl/certs

Wether to use starttls, implies LDAPv3 and requires ldap:// instead of ldaps://

LDAP_START_TLS=1

Advanced configuration options (you generally don’t need to change these)

Internal XMPP domain

XMPP_DOMAIN=meet.jitsi

Internal XMPP server

XMPP_SERVER=xmpp.meet.jitsi

Internal XMPP server URL

XMPP_BOSH_URL_BASE=http://xmpp.meet.jitsi:5280

Internal XMPP domain for authenticated services

XMPP_AUTH_DOMAIN=auth.meet.jitsi

XMPP domain for the MUC

XMPP_MUC_DOMAIN=muc.meet.jitsi

XMPP domain for the internal MUC used for jibri, jigasi and jvb pools

XMPP_INTERNAL_MUC_DOMAIN=internal-muc.meet.jitsi

XMPP domain for unauthenticated users

XMPP_GUEST_DOMAIN=guest.meet.jitsi

Custom Prosody modules for XMPP_DOMAIN (comma separated)

XMPP_MODULES=

Custom Prosody modules for MUC component (comma separated)

XMPP_MUC_MODULES=

Custom Prosody modules for internal MUC component (comma separated)

XMPP_INTERNAL_MUC_MODULES=

MUC for the JVB pool

JVB_BREWERY_MUC=jvbbrewery

XMPP user for JVB client connections

JVB_AUTH_USER=jvb

STUN servers used to discover the server’s public IP

JVB_STUN_SERVERS=meet-jit-si-turnrelay.jitsi.net:443

Media port for the Jitsi Videobridge

JVB_PORT=10000

TCP Fallback for Jitsi Videobridge for when UDP isn’t available

JVB_TCP_HARVESTER_DISABLED=true
JVB_TCP_PORT=4443
JVB_TCP_MAPPED_PORT=4443

A comma separated list of APIs to enable when the JVB is started [default: none]

See https://github.com/jitsi/jitsi-videobridge/blob/master/doc/rest.md for more information

#JVB_ENABLE_APIS=rest,colibri

XMPP user for Jicofo client connections.

NOTE: this option doesn’t currently work due to a bug

JICOFO_AUTH_USER=focus

Base URL of Jicofo’s reservation REST API

#JICOFO_RESERVATION_REST_BASE_URL=http://reservation.example.com

Enable Jicofo’s health check REST API (http://<jicofo_base_url>:8888/about/health)

#JICOFO_ENABLE_HEALTH_CHECKS=true

XMPP user for Jigasi MUC client connections

JIGASI_XMPP_USER=jigasi

MUC name for the Jigasi pool

JIGASI_BREWERY_MUC=jigasibrewery

Minimum port for media used by Jigasi

JIGASI_PORT_MIN=20000

Maximum port for media used by Jigasi

JIGASI_PORT_MAX=20050

Enable SDES srtp

#JIGASI_ENABLE_SDES_SRTP=1

Keepalive method

#JIGASI_SIP_KEEP_ALIVE_METHOD=OPTIONS

Health-check extension

#JIGASI_HEALTH_CHECK_SIP_URI=keepalive

Health-check interval

#JIGASI_HEALTH_CHECK_INTERVAL=300000

Enable Jigasi transcription

#ENABLE_TRANSCRIPTIONS=1

Jigasi will record audio when transcriber is on [default: false]

#JIGASI_TRANSCRIBER_RECORD_AUDIO=true

Jigasi will send transcribed text to the chat when transcriber is on [default: false]

#JIGASI_TRANSCRIBER_SEND_TXT=true

Jigasi will post an url to the chat with transcription file [default: false]

#JIGASI_TRANSCRIBER_ADVERTISE_URL=true

Credentials for connect to Cloud Google API from Jigasi

Please read https://cloud.google.com/text-to-speech/docs/quickstart-protocol

section “Before you begin” paragraph 1 to 5

Copy the values from the json to the related env vars

#GC_PROJECT_ID=
#GC_PRIVATE_KEY_ID=
#GC_PRIVATE_KEY=
#GC_CLIENT_EMAIL=
#GC_CLIENT_ID=
#GC_CLIENT_CERT_URL=

Enable recording

#ENABLE_RECORDING=1

XMPP domain for the jibri recorder

XMPP_RECORDER_DOMAIN=recorder.meet.jitsi

XMPP recorder user for Jibri client connections

JIBRI_RECORDER_USER=recorder

Directory for recordings inside Jibri container

JIBRI_RECORDING_DIR=/config/recordings

The finalizing script. Will run after recording is complete

JIBRI_FINALIZE_RECORDING_SCRIPT_PATH=/config/finalize.sh

XMPP user for Jibri client connections

JIBRI_XMPP_USER=jibri

MUC name for the Jibri pool

JIBRI_BREWERY_MUC=jibribrewery

MUC connection timeout

JIBRI_PENDING_TIMEOUT=90

When jibri gets a request to start a service for a room, the room

jid will look like: roomName@optional.prefixes.subdomain.xmpp_domain

We’ll build the url for the call by transforming that into:

https://xmpp_domain/subdomain/roomName

So if there are any prefixes in the jid (like jitsi meet, which

has its participants join a muc at conference.xmpp_domain) then

list that prefix here so it can be stripped out to generate

the call url correctly

JIBRI_STRIP_DOMAIN_JID=muc

Directory for logs inside Jibri container

JIBRI_LOGS_DIR=/config/logs

Disable HTTPS: handle TLS connections outside of this setup

#DISABLE_HTTPS=1

Redirect HTTP traffic to HTTPS

Necessary for Let’s Encrypt, relies on standard HTTPS port (443)

#ENABLE_HTTP_REDIRECT=1

Container restart policy

Defaults to unless-stopped

RESTART_POLICY=unless-stopped

meet.config

server_name _;

client_max_body_size 0;

root /usr/share/jitsi-meet;

ssi on with javascript for multidomain variables in config.js

ssi on;
ssi_types application/x-javascript application/javascript;

index index.html index.htm;
error_page 404 /static/404.html;

location = /config.js {
alias /config/config.js;
}

location = /interface_config.js {
alias /config/interface_config.js;
}

location = /external_api.js {
alias /usr/share/jitsi-meet/libs/external_api.min.js;
}

ensure all static content can always be found first

location ~ ^/(libs|css|static|images|fonts|lang|sounds|connection_optimization|.well-known)/(.)$
{
add_header ‘Access-Control-Allow-Origin’ '
’;
alias /usr/share/jitsi-meet/$1/$2;
}

location / {
ssi on
}

BOSH

location = /http-bind {
add_header ‘Access-Control-Allow-Origin’ ‘http://localhost:4200’;
add_header ‘Access-control-allow-methods’ ‘GET,POST,OPTIONS,DELETE,PUT,HEAD’;
add_header ‘Access-control-allow-headers’ ‘Content-Type,Origin,Authorization,X-Requested-With,Accept,X-PINGOTHER’;
proxy_pass {{ .Env.XMPP_BOSH_URL_BASE }}/http-bind;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header Host {{ .Env.XMPP_DOMAIN }};
}

location ~ ^/([^/?&:’"]+)$ {
try_files $uri @root_path;
}

location @root_path {
rewrite ^/(.*)$ / break;
}

{{ if .Env.ETHERPAD_URL_BASE }}

Etherpad-lite

location /etherpad/ {
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection ‘upgrade’;
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;

proxy_pass {{ .Env.ETHERPAD_URL_BASE }}/;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_buffering off;
proxy_set_header Host {{ .Env.XMPP_DOMAIN }};

}
{{ end }}

I suggest you to go one by one simply…so you first dont care about jibri/etherpad/authentication or other major features that can be troublesome at first. your current environment is too big to inspect…so first just try without any of these and try to create simpliest room by just https://localhost:8443 then just create rooms through https://yourdomain.com:8443 (you cant just use localhost for later usecase) from your http://localhost:4200 (angular app maybe?) but I am sure of some places where you mistaken :

  1. Follow this config :
hosts:{
domain:"meet.jitsi",
muc: "muc.meet.jitsi",
anonymousdomain: "meet.jitsi"
},
bosh: "https://fuji/http-bind"

it is weired but yeah I was onto same problem and stuck for nearly months :slight_smile: here domain, muc and anonymousdomain variables are not what your server names are. Its for the internal docker server names. you can find those names on D:/.jitsi-meet-cfg/web/rootfs/defaults/config.js
so for you (and everyone else who is using docker server and calling api from other frontend to create rooms) domain name,muc and anonymous domain name would be same (the above configurations) and only in Bosh variable set yours… also use

muc_mapper_domain_prefix = "muc"

line in prosody.cfg.lua to say that the api’s muc name has muc prefix.
I post about this type of issue in another thread and plz look in here Docker CORS issue to know about more.

  1. If your url works (can create rooms normally by going http://yourdomain.com) separately it should work. in your environment file you have to uncomment the PUBLIC_URL and DOCKER_HOST_ADDRESS variable. for now (local development) you have to set the docker host address to your private ip (like 192.168.0.118 for me) and for public url you can also use your ip like https://192.168.0.149:8443 (like the docker host address). it would be best if you go to your pc’s /etc/hosts file and edit it to set new domain like
192.168.0.118 video.rajat.com

which will work as local dns and going https://video.rajat.com:8443 will redirect you to 192.168.0.118:8443 and now you can just use this name in public url and also while installing jitsi you can just put that domain name so you dont have to use letsencrypt (and I did’nt try letsencrypt)
Hope you will get out of this… :heart:

1 Like

thanku for help i tried your all point connection created then there error come

external_api.js:15 2020-06-16T04:55:05.759Z [modules/xmpp/xmpp.js] Feature discovery error null