Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Linux Autres OS Linux Debian Jitsi sur serveur debian/testing

Jitsi sur serveur debian/testing

8 réponses
Avatar
BERTRAND Jo=c3=abl
Bonjour à tous,

J'essaie d'installer jitsi sur l'un de mes serveurs et je sèche. J'ai
besoin d'une authentification (je ne veux pas que n'importe qui puisse
faire n'importe quoi sur un serveur accessible sur internet).

J'ai donc installé les paquets suivants :

- jicofo
- jitsi-meet
- jitsi-meet-prosody
- jitsi-meet-web
- jitsi-meet-web-config
- jitsi-videobridge

et configuré apache en conséquence pour qu'il réponde sur
https://jitsi.systella.fr

Lorsque j'entre le nom d'une conférence, il me propose d'entrer un login
et un mot de passe, ce que je fais (login et mot de passe configuré dans
/etc/jitsi/jicofo/config). Le couple login/mot de passe est le bon,
parce que si j'en essaie un autre, je me prends directement une erreur
d'authentification. Le problème est qu'avec le bon login/mot de passe,
ça reste bloqué à l'étape "connecting"... Et je ne sais pas comment
débuguer la chose.

Dans le fichier /var/log/jitsi/jvb.log, j'ai un certain nombre de
lignes qui se répètent, mais je ne sais pas si c'est relié à mon problème :

JVB 2020-04-11 14:46:44.857 PRÉCIS: [308]
org.jitsi.videobridge.xmpp.ComponentImpl.processIQ() (serving component
'JitsiVideobridge') Processing IQ (packetId IJ696-532242): <iq
type="result" id="IJ696-532242" from="jitsi.systella.fr"
to="jitsi-videobridge.jitsi.systella.fr"/>
JVB 2020-04-11 14:46:48.388 PRÉCIS: [539]
org.jitsi.videobridge.xmpp.ComponentImpl.processIQ() (serving component
'JitsiVideobridge') Processing IQ (packetId wrGd7-1419318): <iq
type="get" to="jitsi-videobridge.jitsi.systella.fr" id="wrGd7-1419318"
from="focus@auth.jitsi.systella.fr/focus3519256182970598"><query
xmlns="http://jabber.org/protocol/disco#info"/></iq>
JVB 2020-04-11 14:46:48.388 PRÉCIS: [539]
org.jitsi.videobridge.xmpp.ComponentImpl.processIQRequest() (serving
component 'JitsiVideobridge') Processing IQ request (packetId
wrGd7-1419318).
JVB 2020-04-11 14:46:48.388 PRÉCIS: [539]
org.jitsi.videobridge.xmpp.ComponentImpl.processIQ() (serving component
'JitsiVideobridge') Responding to IQ (packetId wrGd7-1419318) with: <iq
type="result" id="wrGd7-1419318"
from="jitsi-videobridge.jitsi.systella.fr"
to="focus@auth.jitsi.systella.fr/focus3519256182970598"><query
xmlns="http://jabber.org/protocol/disco#info"><identity
category="component" type="conference" name="JitsiVideobridge"/><feature
var="http://jabber.org/protocol/disco#info"/><feature
var="urn:xmpp:ping"/><feature var="jabber:iq:last"/><feature
var="urn:xmpp:time"/><feature
var="http://jitsi.org/protocol/colibri"/><feature
var="http://jitsi.org/protocol/healthcheck"/><feature
var="urn:xmpp:jingle:apps:dtls:0"/><feature
var="urn:xmpp:jingle:transports:ice-udp:1"/><feature
var="urn:xmpp:jingle:transports:raw-udp:1"/><feature
var="jabber:iq:version"/></query></iq>
JVB 2020-04-11 14:46:49.330 INFOS: [26]
org.jitsi.videobridge.Videobridge.log() CAT=stat
create_conf,conf_id=ddae609a65851434
conf_name=null,logging=false,conf_count=1,ch_count=0,v_streams=0
JVB 2020-04-11 14:46:49.363 INFOS: [26]
org.jitsi.videobridge.health.Health.log() Performed a successful health
check in 33ms. Sticky failure: false
JVB 2020-04-11 14:46:54.858 PRÉCIS: [543]
org.jitsi.videobridge.xmpp.ComponentImpl.processIQ() (serving component
'JitsiVideobridge') Processing IQ (packetId IJ696-532244): <iq
type="result" id="IJ696-532244" from="jitsi.systella.fr"
to="jitsi-videobridge.jitsi.systella.fr"/>
JVB 2020-04-11 14:46:59.363 INFOS: [26]
org.jitsi.videobridge.Videobridge.log() CAT=stat
create_conf,conf_id=311f6df3b210cfb8
conf_name=null,logging=false,conf_count=1,ch_count=0,v_streams=0
JVB 2020-04-11 14:46:59.397 INFOS: [26]
org.jitsi.videobridge.health.Health.log() Performed a successful health
check in 34ms. Sticky failure: false

