Prima!

Mir war auch so, als ob der 60er schon mal in der Vergangenheit irgendwo aufgetaucht war - hatte nur noch keine Zeit das nachzuverfolgen.
Wenn es jetzt läuft, dann ist das ja erfreulich.
Weiter viel Freude mit dem Tool.

Black Senator
 
Hallo Gemeinde, ich bräuchte einmal eure Hilfe.

Habe cardav2fb erfolgreich auf einen aktuellen Linux Mint installiert. Ich habe 3 Fritzboxen mit jeweiliger config.php.
Die Installation liegt in folgendem Verzeichnis: /home/USER/Dokumente/carddav2fb

Wenn ich mich per ssh anmelde und folgenden Befehl ausführe funktioniert alles bestens:

Code:
cd Dokumente
cd carddav2fb
./carddav2fb run -c config_fritzbox_7590.php

Nur weiß ich nicht wie der Befehl im crontab -e auszusehen hat. Folgende Konstellation funktioniert leider nicht:


Code:
0 21 * * * php /home/USER/Dokumente/carddav2fb run -c config_fritzbox_7590.php
0 22 * * * php /home/USER/Dokumente/carddav2fb run -c config_fritzbox_2.php
0 23 * * * php /home/USER/Dokumente/carddav2fb run -c config_fritzbox_3.php

Kann mich bitte jemand korrigieren. Vielen Dank für die Unterstützung.
 
Probier's mal mit vollständigem Pfad zu den Config-Dateien (ohne Gewähr/ungetestet)
Code:
0 21 * * * php /home/USER/Dokumente/carddav2fb run -c /home/USER/Dokumente/config_fritzbox_7590.php
0 22 * * * php /home/USER/Dokumente/carddav2fb run -c /home/USER/Dokumente/config_fritzbox_2.php
0 23 * * * php /home/USER/Dokumente/carddav2fb run -c /home/USER/Dokumente/config_fritzbox_3.php
 
Was kommt denn als Meldung wenn Du direkt nach dem Login einfach nur
Bash:
php /home/USER/Dokumente/carddav2fb run -c /home/USER/Dokumente/config_fritzbox_7590.php
ausführst?
 
Moin,

die Fragestellung ist eigentlich gar keine zum Programm, sonder vielmehr allgemein zu Cron ..., aber im Wiki habe ich beschrieben wie es bei mir funktioniert.

Beste Grüße

Black Senator
 
Ich habe in der jeweiligen User-Crontab nur eine Zeile mit einem Skript, in dem ich auch die Ausführungsumgebung definiert und die Umleitungen für die beiden Ausgaben.
Nicht den Aufruf eines Skriptes, wie hier des PHP-Skriptes.

Auch, weil bei verschiedenen Linux-Systemen die Crontab in verschiedenen Shells mit unterschiedlichen Umgebungen (PATH und Co) laufen kann.
 
Zunächst einmal ein gutes, neues Jahr in die Runde ganz herzlichen Dank für die (Weiter-)Entwicklung und Pflege von carddav2fb .

Ich habe mir vor ein paar Tagen ein paar Cisco 8851 MPP IP Telefone zugelegt und als interne Telefone an meine FB 7590 mit aktueller Fimrware gehängt. Für die "Rückwärtssuche" zur Anzeige der Anrufernamen bei eingehenden Anrufen verwende ich die normalen FB Funktionalität, die bei vorhandenen Einträgen in einem FB Telefonbuch den Namen des Eintrags aus dem FB Telefonbuch an die internen Telefone weiterleitet.

Bei der Suche nach einer eleganten Pflegemöglichkeit des FB Telefonbuchs bin ich auf carddav2fb gestoßen, welches ich nun dazu verwende, die geteilten Adressbücher meiner Nextcloud in ein dediziertes "Nextcloud" Telefonbuch der FB zu übertragen. Das funktioniert tadellos und wird alle paar Stunden durch einen cron Job angestoßen. carddav2fb ist so konfiguriert, dass es über forcedupload = true das dedizierte "Nextcloud" FB Telefonbuch jedes mal überschreibt. Auch das funktioniert perfekt.

