Telefonbücher für Gigaset und Snom - Workaround

[alex303]

Ich habe den Thread jetzt gelesen, jedoch habe ich nicht gefunden wo in der gigasetN670.fxs.xml das steht.
Dort wird oft über das Script gesprochen, z.B. das die Nachnamen und Vornamen zusammen gefasst werden.

Das möchte ich aber nicht, ich würden es gerne so haben das das Gigaset die Namen richtig sortiert.

Deswegen habe ich noch die Hoffnung das man in der gigasetN670.fxs.xml es manuell anpassen kann, da es irgendwie von der 3cx Benutzeroberfläche nicht funktioniert.

Dann ist mir noch aufgefallen, das die Gigaset Geräte in der Anrufliste nur die Rufnummer und nicht den gespeicherten Namen anzeigen.
Die Namen werden nur angezeigt wenn sie im internen Telefonbuch vom Telefon gespeichert sind.
Ist das immer so, oder kann auch das irgendwo eingestellt werden?

 

[fxbastler]

Lies mal hier oder hier oder hier bzw. suche alternativ im Forum nach N670.

Wenn eine N670 mit dem orignalen Template provisioniert wird dann heisst das Telefonbuch gigaset_phonebook.xml. Diese Datei liegt im jeweiligen Provisionierungsverzeichnis:

http://<3CX_IP>:5000/provisioning/<prov.-verzeichnis>/gigaset_phonebook.xml.

Diese Datei kann in einem beliebigen Browser aufgerufen und kontrolliert werden. Mach das doch mal und schau was da drin steht.

Die meisten der Anleitungen hier in diesem Thread beziehen sich darauf dass man das Standard Template eines Telefones (Snom, N670 oder sonstwas) leicht modifiziert wird und jeweils ein separates Telefonbuch erzeugt und mit diesem Template benutzt wird. Lies dir das alles mal in Ruhe durch und versuche deine Fragen selbst zu beantworten, es wurde schon beschrieben. Ansonsten probier es einfach mal aus. Hinweis: ein Telefon (in dem Fall die Basisstation) lädt sein Telefonbuch oft erst bei einem Neustart.

 

[zimtotti]

Guten Abend zusammen...
Weiss jemand ob das Script mit der N51 IP PRO auch funktioniert?
schon getestet?
oder kann man das 1zu1 wie mit der N670 IP PRO machen?

liebe Grüße

 

[fxbastler]

Die Gigaset N510 IP Pro DECT Basisstation ist EOL. Ich habe eben extra noch einmal geschaut: in einer aktuellen 3CX v18 kann man diese noch auswählen aber in deren Provisionierungstemplate ist kein Telefonbuch Upload eingerichtet. Keine Ahnung ob man das manuell mit einem angepassten Template einrichten kann.

 

[zimtotti]

Die Gigaset N510 IP Pro DECT Basisstation ist EOL. Ich habe eben extra noch einmal geschaut: in einer aktuellen 3CX v18 kann man diese noch auswählen aber in deren Provisionierungstemplate ist kein Telefonbuch Upload eingerichtet. Keine Ahnung ob man das manuell mit einem angepassten Template einrichten kann.

ok super.... danke für die Info...
hat zwar nichts mit dem Thema hier zu tun, aber kann ich dann mehrere N670 IP PROs in reihe anschließen und die Mobilteile wandern von einer Basis in die andere? also um die komplette Fläche abzudecken?
muss ich dann das mit dem script mit jeder Basisstation machen?

 

[fxbastler]

kann ich dann mehrere N670 IP PROs in reihe anschließen und die Mobilteile wandern von einer Basis in die andere

Der Hersteller schreibt hier dass Mini Multizellenbetrieb möglich ist. Er bietet auch gleich Beispiele dazu an. Die Begrenzung der Menge der Mobilteile und der parallelen Telefonate bleibt.

Ob das nahtloses Roaming mit Handover ist (Wechsel der Funkzelle während eines Gespräches ohne Abbruch) wage ich zu bezweifeln. Das erfordert i.d.R. einen Controller. Das kann sicher jemand mit mehr Erfahrung und Wissen beantworten.

 

[Jörg Giencke]

Guten Abend zusammen...
Weiss jemand ob das Script mit der N51 IP PRO auch funktioniert?
schon getestet?
oder kann man das 1zu1 wie mit der N670 IP PRO machen?

