opentalk videoconferencing
-
From the founder of mailbox.org. For me the best alternative to Zoom
https://opentalk.eu
Bring teams together, collaborate productively and creatively, delight customers online, and enjoy true data protection.on premise
https://opentalk.eu/de/on-premise-videokonferenzenmaybe cloudron compatible
https://gitlab.opencode.de/opentalk/ot-setup -
Interesting!
The source code was just recently released:
German video conferencing provider OpenTalk has published the code for its eponymous communications platform under the EUPL (European Public License) open source license on OpenCode.de. That the common platform of public administration for the exchange of open source software was chosen as the repository of the program sources is only logical: because OpenTalk, developed by the Berlin Linux and mailbox specialist Heinlein Support, sees the software as particularly suitable for use in politics and administration, universities and schools.
Front-end and back-end code is ready
On the Git server of OpenCode.de, the code of the frontend created with the JavaScript library as well as the backend programmed in Rust including the server components has been published. Further building blocks such as a Keycloak for participant authentication and a Postgres server are required for operation, which are automatically installed and configured in provided Docker containers. For interested administrators, a guide is available that describes how to install the community version of the video conferencing software on their own systems.As is common with many commercial open source projects, the community version of OpenTalk includes only basic features. The paid enterprise edition includes additional features such as audit-proof reconciliation or high scalability based on Kubernetes clusters. It can be licensed individually and includes support assistance during productive operation. Hosters and platform operators can also integrate the software into their own products and services and offer OpenTalk-based services. Control is then based on a REST API. In the medium term, the manufacturer also hopes for an active community that develops supplements around OpenTalk. However, the necessary coordination processes are currently still lacking.
translated from https://www.heise.de/news/Videokonferenzen-DSGVO-konformes-OpenTalk-jetzt-quelloffen-7495132.html
About the Project:
Berlin-based company OpenTalk is taking on established video telephony apps that have often been used in German offices to date. According to SPIEGEL information, the first authorities are already testing the system.
The company OpenTalk is launching a new video conferencing service starting Wednesday that aims to compete with offerings such as Microsoft Teams, Zoom or Cisco's WebEx. The calls will run via cloud servers operated exclusively in Germany, according to the company. The service was developed by Berlin-based Heinlein Support GmbH over a period of around two and a half years.
OpenTalk is aimed in particular at companies and public authorities. According to SPIEGEL, the service is already being tested in several state institutions or has been commissioned or scheduled for pilot projects, for example at the Federal Environment Agency or by the state chancellery in Schleswig-Holstein. The system is currently being tested in the Thuringian administration. Public authorities in Germany still regularly use video call services from the USA.
The head of OpenTalk, Peer Heinlein, sees this as "a question of national security." It's a problem when numerous government agencies use systems from U.S. providers, he said. "The last attack hit a gas pipeline, the next one could hit a submarine Internet cable. Video telephony by authorities is also a kind of critical infrastructure and should be able to run autonomously in Germany," Heinlein told SPIEGEL.
Another fundamental problem for government video service systems so far has also been that they run over federal or agency infrastructure, with bandwidth restrictions due to security requirements. OpenTalk would also have to run over these systems in most cases. Nevertheless, Heinlein believes it is well equipped for such problems with various measures - including the fact that its service also works relatively well with mediocre bandwidths.
Heinlein also emphasizes that the company's own systems are run entirely out of its own data centers in Berlin and that no data flows abroad.
OpenTalk calls, like many other services designed for high numbers of subscribers, are not yet protected with the particularly secure end-to-end encryption. However, company sources say that they are working on such a function.
New accounts with the service will cost between 7.50 and 12.50 euros per account per month, depending on the features booked. The calls are initially designed for 200 subscribers per call, but tests have shown a much higher limit, they say. -
Hmm, it's a pretty big app.
Here's the contents of the docker-compose file:--- version: "3.9" services: # *** KEYCLOAK *** keycloak: image: quay.io/keycloak/keycloak:${KC_IMAGE_TAG:-20.0} profiles: ["core", "keycloak", "controller"] restart: always environment: KEYCLOAK_ADMIN: ${KEYCLOAK_ADMIN:-admin} KEYCLOAK_ADMIN_PASSWORD: ${KEYCLOAK_ADMIN_PASSWORD} KC_REALM_ID: ${KC_REALM_ID:-opentalk} KC_REALM_NAME: ${KC_REALM_NAME:-opentalk} KC_REALM_DISPLAYNAME: ${KC_REALM_DISPLAYNAME:-opentalk} KC_CLIENT_SECRET: ${KC_CLIENT_SECRET} KC_DOMAIN: ${OT_DOMAIN:-opentalk.example.com} KC_HOSTNAME: "accounts.${OT_DOMAIN:-opentalk.example.com}" KC_HTTP_RELATIVE_PATH: ${KC_HTTP_RELATIVE_PATH:-/auth} KC_PROXY: ${KC_PROXY:-edge} KC_TESTUSER_ENABLE: ${KC_TESTUSER_ENABLE:-false} entrypoint: [] command: - /bin/sh - -c - | /opt/keycloak/bin/kc.sh build --health-enabled=true /opt/keycloak/bin/kc.sh start --import-realm --optimized user: 0:0 volumes: - ${KC_HOST_DATA_DIR:-./data/kc_data}:/opt/keycloak/data/:Z - ${KC_HOST_POVIDER_DIR:-./data/kc_provider}:/opt/keycloak/providers:Z ports: - ${KC_EXP_PORT:-8087}:8080 healthcheck: test: curl -fsS http://keycloak:8080/auth/health/ready -o - | grep UP interval: 20s timeout: 120s retries: 10 # *** POSTGRES *** postgres: image: postgres:${POSTGRES_IMAGE_TAG:-13-alpine} profiles: ["core", "postgres", "controller"] volumes: - ${POSTGRES_HOST_DATA_DIR:-./data/pg_data}:/var/lib/postgresql/data restart: always # ports: # - ${POSTGRES_EXP_PORT:-5432}:5432 environment: POSTGRES_DB: ${POSTGRES_DB:-k3k} POSTGRES_USER: ${POSTGRES_USER:-ot} POSTGRES_PASSWORD: ${POSTGRES_PASSWORD} # *** AUTOHEAL *** autoheal: image: willfarrell/autoheal:${AUTOHEAL_IMAGE_TAG:-latest} profiles: ["core", "keycloak", "postgres", "rabbit", "web-frontend", "controller", "janus"] restart: always environment: AUTOHEAL_CONTAINER_LABEL: all volumes: - /var/run/docker.sock:/var/run/docker.sock # *** RabbitMQ *** rabbit: image: rabbitmq:${RABBITMQ_IMAGE_TAG:-3.10-management-alpine} profiles: ["core", "rabbit", "janus", "controller", "obelisk", "mail-worker", "recorder"] restart: always ports: - ${RABBITMQ_EXP_NODE_PORT:-5672}:5672 # - ${RABBITMQ_EXP_UI_PORT:-15672}:15672 environment: RABBITMQ_SERVER_ADDITIONAL_ERL_ARGS: -rabbit consumer_timeout 30000 healthcheck: test: rabbitmq-diagnostics -q check_running && rabbitmq-diagnostics -q check_local_alarms interval: 10s timeout: 15s retries: 5 # *** Redis *** redis: image: redis:${REDIS_IMAGE_TAG:-alpine} profiles: ["core", "redis", "controller"] restart: always # ports: # - ${REDIS_EXP_PORT:-6379}:${REDIS_EXP_PORT:-6379} # *** Web-Frontend web-frontend: image: registry.opencode.de/opentalk/web-frontend:${OT_FRONTEND_IMAGE_TAG:-v1} profiles: ["core", "web-frontend"] restart: always ports: - ${OT_FRONTEND_EXP_PORT:-8080}:80 environment: CONTROLLER_HOST: controller.${OT_DOMAIN:-opentalk.example.com} BASE_URL: https://${OT_DOMAIN:-opentalk.example.com} OIDC_ISSUER: https://accounts.${OT_DOMAIN:-opentalk.example.com}/auth/realms/${KC_REALM_ID:-opentalk} OIDC_CLIENT_ID: ${OIDC_CLIENT_ID:-OtFrontend} NDT_SERVER: ${NDT_SERVER:-ndt.example.com} CHANGE_PASSWORD_URL: https://accounts.${OT_DOMAIN:-opentalk.example.com}/auth/realms/${KC_REALM_ID:-opentalk}/account/ ERROR_REPORT_ADDRESS: ${ERROR_REPORT_ADDRESS:-reports@example.com} LIBRAVATAR_DEFAULT_IMAGE: ${LIBRAVATAR_DEFAULT_IMAGE:-identicon} VIDEO_BACKGROUNDS: >- [{ altText: 'OpenTalk', url: '/assets/videoBackgrounds/elevate-bg.png', thumb: '/assets/videoBackgrounds/thumbs/elevate-bg-thumb.png', }] IS_BETA_RELEASE: ${IS_BETA_RELEASE:-false} FEATURE_USER_SEARCH: ${FEATURE_USER_SEARCH:-false} FEATURE_TIMER: ${FEATURE_TIMER:-true} FEATURE_WHITEBOARD: ${FEATURE_WHITEBOARD:-false} FEATURE_PROTOCOL: ${FEATURE_PROTOCOL:-false} FEATURE_RECORDING: ${FEATURE_RECORDING:-false} # *** controller *** controller: image: registry.opencode.de/opentalk/controller:${OT_CONTROLLER_IMAGE_TAG:-v0.1} profiles: ["core", "controller"] restart: always depends_on: keycloak: condition: service_healthy rabbit: condition: service_healthy janus: condition: service_healthy minio: condition: service_healthy ports: - ${OT_CONTROLLER_EXP_PORT:-8090}:11311 volumes: - ${OT_CONTROLLER_CONFIG_FILE:-./config/controller.toml}:/controller/config.toml # *** minio *** minio: image: minio/minio:${MINIO_IMAGE_TAG:-RELEASE.2023-01-02T09-40-09Z.hotfix.5c99bdd49} profiles: ["core", "minio", "controller"] restart: always command: minio server /data volumes: - ./data/minio:/data healthcheck: test: ["CMD", "curl", "-f", "http://localhost:9000/minio/health/live"] interval: 30s timeout: 20s retries: 3 environment: MINIO_ROOT_USER: ${MINIO_ROOT_USER:-minioadmin} MINIO_ROOT_PASSWORD: ${MINIO_ROOT_PASSWORD:-minioadmin} # *** janus gateway*** janus: image: registry.opencode.de/opentalk/janus-gateway:${JANUS_IMAGE_TAG:-latest} profiles: ["core", "janus", "controller", "obelisk"] restart: always network_mode: host depends_on: - rabbit command: - janus environment: WAITTIMEOUT: ${JANUS_WAITTIMEOUT:-30} RABBITMQ_HOST: ${RABBITMQ_HOST:-rabbit} RABBITMQ_PORT: ${RABBITMQ_EXP_NODE_PORT:-5672} JANUS_DISABLE_WEBSOCKET: ${JANUS_DISABLE_WEBSOCKET:-true} JANUS_DISABLE_HTTP: ${JANUS_DISABLE_HTTP:-true} JANUS_EXCHANGE: ${JANUS_EXCHANGE:-janus-exchange} JANUS_QUEUE_NAME: ${JANUS_QUEUE_NAME:-janus-gateway} JANUS_EXCHANGE_TYPE: ${JANUS_EXCHANGE_TYPE:-topic} JANUS_QUEUE_INCOMING: ${JANUS_QUEUE_INCOMING:-to-janus} JANUS_ROUTING_KEY_OUTGOING: ${JANUS_ROUTING_KEY_OUTGOING:-from-janus} JANUS_ICE_IF: ${JANUS_ICE_IF:-eth0} JANUS_UDP_PORT_RANGE: ${JANUS_UDP_PORT_RANGE:-20000-25000} JANUS_ICE_LITE: ${JANUS_ICE_LITE:-true} JANUS_EVENT_LOOPS: ${JANUS_EVENT_LOOPS:-8} JANUS_IGNORE_MDNS: ${JANUS_IGNORE_MDNS:-true} # *** obelisk *** obelisk: image: registry.opencode.de/opentalk/obelisk:${OT_OBELISK_IMAGE_TAG:-latest} profiles: ["obelisk"] network_mode: host restart: always depends_on: rabbit: condition: service_healthy janus: condition: service_healthy environment: RUST_LOG: ${RUST_LOG:-info} GST_DEBUG: ${GST_DEBUG:-2} CONTROLLER_DOMAIN: ${CONTROLLER_DOMAIN:-controller.$OT_DOMAIN} SIP_ADDR: "${SIP_ADDR:-0.0.0.0}" SIP_PORT: "${SIP_PORT:-5060}" SIP_USER: "${SIP_USER:-mysipuser}" SIP_PASSWORD: "${SIP_PASSWORD:-mysippw}" SIP_REALM: "${SIP_REALM:-SIP_REALM}" SIP_REGISTRAR: "${SIP_REGISTRAR:-sip:yoursipprovider.com}" SIP_STUN_SERVER: "${SIP_STUN_SERVER:-stun.yoursipprovider.com:3478}" SIP_ENFORCE_QOP: "${SIP_ENFORCE_QOP:-true}" SIP_RTP_PORT_RANGE_START: "${SIP_RTP_PORT_RANGE_START:-40000}" SIP_RTP_PORT_RANGE_END: "${SIP_RTP_PORT_RANGE_END:-49999}" # *** mail worker *** mail-worker: image: registry.opencode.de/opentalk/smtp-mailer:${OT_MAIL_WORKER_IMAGE_TAG:-latest} profiles: ["mail-worker"] restart: always depends_on: rabbit: condition: service_healthy #volumes: # - ${OT_MAIL_WORKER_CONFIG_FILE:-./config/mail-worker.toml}:/opt/smtp-mailer/config.toml environment: RUST_LOG: ${RUST_LOG:-info} MAILER_SMTP__SERVER: "${SMTP_SERVER:-}" MAILER_FRONTEND__BASE_URL: "https://$OT_DOMAIN" MAILER_LANGUAGES__DEFAULT_LANGUAGE: "${LANGUAGES_DEFAULT_LANGUAGE:-de-DE}" MAILER_RABBITMQ__MAIL_TASK_QUEUE: "${RABBITMQ_MAIL_TASK_QUEUE:-opentalk_mailer}" MAILER_RABBITMQ__URL: "${RABBITMQ_URL:-amqp://rabbit/%2F}" # *** spacedeck *** spacedeck: image: registry.opencode.de/opentalk/spacedeck:${SD_IMAGE_TAG:-latest} profiles: ["spacedeck"] restart: always environment: SD_HOST: ${SD_HOST:-0.0.0.0} SD_PORT: ${SD_PORT:-9666} SD_ENDPOINT: ${SD_ENDPOINT:-} SD_API_TOKEN: ${SD_API_TOKEN:-} SD_INVITE_CODE: ${SD_INVITE_CODE:-} ports: - "${SD_EXP_PORT:-9666}:${SD_PORT:-9666}" # *** etherpad *** etherpad: image: registry.opencode.de/opentalk/etherpad:${EP_IMAGE_TAG:-latest} profiles: ["etherpad"] restart: always environment: EP_APIKEY: ${EP_APIKEY:-} TRUST_PROXY: ${TRUST_PROXY:-true} SUPPRESS_ERRORS_IN_PAD_TEXT: ${SUPPRESS_ERRORS_IN_PAD_TEXT:-true} DEFAULT_PAD_TEXT: ${DEFAULT_PAD_TEXT:-Willkommen bei OpenTalk!} ports: - "${EP_EXP_PORT:-9001}:${EP_PORT:-9001}" -
It seems the deployment was simplified a bit, still using Keycloak and RabbitMQ.
https://gitlab.opencode.de/opentalk/ot-setup/-/blob/1.6-release/docker-compose.yamlNew features page: https://mailbox.org/en/post/hello-opentalk-the-gdpr-compliant-video-conferencing-solution
Self-hosting page: https://opentalk.eu/en/on-premise-videoconferencing
-
Keycloack - is quite a behemoth on itself
-
A quick read spreads doubts to me that this might not be possible to run on Cloudron at all. Sadly enough.
OpenTalk utilizes modern container technology. Each conference will be launched within a container. For small-scale installations, that's usually "localhost", or alternatively, a Kubernetes cluster for anything bigger. OpenTalk takes care of the provisioning, operation and shutdown of each conference container.
Containerization ensures vertical & horizontal scaling as wells as clear data separation between conferences and participants. OpenTalk allows hassle-free operation, good management of CPUs and other resources, and avoids the "10K" scale-out issues that other solutions may suffer from. A conference container runs largely independently, which is great for administrators, as configuration changes and even system updates can be performed at all times without causing disruption.
-
I may give Kopano Meet another try... (although tbh mostly still happy with out of date Jitsi and Nextcloud Talk for my limited needs)
-
I'm sorry, but:
Each conference will be launched within a container.
Sounds like a nice marketing wording for what's happening already for any docker-ized app. Every docker-ized app launch it's context within a container.
And I seriously doubt that for every call they deploy separate container and kill it afterwards - especially on Kubernetes, that would make calls setup extremely slow.
-
@potemkin_ai said in opentalk videoconferencing:
I'm sorry, but:
You can...
Each conference will be launched within a container.
That's a quote from OpenTalk's website, I do not invent and propagate hearings lol
Sounds like a nice marketing wording for what's happening already for any docker-ized app. Every docker-ized app launch it's context within a container.
It's in no way a "marketing wording" it's how they've implemented their app's environment apparently. To run an app built to run from within a docker container, obviously it runs in a container. Though the self-contained apps
And I seriously doubt that for every call they deploy separate container and kill it afterwards - especially on Kubernetes, that would make calls setup extremely slow.
Well, I get you but this is not my saying, this is what I quoted from their own website so this is their OWN explanation of how their conference server works. If you don't believe them, maybe you should go and argue with them what you know about Docker and Kubernetes?
For my part, according to their OWN explanation, it reminds me much of how Cloudron works, somehow...