Was ich nun allerdings festgestellt habe ist, dass die FB anscheinend nach jeder "Replikation" des Telefonbuchs (also nach jedem Überschreiben der Einträge) die Namen aus dem Telefonbuch bei eingehenden Anrufen nicht an die internen Telefone weiterleitet. In der Anrufliste auf der FB werden die Namen angezeigt, Aber auf den internen Telefonen erscheint nur die Nummer. Fasse ich nun über das Web GUI der FB einen der Einträge aus dem Telefonbuch an (in dem ich z.B. den Nummerntyp eines beliebigen Eintrags von privat auf mobil ändere) und speichere die Änderung, dann werden ab dem Zeitpunkt auch wieder die Namen aller Einträge im Telefonbuch an die internen Telefone weitergeleitet.

Es sieht für mich also fast so aus, als ob die FB nach einem Überschreiben des Telefonbuchs über carddav2fb das Telefonbuch in der Namensweiterleitung ingoriert. Und durch das manuelle Ändern über ihr Web GUI dann aktiviert / berücksichtigt. Hat jemand von euch dieses Phänomen auch schon einmal beobachtet? Falls ja, habt ihr eventuell einen Workaround gefunden, wie man die FB davon überzeugen kann, das Telefonbuch sofort zu verwenden?

Gibt es eventuell irgendeine undokumentierte Funktion der FB, mit der man sie zum Einlesen / Aktivieren neuer Telefonbücher zwingen kann bzw. muss.

Vielen Dank im Voraus für eure Rückmeldungen.

Liebe Grüße,
Ralf
 
Hallo Ralf,

ich kommec erst jetzt dazu ggf. Hilfe anzubieten. Da ich keine vergleichbare HW-Konstellation habe kann ich das nicht replizieren.
Ich würde gerne wissen wollen, ob eine Veränderung an der XML-Struktur und/oder Inhalt, den Trigger setzt, welchen offenbar die FRITZ!Box braucht, um die Synchronisierung vorzunehmen (zu FRITZ!Fon wird sofort nach exterrnem Upload synchronisiert).

Ich kann Dir nur folgendes anbieten bzw. zur Unterstützung der Fehlereingrenzung folgendes Vorgehen vorschlagen:
  1. Als erstes würde mich interessieren, wie sich das System verhält, wenn Du über die GUI ein Telefonbuch hoch lädst. Denn carddav2fb macht nichts anderes, als über exakt die gleiche Schnittstelle den Upload zu schieben. Dafür reicht ein kleines selbst editiertes Telefonbuch gemäß AVM Vorgaben (siehe 5 ff - ein Eintrag <contact> sollte genügen). Wenn das auch zu keinem Sync führt, dann kannst Du nur ein Ticket bei AVM aufgeben und erwarten, dass nichts passiert.
  2. Falls wider Erwarten doch so ein Sync angestoßen wird, dann
    1. nach Upload durch carddav2fb das Telefonbuch aus der GUI heraus lokal speichern
    2. einen (oder mehrere) Einträge, wie von Dir beschrieben editieren und nachdem
    3. das Telefonbuch aus der GUI heraus erneut lokal in anderer XML-Datei speichern
    4. beide Dateien in einen geeigneten Editor laden, welcher XML strukturiert darstellen kann (z.B. Notepad++ mit Add-On)
    5. die gesamte XML-Struktur bzw. die entsprechenden Einträge auf auffällige Veränderungen (vorher - nachher) vergleichen
      wenn Du willst, dann kannst Du mir auch die Files (abgestrippt auf die jeweiligen Einträge und anonymisiert) zusenden (E-Mail im Header von ../src/ReplyMail/replymail.php)
Grüße

Black Senator
 
Zuletzt bearbeitet:
Hallo Black Senator,

zunächst einmal vielen Dank für deine Antwort und den Ideen bezüglich XML Im-/und Export des Telefonbuchs. Das hat ein weiteres Universum an Testmöglichkeiten eröffnet. Aber der Reihe nach.

Nach meinem ersten Foren Eintrag hatte ich weitere Versuche unternommen um das Problem einzugrenzen.

Dabei bin ich auf eine zusätzliche, zeitabhängige Komponente gestoßen, die die Untersuchung weiter verkompliziert. Ich habe festgestellt, dass die Namensauflösung (kurz für die Zuordnung und Weiterleitung des Namens einer anrufenden Telefonnummer anhand eines Telefonbucheintrags) für neue Telefonbucheinträge (neue Telefonnummer und neuer Name) innerhalb der ersten 24h nach dem ersten Import durch carddav2fb in die FB funktioniert. Sprich, wenn ich einen neuen Telefonbucheintrag anlege, den nächsten Importzyklus durch carddav2fb abwarte (oder manuell auslöse) und danach dann zeitnah von der Nummer des Telefonbucheintrages angerufen werden, klappt alles.