liebe Grüße

Die N510 und N720 kennen keine XML-Telefonbücher wir die N670 und N870. Bei der N510 funtioniert nur LDAP vernünftig (mit Suche und Anzeige der Namen zu eingehenden Anrufen).

Wenn man einen LDAP-Server im Netz greifbar hat, z.B. eine Synology oder ein OpenLDAP-Server auf einem Pi, ist das recht einfach implementiert. Active Directory ginge auch, aber da würde ich nicht ohne Not drin herumschreiben.

Ich habe mein Skript mittlerweilen komplett neu geschrieben und es kann nun auch LDAP-Directories befüllen - weil ein Kunde eine Gigaset Multicell Anlage auf Basis der N720 hatte. Dass das auch mit der N510 funktioniert, ist Beifang.

Das Skript liest jetzt auch aus iCloud und Google Contacts oder auch LDAP-Directories wie Windows Active Directory.

 

[SevenBitGmbH]

Ich habe mein Skript mittlerweilen komplett neu geschrieben und es kann nun auch LDAP-Directories befüllen - weil ein Kunde eine Gigaset Multicell Anlage auf Basis der N720 hatte. Dass das auch mit der N510 funktioniert, ist Beifang.

Das klingt sehr spannend! Dürfte das LDAP-fähige Script verwendet werden? Hätten noch mehrere N510 im Einsatz und wären froh, wenn wir diese irgendwie mit 3CX bzw. dem Company Phonebook weiternutzen könnten

 

[Trust]

Oh, da hänge ich mich mal dran. Ich möchte unsere Snom M900 auch auf LDAP umbauen.
An dem Script wäre ich natürlich auch brennend interessiert.

 

[Jörg Giencke]

Das klingt sehr spannend! Dürfte das LDAP-fähige Script verwendet werden? Hätten noch mehrere N510 im Einsatz und wären froh, wenn wir diese irgendwie mit 3CX bzw. dem Company Phonebook weiternutzen könnten

Damit das nicht falsch verstanden wird: Das Hauptscript sammelt über Plugins (für Google, iCloud, CardDav) Telefonbucheinträge zusammen. Dabei können Gruppen als Auswahlkriterium angegeben werden. Danach werden die zusammengesammelten Einträge dann wiederum über Plugins (für Yealink XML, Snom XML, Gigaset XML, LDAP, 3CX CSV) abgelegt. Das 3CX Telefonbuch ist - als Datenquelle - nicht beteiligt.

Zur Zeit können die zusammengesammelten Einträge nur manuell ins 3CX Telefonbuch 'nachgeladen' werden. Das geschieht über den Import der erzeugten 3CX-CSV-Datei. Leider bin ich mit dem direkten Zugriff auf die 3CX Datenbank - um letzteren Schritt zu automatisieren - noch nicht so weit. Da wäre ich für Tipps dankbar.

 

[Trust]

Achso ok danke für die Klarstellung.
Ich hatte es so verstanden, dass du die Daten aus dem 3CX-Telefonbuch ziehst und auf einem OpenLDAP Server importierst.
Eventuell geht ja irgendwann etwas in die Richtung.

 

[Jörg Giencke]

Ich hatte es so verstanden, dass du die Daten aus dem 3CX-Telefonbuch ziehst und auf einem OpenLDAP Server importierst.

Das 3CX Telefonbuch ist als Datenquelle denkbar ungeeignet. Eine Blackbox, auf die nur mit 3CX zugegriffen werden kann - mit nichts anderem kompatibel.

Mein Ansatz zielt dahin, einen Datenbestand zu pflegen, der mit diversen Anwendungen bearbeitet und eingesehen werden kann und diversen Endgeräten - unabhängig von 3CX - zur Verfügung gestellt werden kann. 3CX ist nicht Master, 3CX ist Slave.

So hat zum Beispiel ein Kunde seine Adressdatenbank in ownCloud. Alle Adressen, die dort die Kategorie 'Telefonbuch' tragen, werden ausgelesen und für eine Gigaset N720 in ein LDAP-Verzeichnis (LDAP Server einer Synology) geschrieben sowie für Yealink und Snom Telefone in XML-Dateien auf dem Webserver eben jener Synology abgelegt.