Ce que je cherche à faire :
- que seul un utilisateur ayant un certain login/mot de passe puisse
créer une conférence ;
- que les autres utilisateurs ne peuvent l'utiliser qu'en étant
authentifiés eux aussi.

Toute idée sera la bienvenue.

Bien cordialement,

JKB
Signaler un problème avec ce contenu

8 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Avatar
raphael.poitevin
BERTRAND Joël writes:
Lorsque j'entre le nom d'une conférence, il me propose d'entrer un l ogin
et un mot de passe, ce que je fais (login et mot de passe configuré dans
/etc/jitsi/jicofo/config). Le couple login/mot de passe est le bon,
parce que si j'en essaie un autre, je me prends directement une erreur
d'authentification. Le problème est qu'avec le bon login/mot de pass e,
ça reste bloqué à l'étape "connecting"... Et je ne sa is pas comment
débuguer la chose.

Est-ce que déjà dans un premier temps ça foncionne sans le s ystème d’authentification ?
--
Raphaël
www.leclavierquibave.fr
Avatar
Gilles Mocellin
Le 11/04/2020 à 14:49, BERTRAND Joël a écrit :
Bonjour à tous,
J'essaie d'installer jitsi sur l'un de mes serveurs et je sèche. J'ai
besoin d'une authentification (je ne veux pas que n'importe qui puisse
faire n'importe quoi sur un serveur accessible sur internet).

[...]
Bonjour,
De mon coté, j'ai opté simplement pour l'intégration faite dans Nextcloud.
Certes, ce n'est pas du paquet Debian, mais c'est intégré, simple et
fonctionnel.
Comme j'avais déjà Nextcloud (installé via Docker), ça n'a pas été bien dur.
Pour ceux qui n'ont pas NExtcloud, ça vaut peut-être le coup de tester,
pour toutes les autres possibilités que ça offre :
- synchro de fichier (aussi sur mobile)
- partage, dont par lien (sans compte)
- carnet d'adresse et agenda partagé (CalDAV, CardDAV)
- un "app store" avec plein d'autres possibilités, dont Talk = Jistsi Meet
Avatar
NoSpam
Une idée: tu pourrais faire l'authentification avec apache .htaccess
sans toucher à Jitsi.
J'ai fais différemment: je n'autorise que certaines salle prédéfinies
avec accès sans mot de passe.
Le 13/04/2020 à 11:23, BERTRAND Joël a écrit :
NoSpam a écrit :
Le 11/04/2020 à 14:49, BERTRAND Joël a écrit :
    Bonjour à tous,
    J'essaie d'installer jitsi sur l'un de mes serveurs et je sèche. J'ai
besoin d'une authentification (je ne veux pas que n'importe qui puisse
faire n'importe quoi sur un serveur accessible sur internet).
    J'ai donc installé les paquets suivants :
