[Behoben in SF 8.1.3.x] Starface 8.1.0.11 | Funktionstaste Rufumleitung verliert immer wieder den Haken bei der betreffenden Nummer

  • Update 8.1.2.2 ist raus.

    Ist der Fehler mit dem BLF tasten hiermit behoben?

    Nein, leider noch nicht. :(

    Soweit mir bekannt ist das Problem aus SC-6356 noch in Untersuchung, da die eigentliche Ursache leider bisher immer noch unklar ist. Auf unseren Testsystem im Labor lässt es sich nicht reproduzieren. Bei den untersuchten betroffenen Kundensystemen ließ sich bisher keine Gemeinsamkeit feststellen, welche als Auslöser in Frage kommt.

    Wir hatten zuerst Drittmodule im Verdacht, aber das scheint es nicht zu sein, zumindest sind bei einigen betroffenen Systemen zum Zeitpunkt des Auftretens keine Drittmodule aktiv gewesen. (was natürlich nicht 100% ausschließt, dass irgendwann zuvor einmal durch Drittmodule oder von Hand etwas in der Datenbank geändert wurde)

    Sollte dennoch jemand feststellen, dass sich an dem Thema seit 8.1.2.2 (unbeabsichtigt) etwas geändert hat, wären wir für Hinweise dankbar.

    Presales Manager

    STARFACE GmbH | Adlerstraße 61 | 76137 Karlsruhe | https://www.starface.com

    Edited 3 times, last by areeh (February 29, 2024 at 9:10 AM).

  • Wir hatten zuerst Drittmodule im Verdacht, aber das scheint es nicht zu sein, zumindest sind bei einigen betroffenen Systemen zum Zeitpunkt des Auftretens keine Drittmodule aktiv gewesen. (was natürlich nicht 100% ausschließt, dass irgendwann zuvor einmal durch Drittmodule oder von Hand etwas in der Datenbank geändert wurde)

    Das bringt mich auf eine neue Idee welche ich noch nicht reproduziert habe, das ist aber naheliegend.

    Was passiert wenn man dem Benutzer eine Umleitung für eine Gruppe anlegt und diesen in der Gruppe deaktiviert, könnte das dieses Problem verursachen?

  • Ich kann das Problem in unserer Umgebung bestätigen.
    Starface-Cloud Server 8.1.2.2 MacOS UCC Client 8.1.0 (823) Beta ebenso wie Stable.
    Dinge wie Server und Client Restarts, Tasten neu anlegen helfen nicht, bzw. nur zeitweise.
    Ein paar Beobachtungen:
    - Nach ca 48h haben bei uns die meisten Rechner ihre Tasten wieder verloren.
    - Es ist nicht immer dasselbe Subset an Rechnern betroffen. Manche erhalten ihre Tasten über längere Zeit.
    - Wenn ein Benutzer betroffen ist, dann immer alle seine Tasten auf einmal.

    Dieses zufällige Verhalten deutet schon ein wenig darauf hin dass es damit zu tun haben könnte wer, wann, abwechselnd welche Tasten benutzt.

  • Nein, leider noch nicht. :(

    Soweit mir bekannt ist das Problem aus SC-6356 noch in Untersuchung, da die eigentliche Ursache leider bisher immer noch unklar ist. Auf unseren Testsystem im Labor lässt es sich nicht reproduzieren. Bei den untersuchten betroffenen Kundensystemen ließ sich bisher keine Gemeinsamkeit feststellen, welche als Auslöser in Frage kommt.

    Wir hatten zuerst Drittmodule im Verdacht, aber das scheint es nicht zu sein, zumindest sind bei einigen betroffenen Systemen zum Zeitpunkt des Auftretens keine Drittmodule aktiv gewesen. (was natürlich nicht 100% ausschließt, dass irgendwann zuvor einmal durch Drittmodule oder von Hand etwas in der Datenbank geändert wurde)

    Sollte dennoch jemand feststellen, dass sich an dem Thema seit 8.1.2.2 (unbeabsichtigt) etwas geändert hat, wären wir für Hinweise dankbar.

    Leider häufen sich unsere Kundenanfragen zu dem Thema, so das wir alsbald auf eine Lösung hoffen.

  • Zusätzliche Information:

    Bei uns ist nur ein KX-HDV330 und ansonsten nur das WebGUI als Taste involviert.

    Es kann passieren das der Benutzer kurzzeitig nicht in der Gruppe ist, das ist auch mein Verdacht warum die Taste "kaputt" geht.

  • Haben das gleiche Problem bei einem Kunden... Bleiben wir in er Web-Version funktionieren die Aktivierungen ohne Probleme - auch Benutzer-übergreifend. Die hinterlegten Taten auf den Telefonen verlieren allerdings die Einstellungen und sind nicht mehr nutzbar...

    Auch unser Kunde wird so langsam ungeduldig und wir hoffen zumindest mal auf eine zeitnahe Auskunft, wann wir mit einer Lösung rechnen können.

  • Nein, leider noch nicht. :(

    Soweit mir bekannt ist das Problem aus SC-6356 noch in Untersuchung, da die eigentliche Ursache leider bisher immer noch unklar ist. Auf unseren Testsystem im Labor lässt es sich nicht reproduzieren. Bei den untersuchten betroffenen Kundensystemen ließ sich bisher keine Gemeinsamkeit feststellen, welche als Auslöser in Frage kommt.

    Wir hatten zuerst Drittmodule im Verdacht, aber das scheint es nicht zu sein, zumindest sind bei einigen betroffenen Systemen zum Zeitpunkt des Auftretens keine Drittmodule aktiv gewesen. (was natürlich nicht 100% ausschließt, dass irgendwann zuvor einmal durch Drittmodule oder von Hand etwas in der Datenbank geändert wurde)

    Sollte dennoch jemand feststellen, dass sich an dem Thema seit 8.1.2.2 (unbeabsichtigt) etwas geändert hat, wären wir für Hinweise dankbar.

    @Starface:

    Nachdem sich zwischenzeitlich auch hier ein Kunde zu diesem Problem gemeldet hat (hier verschwinden alle Einstellungen zu gesetzten / aktiven Modulen mind. an Yealink-Telefonen, bleiben aber in Wirklichkeit aktiv, wenn man sich die Funktionalität auf der Starface im Webfrontend anschaut), habe ich mal etwas gesucht und mind. einen möglichen Auslöser (nicht die Ursache) für diesen Effekt finden können:

    Sobald auf dem betroffenen System ein Dienste- oder Serverneustart ausgeführt wird, hat man genau das beschriebene Problem - das ist hier 100% reproduzierbar. Damit kommen manuelle Aktivitäten, die sowas bedingen oder natürlich auch diverse Module zumindest als "Auslöser" in Frage - das Thema hat man dann z.B. schon bei nötigen Neustarts nach Aktualisierung von Zertifikaten auf der Starface (...).

    In meinem Beispiel habe ich das zwischenzeitlich mal mit einem alten und einem aktuellen Yealink getestet - der Effekt ist immer gleich.

    Wichtig dabei: die eigentliche Funktionalität ist hier wohl nicht betroffen, lediglich die Anzeige des aktuellen BLF-Status am angeschlossenen Tischtelefon stimmt nicht. Die Darstellung in der Premium-App oder im Webfrontend sind korrekt und die Funktion scheint wohl auch gegeben.

    Startet man dann das betroffene Telefon neu, wird auch die Einstellung der BLFs wie die für diesen Benutzer gesetzt sind, korrekt übernommen. Ob sich das jetzt nur auf Yealinks beschränkt oder auch andere Modelle betroffen sind, habe ich noch nicht testen können.

    Ergänzung dazu:

    Gerade noch gesehen - behebt man den Zustand der fehlenden BLF-Stati auf einem (!) der hier betroffenen Yealinks, wird das sofort auch bei allen anderen (hier vorhandenen) Yealinks korrigiert. Laut Kunden mit älterem Gerät reicht dazu wohl schon ein Drücken der dort noch vorhandenen OK-Taste eines T46.

  • Ergänzung - gerade noch gesehen:

    Am Yealink T57W wird überdies auch die Uhrzeit nicht korrekt gesetzt - trotz scheinbar korrekter Einstellungen und richtiger Zeit auf der betreffenden Starface wird aktuelle Zeit +1h angezeigt. Tatsächlich lässt sich das nur korrigieren, wenn man auf dem Telefon die Vorgabe nach Provisionierung "Sommerzeit automatisch" deaktiviert ...

    Leider ist mir das erst jetzt aufgefallen -- ich kann nicht sagen, ob das erst jetzt neu auftritt (diese Woche wäre ja die Umschaltung zur Sommerzeit dran), oder schon vorher - also mit Übermittlung der aktuell verwendeten Firmware so ist.

    Spannenderweise habe ich mal unseren lokalen Zeitserver eingetragen, der definitiv die richtige Zeit ins LAN setzt - auch da stimmt die Anzeige nicht, es scheint mind. zusätzlich ein Problem mit der eingesetzten Firmware (96.86.150.5) des Yealink zu bestehen. Setzt man Sommerzeit auf "deaktiviert", stimmt die Zeit sofort.

    Auch spannend: nach testweisen Rücksetzen des T57W auf Werkseinstellungen und neuem Anmelden an die betreffende Starface sind nicht sofort alle EInstellungen korrekt angekommen (keine Passwörter - weder für den Admin, noch den User oder den Telefonaccount auf der Starface). Da läuft aktuell offenkundig noch etwas mehr schief.

  • ... und noch etwas mehr Infos zu dem BLF-Problem:

    Das tritt definitiv nur nach Server- oder Diensteneustart der Starface auf. Danach hilft bei div. Versuchen weder ein neues Autoprovisionieren, noch ein Neustart des Telefones aus dem Menü oder dem Web-Backend des Admins. Insofern man aber entweder am Telefon das BLF z.B. einer Modulfunktion drückt oder den gleichen Vorgang 1x an der Starface initiiert, ist es danach komplett egal, ob man das Telefon neustartet, neu Provisioniert oder gar mal stromlos macht / vom LAN trennt - dann funktioniert das immer korrekt und mit richtig übertragenem BLF-Status.

    Das davor angesprochene Zeitanzeigeproblem (zumindest beim T57W) bleibt unbenommen davon bestehen - das scheint ein zusätzliches/anderes Problem zu sein.

  • Für mich ist das der gleiche Datenbankfehler, der auch bei den Gruppen selbst zuschlägt.

    Das Thema hatte ich mir bei den betroffenen Kunden auch angeschaut und konnte das hier allerdings so nicht bestätigen. Womit ich aber nicht sagen will, dass da nichts ist - möglicherweise spielen ja noch andere Dinge da rein, die hier nur nicht zutreffen.

  • Ergänzung - gerade noch gesehen:

    Am Yealink T57W wird überdies auch die Uhrzeit nicht korrekt gesetzt - trotz scheinbar korrekter Einstellungen und richtiger Zeit auf der betreffenden Starface wird aktuelle Zeit +1h angezeigt. Tatsächlich lässt sich das nur korrigieren, wenn man auf dem Telefon die Vorgabe nach Provisionierung "Sommerzeit automatisch" deaktiviert ...

    Leider ist mir das erst jetzt aufgefallen -- ich kann nicht sagen, ob das erst jetzt neu auftritt (diese Woche wäre ja die Umschaltung zur Sommerzeit dran), oder schon vorher - also mit Übermittlung der aktuell verwendeten Firmware so ist.

    Spannenderweise habe ich mal unseren lokalen Zeitserver eingetragen, der definitiv die richtige Zeit ins LAN setzt - auch da stimmt die Anzeige nicht, es scheint mind. zusätzlich ein Problem mit der eingesetzten Firmware (96.86.150.5) des Yealink zu bestehen. Setzt man Sommerzeit auf "deaktiviert", stimmt die Zeit sofort.

    Auch spannend: nach testweisen Rücksetzen des T57W auf Werkseinstellungen und neuem Anmelden an die betreffende Starface sind nicht sofort alle EInstellungen korrekt angekommen (keine Passwörter - weder für den Admin, noch den User oder den Telefonaccount auf der Starface). Da läuft aktuell offenkundig noch etwas mehr schief.

    Bitte sowas in den passenden Beiträgen kommentieren oder neuen Beitrag erstellen.

    Das thema wird hier sonst untergehen

  • Bitte sowas in den passenden Beiträgen kommentieren oder neuen Beitrag erstellen.

    Das thema wird hier sonst untergehen

    :) ... zu dem Zeitpunkt als ich das ergänzt hatte, war (mir) noch nicht klar, dass es nicht im Zusammenhang mit dem anderen - hier besprochenen Problem im Zusammenhang steht - "passende andere Beiträge" gab es da noch nicht und wie gesagt - dass es sich um getrennte Dinge handelte, war noch unklar, sonst hätte ich auch natürlich getrennte Themen eröffnet ...

    Sorry

  • Hallo liebe Partner,

    vielen Dank für eure zahlreichen wertvollen Beiträge und Beobachtungen zu dem Thema.

    Wir sind hier nun auch ein gutes Stück weiter gekommen, sodass ich euch heute mitteilen darf, dass die Problematik mit dem nächste Service Release in Q2 gefixt wird.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!