Gewartet oder angezeigt werden kann der Datenbestand mit allem, was CardDav beherrscht. Und das ist eine Menge. So haben alle Telefone der Mitarbeiter - egal ob Android, iOS, Gigaset, Yealink oder Snom - immer den gleichen Datenbestand. Und das unabhängig von der 3CX PBX. Letztere wird momentan nach Änderungen am zentralen Datenbestand noch händisch versorgt. Ein 2-Minuten-Vorgang: 'Alles löschen' > 'Importieren', der aber auch noch automatisiert werden wird.

Natürlich könnte man als Datenquelle auch die Datenbank der 3CX hernehmen. Das ist technisch recht einfach und war auch 'seinerzeit' der erste Ansatz. Allerdings ist der Ansatz schnell fallengelassen worden, da die 3CX kontaktemäßig kaum etwas kann und sich schon gar nicht in irgendetwas anderes integrieren lässt. Nicht falsch verstehen: Die 3CX kann integrieren (CRM, MS 365, ...), anders herum geht aber nichts.

 

[Trust]

Hey vielen Dank für deine ausführliche Antwort.
die 3CX als Datenquelle zu verwenden sollte auch nur eine Notlösung sein. Früher oder später werden die Kontakte aus einem CRM kommen und auch dort gepflegt werden. Über das CRM findet dann auch die LDAP Anbindung der Snom Geräte statt.
Die M900 können über das lokale Telefonbuch (XML / 3CX Template) maximal 3000 Kontakte verarbeiten. Aus dem Grund muss ich schon vor der CRM Anbindung eine LDAP Verbindung schaffen und auf die 3CX Kontakte zurückgreifen.

 

[SevenBitGmbH]

Das 3CX Telefonbuch ist als Datenquelle denkbar ungeeignet. Eine Blackbox, auf die nur mit 3CX zugegriffen werden kann - mit nichts anderem kompatibel.

Mein Ansatz zielt dahin, einen Datenbestand zu pflegen, der mit diversen Anwendungen bearbeitet und eingesehen werden kann und diversen Endgeräten - unabhängig von 3CX - zur Verfügung gestellt werden kann. 3CX ist nicht Master, 3CX ist Slave.

So hat zum Beispiel ein Kunde seine Adressdatenbank in ownCloud. Alle Adressen, die dort die Kategorie 'Telefonbuch' tragen, werden ausgelesen und für eine Gigaset N720 in ein LDAP-Verzeichnis (LDAP Server einer Synology) geschrieben sowie für Yealink und Snom Telefone in XML-Dateien auf dem Webserver eben jener Synology abgelegt.

Gewartet oder angezeigt werden kann der Datenbestand mit allem, was CardDav beherrscht. Und das ist eine Menge. So haben alle Telefone der Mitarbeiter - egal ob Android, iOS, Gigaset, Yealink oder Snom - immer den gleichen Datenbestand. Und das unabhängig von der 3CX PBX. Letztere wird momentan nach Änderungen am zentralen Datenbestand noch händisch versorgt. Ein 2-Minuten-Vorgang: 'Alles löschen' > 'Importieren', der aber auch noch automatisiert werden wird.

Natürlich könnte man als Datenquelle auch die Datenbank der 3CX hernehmen. Das ist technisch recht einfach und war auch 'seinerzeit' der erste Ansatz. Allerdings ist der Ansatz schnell fallengelassen worden, da die 3CX kontaktemäßig kaum etwas kann und sich schon gar nicht in irgendetwas anderes integrieren lässt. Nicht falsch verstehen: Die 3CX kann integrieren (CRM, MS 365, ...), anders herum geht aber nichts.

Das klingt doch auch interessant was ich nicht ganz verstehe: weshalb funktioniert die XML-Telefonbuch beim N670, jedoch nicht beim N510? Das N510 erwartet ein "Suchresultat" in XML-Form, oder? Somit müsste es doch auch möglich sein, einfach ein ganzes Telefonbuch als XML zurückzugeben, oder? LDAP als weiteres (oder als Haupt-)Verzeichnis wäre auch eine Möglichkeit, möchten wir aber bei kleineren Kunden eher vermeiden. Daher wäre es schön wenn das N510 (oder auch die alten Tischtelefone der DE-Serie, wie DE900, etc.) irgendwie in Verbindung mit einem XML-Telefonbuch genutzt werden könnte. Die Infos dazu sind jedoch eher spärlich.

 

