Posts by Ulf

    christian:

    In vergleichbaren, wenn auch seltenen Fällen war hier das Thema Werksreset und auch mehrfaches Neusetzen und manuelles Eintragen über die Weboberfläche der betroffenen Telefone die letztliche Lösung. Warum insbesondere Yealink-Telefone ab und ab mal diesen Effekt aufweisen, ist nie klärbar gewesen. Was tatsächlich hier immer wieder mal - wenn auch eben im Verhältnis sehr selten auftritt (speziell bei Yealink und den älteren Geräten), dass man das Passwort zum Telefonkonto neu setzen musste und explizit in der Weboberfläche (die man dann natürlich erreichen können muss) manuell nachgetragen hat.

    Was ich allerdings eher nicht verstehe ist die Aussage, dass man nicht auf die Weboberfläche der Geräte zugreifen kann - das nach einem Werksreset natürlich zunächst wieder das ursprüngliche Standard-Passwort gesetzt ist, ist beachtet? Verschlüsselung in den Einstellungen für Yealink an oder aus? Und wurde testweise die Passwortvorgabe (auf der Starface) mal in den Ursprungszustand und auch mal in eine einfachere Angabe (z.B. nur Zahlen o.ä.) geändert?

    Beschrieben ist, dass Anrufe bei den Telefonen nicht klingeln - was heißt das genau: kann man von den Geräten ausgehend telefonieren, oder nicht? Wie werden die Geräte denn in der Starface signalisiert: als verbunden?

    Hallo Zusammen,

    wir haben einen Kunden, der den Wechsel von 7 auf 8 noch aktuell scheut, da er nicht weiß, ob seine müsam entwickelten Module weiterhin zuverlässig laufen oder es eben Anpassungen geben muss.

    Es ist wohl eine ganze Menge an Modulen...

    Wir sind nicht auf dem Stand, dies zu leisten - wer könnte helfen?

    Danke vorab :)

    Fabian hat grundsätzlich recht - wenn aber Hilfe gebraucht wird, kann man sich das ansehen - der Betreffende kann sich gerne mal melden. Kontakt entweder hier per PN, oder über unseren Modulshop (Kontakt).

    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

    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.

    ... 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.

    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.

    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.

    slu

    .... und ich will ja ncht ganz pessimistisch sein, aber gerade in Zeiten von zunehmenden Cyberangriffen aufgrund der weltpolitischen Lage und ein paar Verrückter da draußen, ist es noch wichtiger, solche echten Schwachstellen zu elimieren. Wie schnell kann das Szenario eintreffen, wo ein Rechenzentrum XY, ein Vordienstleister oder was auch immer von so einem Angriff betroffen ist und bei aktuellem Konstrukt unnötigerweise gleich mal Anlagen (um das nur auf unser Umfeld herunterzubrechen) in ganz Deutschland (u.a.) nur noch teilweise bedien- oder nutzbar sind?

    Geteiltes Leid soll ja angeblich halbes Leid sein - aber in dem Fall entstünde dann bei einer großen Zahl von Nutzern absolut unnötiges Leid ...

    Das ist halt der Preis von Cloud und alles bei einem Anbieter!

    Unsere Anlage On-Premise läuft, auch der SIP Trunk (nicht von Starface, sorry) läuft ohne Probleme.

    Ohne Forum hätte ich gar nichts von der Störung mitbekommen...

    slu:

    Damit das nicht falsch verstanden wird:

    Die Anlagen hier in unserem Umfeld "laufen", auch die SIP-Trunks sind verfügbar - allerdings ist mind. keine Leitungskonfiguration möglich - das dann völlig unabhängig davon, ob der Kunde Starface Connect nutzt oder nicht. Zudem gibt es im Bereich Lizenzen eben jene Fehlermeldung (Letzteres ist dabei noch halbwegs erwartbar gewesen und sollte ein paar Tage lang keine Rolle spielen).

    Mich würde es jetzt wirklich wundern, wenn Du diese Effekte nicht hast - bei unseren Kunden liegt keine einzige Starface in der Cloud bei Starface selbst, sondern es handelt sich durchgehend um Appliances (die dann allerdings mit Starface 6.x und älter, da nicht updatefähig u.ä.) und die große Mehrzahl in aktueller SF-Version hosten wir selbst. Die Kunden haben allesamt verschiedenste Trunks, die wie gesagt funktionieren, sich aber gar nicht konfigurieren lassen (Leitungskonfiguration ist nicht aufrufbar).

    Genau auch mit Blick auf diesen 2. Punkt ist die sich dann plötzlich zeigende Abhängigkeit von einer (!) externen Instanz - sagen wir mal: "etwas erschreckend". Zumind. war in dieser Form nicht davon auszugehen / wir haben ja schon bewusst versucht, unnötige Abhängigkeiten zu umschiffen.

    Zwischenzeitlich / im Moment scheint das Ganze wieder zu funktionieren - Gedanken, wie man diesen Punkt verbessern kann, sollte man sich im Nachgang aber wohl schon nochmal machen. Und eben eine Info an die Partner wäre absolut wünschenswert gewesen - insbesondere bei so lange andauernden Störungen.

    @Starface: vielleicht wäre eine Info an die Partner gut, bevor die in der Fehlersuche wegen plötzlich nicht funktionierenden Funktionen versinken / der Zusammenhang zur Störung bei Euch ist zunächst mal schwer bis gar nicht erkennbar, man merkt es nur, wenn man ganz viele Anlagen betreut die ein wenig übers Land oder mind. verschiedene Hosts verteilt sind.

    Schlimmerweise funktionieren auch gar nicht bei Starface gehostete Starfaces aktuell nicht richtig. Neben der schon benannten Fehlermeldung gibt es auch den Effekt, dass die Anlagen in bestimmten Punkten, wie z.B. der Leitungskonfiguration aktuell nicht nutzbar sind, andere Punkte, wie Benutzer- und Gruppenkonfiguration sind nutzbar ...

    Das fühlt sich jetzt alles Andere als gut an, wenn Störungen bei Starface dann auch nach Außen solche Auswirkungen hat - das sollte gar nicht sein.

    Ganz offenkundig ist auch der Lizenzserver betroffen - ruft man bei beliebigen Starface-Installationen (auch aktuelle 8.1.2.2) im Bereich Server den Punkt Lizenzen auf, bekommt man aktuell folgende Meldung:

    "Interner Serverfehler: Bitte vergewissern Sie sich, dass eine Verbindung zum Internet hergestellt ist und „https://license.starface.de%e2%80%9c erreicht werden kann."

    Bei einer ältere 6er-Version der Starface sieht die Fehlermeldung so aus:

    "Interner Serverfehler: "javax.xml.ws.WebServiceException: Failed to access the WSDL at: https://license.starface.de/starface/LicenseWebService_V3?wsdl. It failed with: No route to host (Host unreachable)." Bitte vergewissern Sie sich, dass eine Verbindung zum Internet hergestellt ist und die Adresse 'https://license.starface.de' erreicht werden kann."

    Wir bieten so eine Integration in den UCC-Client (PC/MAC) an - zumindest für den Versand von SMS. Bei Bedarf kann der Service auch in Module integriert werden, mit denen z.B. bestimmte Ereignisse abgefragt und dann per SMS informiert werden kann.

    Bei der Integration in dem Client kann man via Eingabeformular Nachrichten verfassen, frei adressieren und versenden. Der Versand erfolgt über eine fest-integrierte SMS-Anbindung.

    Eine ähnliche Lösung gibt es auch über Drittanbieter-Hardwaregateways zum Versand von SMS über eigene SIM-Cards und Verträge ... alles ist im Grunde denkbar.

    Lösungen im Rechenzentrum oder der Starface-Cloud sind in der Regel erstgenannte Umsetzung, wobei beim Hosten in div. Rechenzentren je nach Anbieter sicher auch ein Einsatz über ein Hardware-Gateway möglich ist. Für lokale Installationen ist Beides problemlos einsetzbar.

    Hallo Dirk,

    wir haben hier bzgl. der verfügbaren Kerne alle möglichen Kombinationen über 2, 4 bis 16 Kerne - beobachten kann man die Problematik m.E. völlig unabhängig davon (die Virtualisation mit 16 Kernen muss mal außen vor bleiben, da dort noch SF 6.7 läuft, was das Problem eh nicht hat.

    Bezüglich der NTP-Server hatte ich auch bereits getestet - es ist da offenbar wurscht ob man die vorgegebenen nutzt oder wie hier eigentlich üblich die im RZ eigenen. Auch das macht keinen Unterschied.

    Das ausfallen lassen eines Backups nach einen Serverneustart wäre eine theoretische Idee, birgt aber vermutlich auch wieder Gefahren, zumindest aber würde es im Bereich der Virtualisierungen dafür sorgen, dass es keine der eventuell kritischen Überschneidungen gäbe.

    Wie ist das denn eigentlich bei der Zeitumstellung Sommer-/Winterzeit geregelt? Da hätten wir ja auch plötzlich eine Zeitdifferenz vor einem geplanten Backupintervall?!

    Fabian / slu:

    Das vorgeschlagene Szenario habe ich hier aktuell noch nicht testen können (rein zeitlich/organisatorische Gründe). Danke aber für das Mitdenken und Mitsuchen (Starface ist auch dran ...).

    Es scheint bisher relativ egal zu sein, wann ein Serverneustart erfolgt - ob das 1-2 oder 5 Stunden bzw. noch länger davor passiert und sogar ein Tageswechsel dazwischen kommt, spielt offenbar keine Rolle. Tatsächlich gab es jene Neustarts in aller Regel eher auch gar nicht kurz vor einem Backup.

    slu:

    Aufgefallen ist mir das u.a. auch nur ganz zufällig im Rahmen eines nötigen Neustarts vieler virtualisierter Starfaces wegen eines Hardwareproblemes, bzw. auch im Zusammenhang notwendiger, gelkegentlicher Host-Updates. Zudem tritt das auf dem gleichen System vor 8.x ja gar nicht auf, konnte also vorher noch nie beobachtet werden.

    Ich bin zuversichtlich, dass wir das gemeinsam gelöst bekommen (bzw. das Ganze innerhalb der Starface zu lösen ist), zumal das wie schon gesagt gar nicht so banal ist, wie das vielleicht auf ersten Blick aussieht.

    Hallo Ulf! Danke für Deine Rückmeldung! Bei uns scheint der Keepalive entweder per Default oder über die Autoprovisionierung auf 20 Sekunden zu stehen… Das scheint mir ein passender Wert zu sein. Merkwürdig ist bei uns, dass bei beiden die Ports separat voneinander "togglen" zwischen "Registered" und "Not Registered". Verhält sich das bei Euch stabiler? Nutzt Ihr die Firmware 1.0.45.2 oder höher?

    Herzlich,

    Christian

    KeepAlive steht hier auf 30 / Options = 3 und entsprechend "Enable SIP OPTIONS/NOTIFY Keep Alive" bei OPTIONS auf On.

    Firmware ist 1.0.41.2