Kein Mensch braucht eine 3CX-Whatsthat- oder -Facebook-Integration im Business-Umfeld.
Wer sich meine Daten erschleichen möchte, um sich daran zu bereichern, ist mir erst mal suspekt.
Deshalb bekommt die Zuckerbergsche Datenkrake von mir genau das, was ihr zusteht, nämlich gar nichts.
In keinem unserer Netze wird so eine Software installiert. Würde das einer unserer Admins machen, würde ich ihm die Ohren lang ziehen. DSGVO und Whatsthat? Ein No-Go, egal was für tolle Argumente man sich einfallen lässt.
Was sich 3CX dabei denkt, so etwas zu integrieren, ist mir ein völliges Rätsel. Da können nur monetäre Interessen dahinter stecken, anders ist das nicht mehr zu erklären.
Zur 3CX Desktop App:
Wir haben aus gegebenden Anlass beschlossen, einen eigenen OSS Client (vorerst) in Java zu schreiben und nichts mehr von 3CX auf Windows-Maschinen auszurollen, da wir das, wie wir gerade hart gelernt haben, überhaupt nicht wirklich kontrollieren können, wenn das System aktuell bleiben soll. Ob das später in Go, C++ oder Rust neu geschrieben wird, wissen wir noch nicht.
Damit soll gleichzeitig eine native Integration unter Windows, macOS, Linux und anderen unixoiden Systemen ermöglicht werden, was bisher als nativer Fat-Client so nicht möglich war.
Das ist im Moment bereits ein PoC und der läuft gerade in einer Beta-Version 0.0.1 testweise beim ersten Kunden. Derzeitiger Stand jetzt ist die Implementierung von click2dial aus Browser und ERP heraus und Übergabe an das entsprechenden VoIP-Telefon des entsprechenden Users. SIP/RTP ist noch nicht intergiert.
Das soll am Ende ans AD und/oder OpenLDAP und die 3CX PostgreSQL DB angebunden werden und ist daher als Frontend-Middleware-Architektur angedacht, wobei die Middleware-Komponenten als distroless Docker-Container laufen sollen und via haproxy auch noch hochverfügbar werden. Weiterhin ist OAuth 2.0/SAML via keycloak geplant.
Was uns in 3CX bisher störte, war die Limitierung auf ein einziges Firmen-Adressbuch, die Limitierung auf 1000 Einträge und die fehlende Berechtigungsstruktur, also wer darf mit seinem SIP-Account und dem zugehörigen VoIP-Phone welche Adressbücher und/oder Eintrags-Typen sehen, z.B. Team- oder Abteilungs-Adressbücher. Man möchte z.B. nicht, dass die Produktionsabteilungen Zugriff auf die Adressbücher der Vorstandschaft haben sollen, es sei denn man definiert Ausnahmen für bestimmte Nutzergruppen oder einzelne Einträge. So feingranular geht das gar nicht mit 3CX.
Weiterhin zu erwähnen ist die fehlende Möglichkeit, bestehende Adressbücher außerhalb sicher "anzuzapfen", z.B. via LDAP, CardDAV, aus anderen Groupware-Systemen, wie z.B. Open-Xchange, Horde, Mailcow, Zimbra, o.ä., oder einfach aus einer DB heraus. Definition, welches das führende System ist, Feld-Mapping, etc., all das fehlt in 3CX.
Mit dem neuen Client sollen all diese Adressbuchbeschränkungen aufgehoben werden und 3CX wird die notwendigen Änderungen auch noch als config change mehr oder weniger freiwillig ans jeweilige Telefon deployen.
Das Beste zum Schluss: Der neue Client ist garantiert ohne Whatsthat- und Facebook-Integration.
Die ungefähre Roadmap steht damit soweit.
Passend zum Thema: Nachdem neulich die 3CX-Unterstützung für Raspberries gekappt wurde, haben wir unsere eigene Instanz nun als LXC-Container auf unserem Proxmox-Cluster laufen. Bekanntlicherweise laufen LXC-Container auch unter RPi. Der nächste Schritt ist nun, x64 basierte LXC-Container lauffähig und stabil auf dem Raspberry für den Hausgebrauch zu implementieren, ohne dass 3CX hier noch irgendwie Hand anlegen muss. Aktuell ist der LXC-Container rock-solid, keine Unterschiede zu vorher.
Hat da jemand Interesse daran und möchte sich beteiligen und/oder davon partizipieren?
Wenn ja, bitte eine PM an mich.
Telefonie 