[Jörg Giencke]

was ich nicht ganz verstehe: weshalb funktioniert die XML-Telefonbuch beim N670, jedoch nicht beim N510? Das N510 erwartet ein "Suchresultat" in XML-Form, oder?

Gigaset N510, N670, N720 und N870 kennen Firmentelefonbücher. Dabei wird eine Suchanfrage an einen Server geschickt, der dann x XML Datensätze zurückgibt. Das Ganze ist schlecht bis gar nicht dokumentiert. Es werden auch nur Name und Nummer unterstützt, keine weiteren Attribute wie Typ (Arbeit, Privat, Mobil, ...) oder Firma. Das eignet sich lediglich für die Suche nach und Ausgabe von Nebenstellen: Meier -> 20, Müller -> 21 und ist wohl auch nur dafür gedacht ('Firmentelefonbuch').

Zusammengefasst: Vergiss es!

N670 und N870 kennen darüber hinaus ein 'Zentrales Telefonbuch' im XML-Format basierend auf einer monolithischen XML-Datei. Die lädt die Basis täglich einmal nach und versorgt die Handsets bei Anfragen (Aktive Suche, eingehende Anrufe, ...) aus diesem Datenbestand. Dieses Telefonbuch unterstützt Vor- und Nachnamen, Firma sowie jeweils zwei Nummern für Arbeit, Mobil und Privat. Das ganze ist ausreichend dokumentiert und einfach zu handhaben.

Zusammengefasst: Hat man eine Nx70 und möchte es einfach halten ist das die erste Wahl.

Alle Gigaset Nxx0 kennen ein LDAP-Adressbuch. Bei N510 und N720 ist das der einzige Weg um Kontakte sinnvoll an die Handsets auszuliefern. Mit sinnvoll meine ich: mehrere Nummern und Firma unter einem Namen zusammengefasst. Bei den Nx70 ist LDAP eine Alternative zum zentralen XML-Telefonbuch.

Gibt es eine Synology im Netz, muss man nur deren LDAP-Server aktivieren und man ist schon fast am Ziel. Hat man einen Linux Server im Netz kann man mit openLDAP arbeiten. Hat man keinen, muss man in einen Rasbberry Pi 3 (reicht) 'investieren' und dort openLDAP installieren. Egal ob Synology LDAP, openLDAP oder Active Directory: Das lässt sich mit Apache Directory Studio ziemlich einfach administrieren.

 

[Jörg Giencke]

Ich hatte es so verstanden, dass du die Daten aus dem 3CX-Telefonbuch ziehst und auf einem OpenLDAP Server importierst.
Eventuell geht ja irgendwann etwas in die Richtung.

Stand 28.11.2021: Gibt es!

Wenn das Skript auf der 3CX läuft, läuft das - nahezu - 'out-of-the-box', wenn das Skript woanders läuft, muss man noch die PostgreSQL Datenbank für Zugriffe von außen öffnen. Letzteres ist in drei Minuten erledigt.

 

[Jörg Giencke]

Zur Zeit können die zusammengesammelten Einträge nur manuell ins 3CX Telefonbuch 'nachgeladen' werden. Das geschieht über den Import der erzeugten 3CX-CSV-Datei. Leider bin ich mit dem direkten Zugriff auf die 3CX Datenbank - um letzteren Schritt zu automatisieren - noch nicht so weit. Da wäre ich für Tipps dankbar.

Das ist Schnee von gestern. Das Skript beherrscht jetzt auch das direkte Schreiben in die 3CX Datenbank.

Kleines 'Problem': 3CX merkt davon nichts und liefert weiterhin beharrlich den alten - irgendwo zwischengespeicherten - Datenbestand aus. Kein wirklicher Beinbruch: Nach einem nächtlichen Cronjob (/usr/sbin/3CXStopServices && /usr/sbin/3CXStartServices) ist der Spuk vorbei und 3CX arbeitet mit den neuen Daten. Das geht sauber über die Bühne und erzeugt auch keine Fehlermeldungen. Die Telefonanlage ist halt für einen kurzen Zeitraum tot. Auf einem Pi 4 für etwa 20 bis 30 Sekunden. Die Telefone merken davon gar nichts, da bleibt alles grün, laufende Telefonate werden allerdings unterbrochen.