Ferner scheint es so, dass Nummern, für die einmal eine Namensauflösung geklappt hat, ab diesem Zeitpunkt immer aufgelöst werden.

Beide Punkte erschweren das Testen enorm, da dadurch eine einmal aufgelöste Nummer "verbrannt" ist und für weitere Tests nicht mehr verwendet werden kann. Außerdem muss ich deshalb vor jedem Test mit einer neuen Nummer quasi 24h warten.

Doch genug des Jammerns und hin zu deinen Vorschlägen.

Zunächst einmal ist es so, dass so bald ich das Telefonbuch über das GUI exportiere, die darin befindlichen Einträge "aktiviert" sind, also die Namensauflösung funktioniert, auch für Einträge die bis zum Export noch nicht funktioniert hatten. Was ich in Ermangelung ausreichender Testrufnummern noch nicht prüfen konnte ist, ob diese Aktivierung für jungfräuliche Nummern nach 24h wieder verschwindet, falls in dieser Zeit kein Anruf erfolgt, oder permanent ist.

Die exportierten Einträge sehen im Prinzip alle identisch aus, unabhängig davon, ob sie funktionieren oder nicht. Abweichend zu der von dir verlinkten AVM Dokumentation hängen an einigen Elementen zusätzliche Attribute, die vermutlich die Anzahl der Unterelemente einer Elementgruppe enthalten und jedem der Unterelemente eine eindeutige ID zuordnen. Das Attribut für die Anzahl der Unterelemente heißt nid, das der einzelnen Unterelemente id. Die id wird innerhalb jeder Untergruppe fortlaufend vergeben, startend bei 0 für das erste Unterelement der Untergruppe. Das übergeordnete nid Element spiegelt in der Regel die Anzahl der ids der Untergruppe wider, ist aber bei einigen Einträgen eins zu niedrig (Beispiel, ein Element hat vier Unterelemente mit id 0 bis 3, das nid Attribut steht jedoch auch 3 statt auf 4). Bei Gruppen mit nur einem Unterlement stimmen die Attributwerte immer (nid = 1, id = 0).

Anonymisierte Auszug aus einem Export:

Code:
<?xml version="1.0" encoding="utf-8"?>
<phonebooks>
    <phonebook name="Nextcloud" owner="1">
        <contact>
            <carddav_uid>2aa285a0-c193-4932-bfdb-80b18c6f5bef</carddav_uid>
            <telephony nid="1">
                <number id="0" type="home" prio="1">065439999999</number>
                <number id="1" type="mobile">015477777777</number>
            </telephony>
            <services nid="1">
                <email id="0" classifier="home">[email protected]</email>
            </services>
            <person>
                <realName>Eintrag Eins</realName>
            </person>
            <uniqueid>6151</uniqueid>
        </contact>
        <contact>
            <carddav_uid>96fe610d-24e6-4a45-ab6c-9e297ff9f748</carddav_uid>
            <telephony nid="3">
                <number id="0" type="home" prio="1">062227777</number>
                <number id="1" type="mobile">015155555555</number>
                <number id="2" type="fax_work">062227777778</number>
            </telephony>
            <services nid="1">
                <email id="0" classifier="home">[email protected]</email>
            </services>
            <person>
                <realName>Eintrag Zwei</realName>
            </person>
            <uniqueid>6142</uniqueid>
        </contact>
        <contact>
            <carddav_uid>655480aa-163b-4456-90d7-d110f4a1f7a4</carddav_uid>
            <telephony nid="3">
                <number id="0" type="home" prio="1">06333888888</number>
                <number id="1" type="work">06333888887</number>
                <number id="2" type="mobile">01727777777</number>
                <number id="3" type="fax_work">063338888886</number>
            </telephony>
            <services nid="3">
                <email id="0" classifier="home">[email protected]</email>
                <email id="1" classifier="home">[email protected]</email>
                <email id="2" classifier="home">[email protected]</email>
            </services>
            <person>
                <realName>Eintrag Drei</realName>
            </person>
            <uniqueid>6147</uniqueid>
        </contact>
    </phonebook>