- jicofo
- jitsi-meet
- jitsi-meet-prosody
- jitsi-meet-web
- jitsi-meet-web-config
- jitsi-videobridge
et configuré apache en conséquence pour qu'il réponde sur
https://jitsi.systella.fr

Alors attention, le port 443 est réservé par jitsi (dans nginx,
paragraphe stream) pour proxy_pass, Jitsi écoute le 4444
As tu suivi leur tuto ?
https://github.com/jitsi/jicofo/blob/master/README.md#secure-domain

La réponse est oui ;-)
Mais je vais reprendre point par point le howto en question.
J'ai donc créé un fichier /etc/prosody/conf.d/jitsi.systella.fr.cfg.lua
qui contient :
VirtualHost "jitsi.systella.fr"
-- enabled = false -- Remove this line to enable this host
authentication = "internal_plain"
ssl = {
key = "/etc/prosody/certs/jitsi.systella.fr.key";
certificate = "/etc/prosody/certs/jitsi.systella.fr.crt";
}
-- we need bosh
modules_enabled = {
"bosh";
"pubsub";
"ping"; -- Enable mod_ping
}
c2s_require_encryption = false
Component "conference.jitsi.systella.fr" "muc"
storage = "memory"
--modules_enabled = { "token_verification" }
admins = { "" }
Component "jitsi-videobridge.jitsi.systella.fr"
component_secret = "xxxxxxx"
VirtualHost "auth.jitsi.systella.fr"
ssl = {
key = "/etc/prosody/certs/auth.jitsi.systella.fr.key";
certificate = "/etc/prosody/certs/auth.jitsi.systella.fr.crt";
}
authentication = "internal_plain"
Component "focus.jitsi.systella.fr"
component_secret = "xxxxxxxx"
L'utilisateur existe (avec le bon mot de
passe, j'ai vérifié) puisque je trouve son mot de passe dans le fichier
/var/lib/prosody/auth%2ejitsi%2esystella%2efr/accounts/focus.dat
Dans /etc/apache2/sites-enabled, j'ai un fichier jitsi.systella.fr.conf
de configuration d'apache2:
<VirtualHost *:80>
ServerName jitsi.systella.fr
Redirect permanent / https://jitsi.systella.fr/
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R01,L]
</VirtualHost>
<VirtualHost *:443>
ServerName jitsi.systella.fr
SSLProtocol TLSv1 TLSv1.1 TLSv1.2
SSLEngine on
SSLProxyEngine on
SSLCertificateFile /etc/letsencrypt/live/systella.fr/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/systella.fr/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/systella.fr/chain.pem
SSLCipherSuite
"EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA256:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EDH+aRSA+AESGCM:EDH+aRSA+SHA256:EDH+aRSA:EECDH:!aNULL:!eNULL:!MEDIUM:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4:!SEED"
SSLHonorCipherOrder on
Header set Strict-Transport-Security "max-age1536000"
DocumentRoot "/usr/share/jitsi-meet"
<Directory "/usr/share/jitsi-meet">
Options Indexes MultiViews Includes FollowSymLinks
AddOutputFilter Includes html
AllowOverride All
Order allow,deny
Allow from all
</Directory>
ErrorDocument 404 /static/404.html
Alias "/config.js" "/etc/jitsi/meet/jitsi.systella.fr-config.js"
<Location /config.js>
Require all granted
</Location>
Alias "/external_api.js" "/usr/share/jitsi-meet/libs/external_api.min.js"
<Location /external_api.js>
Require all granted
</Location>
ProxyPreserveHost on
ProxyPass /http-bind http://localhost:5280/http-bind/
ProxyPassReverse /http-bind http://localhost:5280/http-bind/
RewriteEngine on
RewriteRule ^/([a-zA-Z0-9]+)$ /index.html
</VirtualHost>
Le fichier de configuration
(/etc/jitsi/meet/jitsi.systella.fr-config.js) contient quant à lui :
var config = {
hosts: {
domain: 'jitsi.systella.fr',
muc: 'conference.jitsi.systella.fr'
},
bosh: '//jitsi.systella.fr/http-bind',
clientNode: 'http://jitsi.org/jitsimeet',
testing: {
enableFirefoxSimulcast: false,
p2pTestMode: false
},
desktopSharingChromeExtId: null,
desktopSharingChromeSources: [ 'screen', 'window', 'tab' ],
desktopSharingChromeMinExtVersion: '0.1',
channelLastN: -1,
enableWelcomePage: true,
enableUserRolesBasedOnToken: false,
p2p: {
enabled: true,
stunServers: [
{ urls: 'stun:stun.l.google.com:19302' },
{ urls: 'stun:stun1.l.google.com:19302' },
{ urls: 'stun:stun2.l.google.com:19302' }
],
preferH264: true
},
analytics: {
},
deploymentInfo: {
}
};
Jicofo tourne :
/usr/lib/jvm/java-8-openjdk-amd64/bin/java ... org.jitsi.jicofo.Main
--host=localhost --domain=jitsi.systella.fr --portS47 --secret=xxxxx
--user_name=focus --user_domain=auth.jitsi.systella.fr --user_password=yyyy
Le secret de la ligne de commande correspond au component_secret indiqué
pour focus.jitsi.systella.fr dans la conf de prosody.
Lorsque je regarde la section 'secure domain' du howto. J'ai bien dans
le fichier de conf de prosody :
VirtualHost "jitsi.systella.fr"
authentication = "internal_plain"
Je n'ai pas créé de "guest.jitsi-meet.systella.fr" parce que je désire
que tous les utilisateurs soient authentifiés. Un peu plus loin, je
constate qu'il faudrait
-Dorg.jitsi.jicofo.auth.URL=XMPP:jitsi-meet.systella.fr dans la ligne de
commande de jicofo, ce que je n'ai pas. Je lance jicofo à la main avec
cette option, le résultat est le même. Par acquis de conscience, je
rajoute cette option à la variable JICOFO_OPTS du fichier de config.
Rien n'y fait.
Et là, je sèche...
Toute idée sera la bienvenue.
JKB
Avatar
NoSpam
Rappelle toi que jitsi utilise le port 443 pour le proxy. Si ton apache
écoute également sur ce port ... Chez moi nginx écoute le 6443 (MV dont
le port 443 de l'extérieur est forwardé sur ce port) et fait proxy_pass
vers le 4444 pour jitsi qui utilise également le 80, le 443 pour *son*
proxy_pass et le 4445 pour turn
Je fais le proxy_pass sur le 6443 car j'ai d'autres MV qui utilisent
également le 443, celle ci est en front.
Le 13/04/2020 à 14:01, BERTRAND Joël a écrit :
BERTRAND Joël a écrit :
NoSpam a écrit :
Une idée: tu pourrais faire l'authentification avec apache .htaccess
sans toucher à Jitsi.

J'y ai pensé ce matin, mais ça ne me donne pas la souplesse attendue.
Sinon, pas d'erreur grossière ?

À propos d'erreur, en voici une qui pourrait expliquer des choses (mais
je ne vois pas comment l'analyser). Lorsque je tente une création d'une
conférence "famille", je me prends ceci dans les logs :
[Mon Apr 13 13:49:34.933594 2020] [proxy_http:error] [pid 1602538]
(20014)Internal error (specific information not available): [client
192.168.10.103:48388] AH01102: error reading status line from remote
server localhost:5280, referer: https://jitsi.systella.fr/famille
Bien cordialement,
JKB
Avatar
NoSpam
Sur la partie apache je ne peux t'aider. Ton apache ne devrait pas
écouter le 443, le 6443 comme dans mon exemple puis faire un proxy_pas
sur jitsi.systelia.fr:4444 en fonction du hostname appelé. À partir de
là cela devrait être fonctionnel.
Ma conf nginx:
server {
     # SSL configuration
#
     listen 6443 http2 ssl;
     listen [::]:443 http2 ssl;
     server_name webconf.tootai.net;
     location / {
        # jitsi-meet le port 443 est utilisé par le serveur turn bbb
ecoute dans ce cas le 4444
        # si le serveur turn est désinstallé le port 443 peut à nouveau
être utilisé par nginx
#
        proxy_pass https://webconf.tootai.net:4444;
        include include.d/proxy.conf;
}
     include include.d/ssl_meetings.conf;
}
Le 13/04/2020 à 15:06, BERTRAND Joël a écrit :
NoSpam a écrit :
Rappelle toi que jitsi utilise le port 443 pour le proxy. Si ton apache
écoute également sur ce port ... Chez moi nginx écoute le 6443 (MV dont
le port 443 de l'extérieur est forwardé sur ce port) et fait proxy_pass
vers le 4444 pour jitsi qui utilise également le 80, le 443 pour *son*
proxy_pass et le 4445 pour turn
Je fais le proxy_pass sur le 6443 car j'ai d'autres MV qui utilisent
également le 443, celle ci est en front.

Effectivement, lorsque je regarde ce qu'il se passe par défaut sur les
ports utilisés pas jitsi, j'obtiens des processus qui écoutent sur :443
et :4443.
J'ai donc rajouté dans sip-communicator.properties :
org.jitsi.videobridge.TCP_HARVESTER_PORTD43
Le videobridge écoute donc maintenant sur 4443 (et plus sur 443). Ma
configuration de mod_proxy d'apache est la suivante :
<IfModule mod_proxy.c>
# If you want to use apache2 as a forward proxy, uncomment the
# 'ProxyRequests On' line and the <Proxy *> block below.
# WARNING: Be careful to restrict access inside the <Proxy *> block.
# Open proxy servers are dangerous both to your network and to the
# Internet at large.
#
# If you only want to use apache2 as a reverse proxy/gateway in
# front of some web application server, you DON'T need
# 'ProxyRequests On'.
#ProxyRequests On
#<Proxy *>
# AddDefaultCharset off
# Require all denied
# #Require local
#</Proxy>
# Enable/disable the handling of HTTP/1.1 "Via:" headers.
# ("Full" adds the server version; "Block" removes all outgoing
Via: headers)
# Set to one of: Off | On | Full | Block
#ProxyVia Off
</IfModule>
Je ne vois pas comment le proxy fait le lien entre le port 443 d'apache
et le 4443 de jitsi. J'ai l'impression qu'il manque quelque chose.
J'ajoute donc dans le fichier de conf de jitsi.systella.fr :
ProxyPass / http://localhost:4443/
ProxyPassReverse / http://localhost:4443/
Et ça ne fonctionne toujours pas mieux (mais j'ai une autre erreur) :
[Mon Apr 13 14:59:26.187471 2020] [proxy:error] [pid 1781414]
(111)Connection refused: AH00957: HTTP: attempt to connect to
127.0.0.1:4443 (localhost) failed
[Mon Apr 13 14:59:26.187493 2020] [proxy_http:error] [pid 1781414]
[client 192.168.10.103:58684] AH01114: HTTP: failed to make connection
to backend: localhost, referer: https://jitsi.systella.fr/
Effectivement, dans le fichier de conf du videobridge, j'ai écrit :
org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS2.168.254.1
Je modifie donc la conf d'apache :
ProxyPass / http://192.168.254.1:4443/
ProxyPassReverse / http://192.168.254.1:4443/
Nouvelle erreur, mais j'ai l'impression que je progresse :
[Mon Apr 13 15:04:48.096005 2020] [proxy_http:error] [pid 1787092]
(20014)Internal error (specific information not available): [client
192.168.10.103:59084] AH01102: error reading status line from remote
server 192.168.254.1:4443
[Mon Apr 13 15:04:48.096045 2020] [proxy:error] [pid 1787092] [client
192.168.10.103:59084] AH00898: Error reading from remote server returned
by /
Je continue à creuser.
JKB
Avatar
NoSpam
Le 13/04/2020 à 18:03, BERTRAND Joël a écrit :
NoSpam a écrit :
Rappelle toi que jitsi utilise le port 443 pour le proxy. Si ton apache
écoute également sur ce port ... Chez moi nginx écoute le 6443 (MV dont
le port 443 de l'extérieur est forwardé sur ce port) et fait proxy_pass
vers le 4444 pour jitsi qui utilise également le 80, le 443 pour *son*
proxy_pass et le 4445 pour turn
Je fais le proxy_pass sur le 6443 car j'ai d'autres MV qui utilisent
également le 443, celle ci est en front.

Je pense qu'il y a quelque chose que je ne saisis pas bien dans le
fonctionnement de jitsi. Je viens de lire et relire la doc et ce n'est
pas franchement plus clair.
À quoi sert le proxy et de quels flux s'occupe-t-il (et sur quels ports) ?
De ce que j'ai compris :
- le 80 externe est redirigé sur le 443
- le 443 répond en https (jitsi-meet)
- le proxy qui s'occupe du videobridge.
La question qui se pose est donc la suivante : en supposant qu'on ne
puisse pas rediriger le port 443 externe sur autre chose, comment
organiser l'ensemble des ports pour que ça fonctionne ?

Ce que je ferai: une règle PREROUTING qui redirige le 443 sur un port X
sur lequel écoute ton apache en plus des ports nécessaires pour jitsi.
Ensuite tu rediriges ton traffic via apache en proxy_pass vers jitsi
port 4444, Extrait de la config jitsi nginx:
# this is jitsi-meet nginx module configuration
# this forward all http traffic to the nginx virtual host port
# and the rest to the turn server
Donc le port 443 jitsi renvoi sur 127.0.0.1:4444 (web) et 127.0.0.1:4445
(turn)
Ma config court-circuite le 443 de jitsi en écoutant sur 6443 et renvoi
directement sur 4444 n'ayant pas besoin du serveur turn (pas de LAN
derrière)
--
Daniel
Avatar
raphael.poitevin
BERTRAND Joël writes:
1.0.4101-1

Oui bien je suis resté à celle-là. Je ne me suis pas pench é sur le
système d’authentification.
C'est tout de même un truc tordu à configurer. Si j'ai autant de mal
après une mise à jour, je sens que je vais jeter l'éponge. Ça me
rappelle iFolder sur Sparc il y a une quinzaine d'années...

Ce n’est pas hyper intuitif en effet.
--
Raphaël
www.leclavierquibave.fr
Avatar
Erwann Le Bras
bonjour
un article sur Jitsi :
https://linuxfr.org/news/organiser-des-visioconferences-de-haute-qualite- avec-le-logiciel-libre-jitsi-meet
amitié socialement distancée
Erwann
Le 11/04/2020 à 14:49, BERTRAND Joël a écrit :
Bonjour à tous,
J'essaie d'installer jitsi sur l'un de mes serveurs et je sèche. J'ai
besoin d'une authentification (je ne veux pas que n'importe qui puisse
faire n'importe quoi sur un serveur accessible sur internet).
J'ai donc installé les paquets suivants :
- jicofo
- jitsi-meet
- jitsi-meet-prosody
- jitsi-meet-web
- jitsi-meet-web-config
- jitsi-videobridge
et configuré apache en conséquence pour qu'il réponde su r
https://jitsi.systella.fr
Lorsque j'entre le nom d'une conférence, il me propose d'entrer un login
et un mot de passe, ce que je fais (login et mot de passe configuré dans
/etc/jitsi/jicofo/config). Le couple login/mot de passe est le bon,
parce que si j'en essaie un autre, je me prends directement une erreur
d'authentification. Le problème est qu'avec le bon login/mot de pa sse,
ça reste bloqué à l'étape "connecting"... Et je ne sais pas comment
débuguer la chose.
Dans le fichier /var/log/jitsi/jvb.log, j'ai un certain nombre de
lignes qui se répètent, mais je ne sais pas si c'est relié à mon problème :
JVB 2020-04-11 14:46:44.857 PRÉCIS: [308]
org.jitsi.videobridge.xmpp.ComponentImpl.processIQ() (serving component
'JitsiVideobridge') Processing IQ (packetId IJ696-532242): <iq
type="result" id="IJ696-532242" from="jitsi.systella.fr"
to="jitsi-videobridge.jitsi.systella.fr"/>
JVB 2020-04-11 14:46:48.388 PRÉCIS: [539]
org.jitsi.videobridge.xmpp.ComponentImpl.processIQ() (serving component
'JitsiVideobridge') Processing IQ (packetId wrGd7-1419318): <iq
type="get" to="jitsi-videobridge.jitsi.systella.fr" id="wrGd7-141 9318"
from="/focus3519256182970598"><query
xmlns="http://jabber.org/protocol/disco#info"/></iq>
JVB 2020-04-11 14:46:48.388 PRÉCIS: [539]
org.jitsi.videobridge.xmpp.ComponentImpl.processIQRequest() (serving
component 'JitsiVideobridge') Processing IQ request (packetId
wrGd7-1419318).
JVB 2020-04-11 14:46:48.388 PRÉCIS: [539]
org.jitsi.videobridge.xmpp.ComponentImpl.processIQ() (serving component
'JitsiVideobridge') Responding to IQ (packetId wrGd7-1419318) with: <iq
type="result" id="wrGd7-1419318"
from="jitsi-videobridge.jitsi.systella.fr"
to="/focus3519256182970598"><query
xmlns="http://jabber.org/protocol/disco#info"><identity
category="component" type="conference" name="JitsiVideobridge"/>< feature
var="http://jabber.org/protocol/disco#info"/><feature
var="urn:xmpp:ping"/><feature var="jabber:iq:last"/><feature
var="urn:xmpp:time"/><feature
var="http://jitsi.org/protocol/colibri"/><feature
var="http://jitsi.org/protocol/healthcheck"/><feature
var="urn:xmpp:jingle:apps:dtls:0"/><feature
var="urn:xmpp:jingle:transports:ice-udp:1"/><feature
var="urn:xmpp:jingle:transports:raw-udp:1"/><feature
var="jabber:iq:version"/></query></iq>
JVB 2020-04-11 14:46:49.330 INFOS: [26]
org.jitsi.videobridge.Videobridge.log() CAT=stat
create_conf,conf_idÝae609a65851434
conf_name=null,loggingúlse,conf_count=1,ch_count=0,v_streams=

0
JVB 2020-04-11 14:46:49.363 INFOS: [26]
org.jitsi.videobridge.health.Health.log() Performed a successful health
check in 33ms. Sticky failure: false
JVB 2020-04-11 14:46:54.858 PRÉCIS: [543]
org.jitsi.videobridge.xmpp.ComponentImpl.processIQ() (serving component
'JitsiVideobridge') Processing IQ (packetId IJ696-532244): <iq
type="result" id="IJ696-532244" from="jitsi.systella.fr"
to="jitsi-videobridge.jitsi.systella.fr"/>
JVB 2020-04-11 14:46:59.363 INFOS: [26]
org.jitsi.videobridge.Videobridge.log() CAT=stat
create_conf,conf_id11f6df3b210cfb8
conf_name=null,loggingúlse,conf_count=1,ch_count=0,v_streams=

0
JVB 2020-04-11 14:46:59.397 INFOS: [26]
org.jitsi.videobridge.health.Health.log() Performed a successful health
check in 34ms. Sticky failure: false
Ce que je cherche à faire :
- que seul un utilisateur ayant un certain login/mot de passe puisse
créer une conférence ;
- que les autres utilisateurs ne peuvent l'utiliser qu'en étant
authentifiés eux aussi.
Toute idée sera la bienvenue.
Bien cordialement,
JKB