An dem 'Problem' haben sich schon andere erfolglos abgearbeitet: "A restart of the 3CX service is necessary, we are currently looking how to avoid it.". An dieser Stelle wie immer die Frage: "Falls jemand einen Tipp hat ... ?".

 

[fxbastler]

An dieser Stelle wie immer die Frage: "Falls jemand einen Tipp hat ... ?".

Es geht einfach nicht anders. Ein SIG zu senden reicht in keinem Fall. Der 3CX Dienst muss neu starten.

wenn das Skript woanders läuft, muss man noch die PostgreSQL Datenbank für Zugriffe von außen öffnen.

Würde ich tunlichst vermeiden wollen. Da geht die Hölle auf da alle Passwörter unverschlüsselt in der DB drin stehen. Daher auch nur lokaler Zugriff.

Spoiler: 3CX DB Zugriff - NICHT SUPPORTED!

# Linux: nano /var/lib/3cxpbx/Bin/3CXPhoneSystem.ini
_dbtable=$(sed -n 's/DBName = \(.*\)/\1/p' /var/lib/3cxpbx/Bin/3CXPhoneSystem.ini)
_dbport=$(sed -n '0,/DBPort = \(.*\)/s//\1/p' /var/lib/3cxpbx/Bin/3CXPhoneSystem.ini)
_dbuser=$(sed -n 's/MasterDBUser = \(.*\)/\1/p' /var/lib/3cxpbx/Bin/3CXPhoneSystem.ini)
_dbpassword=$(sed -n 's/MasterDBPassword = \(.*\)/\1/p' /var/lib/3cxpbx/Bin/3CXPhoneSystem.ini)

echo "127.0.0.1:$_dbport:$_dbtable:$_dbuser:$_dbpassword"   > ~/.pgpass
chmod 600 ~/.pgpass

# ab hier automatische psql login fuer diesen Benutzer moeglich
# kompletter DB Dump
pg_dump -d $_dbtable -h 127.0.0.1 -p $_dbport -U $_dbuser > dbexport.pgsql

# Beispiel für Lesezugriff
psql -d $_dbtable -h 127.0.0.1 -p $_dbport -U $_dbuser -c "
select usv.dn, usv.display_name, usv.iddn, dnp.name, dnp.value from users_view as usv, dnprop as dnp
where usv.iddn=dnp.fkiddn and dnp.name='SERVICES_ACCESS_PASSWORD' and usv.dn='200';"

# alternativ geht natuerlich auch ein Zugriff als user postgresql:
su - postgres -c "psql -d database_single -c \"SELECT BLABLA\""

Auf diese Art ändern wir auch gern mal die SIP Trunks des Dashboard nachträglich von rot auf grün indem wir ein selbst erzeugtes oder ein vom SIP Trunk Provider für 3CX bereitgestelltes Template nach /var/lib/3cxpbx/Instance1/Data/Http/Templates/provider/dts.pv.xml kopieren (ein prominentes Beispiel), dessen owner mit

chown phonesystem:phonesystem /var/lib/3cxpbx/Instance1/Data/Http/Templates/provider/dts.pv.xml

anpassen und das danach in der entspr. SQL Tabelle anpassen:

#  die eingerichteten SIP Trunks alle anzeigen lassen
select idgateway, name, model from public.gateway;

#  bei dem zu ändernen SIP Trunk (Merkmal idgateway) den Eintrag ändern
update public.gateway set model='dts.pv.xml' where idgateway=5;
commit;
quit;

 

[Jörg Giencke]

Würde ich tunlichst vermeiden wollen. Da geht die Hölle auf da alle Passwörter unverschlüsselt in der DB drin stehen. Daher auch nur lokaler Zugriff.

Wenn man da Befürchtungen hat, kann man als erste grobe Gegenmaßnahme den Zugriff auf nur eine Maschine (die, auf der das Skript läuft) beschränken. Wem das nicht reicht, der kann auch noch einen User anlegen, der nur auf die Tabelle phonebook Zugriff hat - bei Bedarf auch nur nur lesend.

 

[Jörg Giencke]

Es geht einfach nicht anders. Ein SIG zu senden reicht in keinem Fall. Der 3CX Dienst muss neu starten.

Gibt es dafür auch einen Grund / eine Erklärung?