</phonebooks>

Allerdings scheinen die falschen nid Werte keinen Einfluss auf die Namensauflösung zu haben, da diese auch für Einträge funktioniert, bei denen die nid 3 anstelle von 4 ist.

Importiere ich eine exportiertes Telefonbuch und exportiere es danach erneut, dann ist der einzige Unterschied, dass die <uniqueid> Elementwerte aufsteigend sind, während sie bei direkt exportierten nicht sortiert sind. Grundsätzlich werden bei jedem Export neue <uniqueid> Werte ausgegeben, unabhängig davon ob über carddav2fb oder über das GUI importiert wurde.

Aber bisher sieht es so aus, als ob keines der Elemente bzw. Attribute einen Einfluss darauf hat, ob die Namensauflösung geht oder nicht.

Momentan scheint es so, als ob der Schlüssel die zeitabhängige Aktivierungsfrist zu sein scheint. Diese konnte ich bisher entweder durch den erstmaligen Import eines neuen Telefonbucheintrages für diesen Telefonbucheintrag auslösen, oder durch den Export des gesamten Telefonbuchs für alle Telefonbucheinträge. Wie bereits geschrieben scheint diese Frist bei 24 Stunden zu liegen, exakt eingekreist habe ich sie aber aufgrund der begrenzten Testmöglichkeiten noch nicht (eventuell ist sie auch geringer).

Gestern habe ich mir bei fonial einen Testaccount mit 3 externen Testrufnummern angelegt, mit denen ich nun hoffentlich etwas einfacher testen kann. So bald ich irgendwelche belastbaren Erkenntnisse habe werde ich berichten.

Nochmals Danke für deine Unterstützung.

Liebe Grüße,
Ralf

P.S.: Habe gerade eben als quick and dirty workaround in der 'execute' Funktion einen abschließenden download des hochgeladenen Telefonbuchs angehängt, in der Hoffnung, dass dieser genauso wirkt, wie ein Export über das GUI oder per TR064 (was beides die Aktivierung bewirkt). Jetzt tickt die 24 Stunden Uhr und morgen um die Zeit bin ich hoffentlich schlauer.
 
Zuletzt bearbeitet:
Jetzt tickt die 24 Stunden Uhr und morgen um die Zeit bin ich hoffentlich schlauer.
Und? Gibt es neue Erkenntnisse?

Da es ja vermutlich nicht an carddav2fb liegt, würde ich empfehlen deine Frage in dem Cisco-Forum zu posten. Evtl. liest da eher jemand mit der eine ähnliche Konstellation hat und über den Trigger für die Synchronisation etwas berichten kann.

Grüße

Black Senator
 
Hallo Black Senator,

die gibt es in der Tat, wobei der Langzeittest noch läuft. Mit den Cisco Telefonen hat das Problem nichts zu tun, denn die Namensweiterleitung bei Anrufen im SIP Header findet ja durch die Fritz!Box statt. Eventuell habe ich mich bei meinen Beschreibung etwas missverständlich ausgedrückt. Es geht quasi um das caller id forwarding der FB auf der Basis der Telefonbucheinträge in der FB an interne Telefone. Das Thema ist ein FB Problem. Es tritt genau so bei jedem anderen IP Telefon Client auf (wobei ich das nur mit Softphones geprüft habe) und vermutlich auch bei ISDN Telefonen (aber die habe ich inzwischen bei mir alle rausgeworfen).

Mein erster Ansatz, das Telefonbuch nach dem Hochladen durch carddav2fb über die Funktion downloadPhonebook() gleich wieder runterzuladen hat nichts geändert. Woraus sich schließen lässt, dass Änderungen am Telefonbuch über "/cgi-bin/firmwarecfg" von der FB anders behandelt werden, als welche die per GUI oder TR-064 erfolgen. Deshalb habe ich downloadPhonebook() durch getPhonebook() aus deiner fritzsoap Library getauscht (auch hierfür ganz lieben Dank). Dieser Tausch hat dann den gewünschten Effekt erzielt und die Namensweiterleitung für sämtliche neuen, innerhalb von 24h nicht per Anruf aktivierten Telefonbucheinträge aktiviert.

Ohne mich weiter in die Interna der FB einzugraben vermute ich, dass einer der am caller id forwarding beteiligten Daemons beim GUI / TR-064 Export die Einträge im Telefonbuch einliest und sich in einer internen Datenstruktur abspeichert, wodurch sie aktiviert sind. Wird das hingegen per "/cgi-bin/firmwarecfg" gemacht, dann passiert das wohl nicht (oder nicht vollständig). Die "temporäre Aktivierung" für 24h nach dem Import per "/cgi-bin/firmwarecfg" erklärt das leider nicht.

Da ich aber nicht noch weitere Nächte meines Lebens mit Ursachenforschung verbringen möchte, werde ich wohl nun einfach meinen Workaround als Dauerlösung beibehalten. Ich kann mir auch nur schwer vorstellen, dass von AVM irgendeine Art Rückmeldung oder Unterstützung käme, wenn man sie auf dieses Thema ansprechen würde.

Wie du bereits geschrieben hast ist es kein carddav2fb Problem. Das funktioniert wie beschrieben, deckt aber meinen Anwendungsfall aufgrund des beschriebenen Verhaltens der FB nicht vollständig ab. Sollte ich den Eindruck erweckt haben, carddav2fb zu verdächtigen, war das vollkommen unbeabsichtigt und tut mir leid.

carddav2fb und fritzsoap laufen wie beschrieben und haben mir letzten Endes ermöglicht meinen "edge case" umzusetzen. Nochmals Danke für all die Arbeit, die du da reingesteckt hast und auch für deine Idee, in Richtung XML Im-/Export zu schauen.

Ich widme mich nun einer der vielen anderen Baustellen, die ich - wie wir alle - sonst noch so habe.

Liebe Grüße,
Ralf
 
  • Like
Reaktionen: Black Senator
Meiner Erfahrung nach liefert die Fritz!Box unterschiedliche Telefonbücher. Über die Action GetPhonebook liefert ein abgespecktes Telefonbuch im Vergleich zum Telefonbuch, welches über die WebGUI heruntergeladen werden kann. Auch das Herunterladen eines einzelnen Kontaktes via GetPhonebookEntryUID bzw. GetPhonebookEntry liefert weitere Daten (z. B. Zeitstempel der letzten Aktualisierung)

Ich habe es nicht mehr vor Augen, was passiert, wenn unterschiedliche Telefonbücher/Einträge hochgeladen wird und wie sich die Box verhält.
 
Moin,

ich habe gestern nach längerer Zeit (ca. 1 Jahr) mal wieder ein Update von carddav2fb gemacht.
Jetzt habe ich daß problem, daß ich keine Background-Images mehr hoch geladen bekomme - das Komando
Code:
php carddav2fb background-image -c ./christoph.php
endet immer mit (ausführlich mit debug-Option)
Code:
Uploading background image to FRITZ!Fon #613
*   Trying 192.168.1.1:80...
* Connected to 192.168.1.1 (192.168.1.1) port 80 (#0)
> POST /cgi-bin/firmwarecfg HTTP/1.1
Host: 192.168.1.1
User-Agent: GuzzleHttp/7
Authorization: Basic xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Content-Length: 87531

* We are completely uploaded and fine
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Connection: close
< Content-type: text/html; charset=utf-8
< Date: Mon, 25 Mar 2024 12:11:00 GMT
< X-Frame-Options: SAMEORIGIN
< X-Content-Type-Options: nosniff
< Content-Security-Policy: default-src 'none'; connect-src 'self'; font-src 'self'; frame-src https://service.avm.de https://fritzhelp.avm.de/help/ ht
tps://help.avm.de https://www.avm.de https://avm.de https://assets.avm.de https://clickonce.avm.de http://clickonce.avm.de http://download.avm.de http
s://download.avm.de 'self'; img-src 'self' https://tv.avm.de https://help.avm.de/images/ http://help.avm.de/images/ data:; script-src 'self' 'unsafe-i
nline'; style-src 'self' 'unsafe-inline'; frame-ancestors 'self'; media-src 'self'
<  
* Closing connection 0
Background image upload failed

Alles andere funktioniert (wieder) wie gewünscht ...

Gruß
Christoph
 

Zurzeit aktive Besucher

Statistik des Forums

Themen
245,827
Beiträge
2,240,725
Mitglieder
373,092
Neuestes Mitglied
mueschol
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.