Posts by Ulf

    Ohnehin kann ich unzählige SIP-Einwahlversuche auf der Starface beobachten. Genauso wie gescheiterte Login-Versuche.

    Das beobachte ich allerdings seit Bestehen der Anlage. Ich nehme an, das ist das Übel eine festen IP-Adresse und gehe davon aus, dass dieses Verhalten normal ist.

    Ja, das ist leider "normal" und wird nach einer Anzahl X von der Starface abgefangen und macht eigentlich keine Probleme. Wir halten es hier allerdings so, dass diese Fehllogins und andere Auffälligkeiten in einer vorgeschalteten Firewall Beachtung finden und solche "Versuche" zumindest nach dem ersten Auftreten weitestgehend schon im Vorfeld abgefangen und geblockt werden. In der Regel gibt es erkennbare Muster immer gleicher Ausgangs-IPs dafür - ich muss aber vorwarnen - pauschal / automatisch in eine Sperre übernehmen funktioniert eher nur leidlich, da man so auch schnell mal etwas aussperrt, was man nicht sperren wollte oder sollte. Hier ist tatsächlich Handarbeit und manuelle Einzelprüfung angesagt ... lohnt sich aber - es wird dann deutlich ruhiger auf der Starface ...

    Hallo Fabian,

    nein - von Deinen diesbezüglichen Modulen ist dort nichts installiert - hier wird ein eigenes Modul dafür verwendet (was es auch schon etwas länger als Deine diesbezüglichen Module gibt und auch etwas anders ausgerichtet ist ;)). Allerdings ist jenes Modul für den betroffenen Benutzer gar nicht aktiv und das Problem tritt auch dann auf, wenn das Modul bzw. dessen Instanzen komplett deaktiviert ist - in diese Richtung hatte ich auch schon gedacht.

    Nachdem Fabians Hinweis goldrichtig war und die Openfire-Anpassung sofort eindeutig nachvollziehbare Besserung gebracht hat, gibt es bei jener Instalation jetzt noch eine andere Auffälligkeit, die vermutlich eine andere Ursache hat:

    Einer der Benutzer loggt sich mit seinem Windows-Client auf der Starface ein und dann beginnt nach einiger Zeit die sichtbare Chatverfügbarkeit in relativ schnellem Wechsel an und aus zu gehen. So ist das dann auf der Starface z.B. in BLFs sichtbar. Der Client bleibt auch selbst stabil angemeldet und zeigt sonst auf Seiten der Starface vermeintlich kein sonstig sichtbares Fehlverhalten.

    Der Nutzer selbst beschreibt es so, dass er den Client teils gar nicht nutzen kann - sich das bei Ihm als "unverbunden" darstellt (was es aber definitiv nicht ist) - im Client wird beim genutzten Softphone ein ! angezeigt - der Chat witzigerweise als verfügbar.

    Client-Alzheimer? =O

    Auf Seiten der Starface kann man auch sehen, dass selbst Anrufe dorthin geleitet werden - also von Seiten der Anlage auch technisch von einem vorhandenen Client ausgegangen wird. Mit Blick auf den auswertbaren Chatstatus des Benutzers sieht es so aus, als gäbe es "mehrere Anmeldungen des gleichen Accounts" mit uneindeutigem - unterschiedlichem Ergebnis der Auswertung des Chatstatus.

    Betroffen ist nur eben jener eine Nutzer (von über 350). Der Nutzer ist nicht neu - den gibt es so schon lange, funktioniert hat der bisher problemlos bis eben auch der sich zunächst nicht mehr anmelden konnte (siehe gelöstes Problem). Bei anderen Nutzern, die jenes erste Anmeldeproblem hatten, tritt das defitiv nicht auf.

    Wo kann man ansetzen?

    ... den Client hat der benutzer wohl schon mehrfach neu auf seinem PC installiert (nach vorherig, vollständiger Entfernung).

    In dem Fall handelt es sich aus rein organisatorischen Gründen (aktuell noch) um einen 6.7.x-Installation mit dem dafür passenden Client.

    Hallo Fabian,

    ich bin mir jetzt nicht sicher, ob ich an den richtigen Stellen dafür gesucht habe - in der mit bekannten Openfire-Konfiguration kann ich dazu nichts finden, aber vielleicht suche ich nach etwas Falschem oder an der falschen Stelle.

    Sicherheitshalber: Die betreffende Angabe wäre exakt wo zu finden?

    Hallo Fabian,

    danke für die Info - dann haben wir die Erklärung - da wird teils deutlich mehr transportiert (punktuell wohl über das Doppelte). Der Zusammenhang zum Umfang der UCI-Requests liegt dann sicher noch in Kombination an einer anderen Stelle, die ich hier gar nicht weiter erwähnen und beschreiben mag und die ich zum Glück nach längerer Überzeugungsarbeit dem Kunden ausreden konnte. Offenkundig wurde dann jetzt definitiv eine Schmerzgrenze überschritten - Dein Hinweis erklärt das jedenfalls.

    Das heißt aber auch, dass diese Limitierung auch bei Folgeversionen der SF gilt, oder?

    Hallo in die Runde,

    ich bin im Zusammenhang mit der Verwendung verketteter Gruppen bei einer Kundenanlage auf ein merkwürdiges Problem gestossen:

    Der Kunde wollte den eigentlichen simplen Lösungsweg für ein banales Anrufhandling haben, bei dem Anrufe zunächst bei einem Benutzer für einige Sekunden klingeln, danach für weitere Sekunden an eine erste Gruppe von anderen Benutzern signalisiert werden und, falls diese nicht annehmen in einer zweiten Runde an weitere, andere Benutzer weitergegeben + wenn auch diese nicht abnehmen nach weiterer Klingelzeit auf der Mailboch landen.

    Gelöst wurde das dann tatsächlich durch eine Weitergabe an zwei Gruppen, die Ihrerseits jeweils über separate mehrstellige Rufnummern angewählt werden. So weit - so gut - funktionierte lange Zeit für verschiedene Szenarien bei genau diesem Kunden auch so.

    Mittlerweile ist der Kunde sehr stark gewachsen, hat ein zigfaches an Mitarbeitern und eben auch zusätzliche Anforderungen. Beim Anlegen zweier weiterer in dieser Form verketteter Gruppen gab es nunmehr für die letzte neu angelegte Gruppenkombination plötzlich den Effekt, dass alle, in der zweiten Gruppe befindlichen Gruppenmitglieder, sich nicht mehr via PrepiumApp an der Starface anmelden können. Es ist eindeutig so, dass es sich um benannte Gruppenmitglieder handelt und auch nur diese - kein anderer Benutzer ist betroffen. Bei Entfernen eines Benutzers aus jener zweiten Gruppenstufe kann der sich auch sofort wieder anmelden.

    Gibt es für solche Gruppenkonstellationen mit Blick auf die Anzahl von Gruppen und Gesamtgruppenmitgliedern eine Limitierung?

    Die bisher genutzten Gruppen sind bezüglich der Gruppenmitglieder sehr umfangreich, wobei es eine untere zweistellige Anzahl von Gruppen gibt. Die betreffende Starface-Installation ist bis an die Grenzen des vom genutzten Linuxunterbau überhaupt verarbeitbaren RAM und CPU bestückt, hat also von dieser Seite technisch eher gar keine Mühe damit und verhält sich mit Blick auf genutzte Ressourcen auch komplett unauffällig und ruhiger als so manche Standardinstallation ...

    Gibt es dazu irgendwelche Hinweise?

    @Starface?

    Nachtrag zum Thema:

    Zwischenzeitlich wird beim Aufruf der LOGs wenigstens noch eine Fehlermeldung angezeigt: "Es ist ein Fehler in der Anwendung aufgetreten!".

    Kontrolliert hatte ich zwischnezitlich mal auch die Log-Files auf Vorhandensein und korrekte Rechte + Besitzer - das passt wohl alles (im Vergleich zu anderen Installationen.

    @Starface???

    Hallo in die Runde,

    nach Update einer Starface auf Version 7.3.1.3 ist in einem Fall der Aufruf der Logs im Administrationsbereich nicht mehr möglich - das betreffende Fenster bleibt leer / das offene Adminfenster hängt sich auf, kann danach nur noch geschlossen werden und funktioniert erst nach einem Neustart wieder (der Log-Bereich ist allerdings nie nutzbar - alles Andere schon).

    Browsercaches wurden bereits geleert und auch verschiedenen Browsern (allesamt aktuell) getestet. Betroffen ist auch nur eben diese eine Starface - andere verwaltete Kundenanlagen haben unter gleichen Bedingungen dieses Problem nicht.

    Aufgefallen war allerdings auch in einem anderen Fal direkt nach dem Updatel, dass dieser Effekt auch auftrat, wenn eine virtualisierte Starface nur eben über die empfohlenen 2 GB RAM verfügt (exakt im Bereich der Logs wird dann eben auch nichts angezeigt und das Fenster hängt sich auf). Hatte man bei jener SF das RAM auf 4 GB angehoben, lief es problemlos auch im Bereich der Logs ...

    Wie kann man hier Abhilfe schaffen?

    Hallo in die Runde,

    gibt es eine Option, bei Gesprächsmitschnitten den Mailversand zu dektivieren/unterdrücken? Im vorliegenden Fall würde die Speicherung und optionale tgl. Archivierung völlig ausreichen - der Mailversand ist in dem Fall völlig überflüssig und gar nicht gewünscht.

    Aktuell noch im Einsatz SF 6.7.3.22

    Hallo in die Runde,

    wir haben bei einen Kunden mit aktuell deutlich mehr als 300 Usern das Problem, dass bei einigen Benutzern bei der Anmeldung des Clients sporadisch das Passwort falsch zu sein scheint. Sobald der Nutzer das (gleiche / bekannte) Passwort (im Client) neu einträgt, kann sich der Client auch wieder anmelden.

    Leider geht mit dem Auftreten dieses Problemes offenbar ein zweites Problem einher:

    ... ab und an werden in o.g. Situation während des Anmeldeversuches der Clients mit plötzlich vermeintlich falschem Passwort, andere bereits angemeldete User rausgeworfen + die Systemlast der SF steigt deutlich an.

    Im Einsatz ist in diesem Fall Anwendungsbedingt aktuell noch eine SF 6.7.3.22 mit dazu passenden Client 6.7.3.322

    Kennt jemand diesen Effekt und gibt es dazu einen Lösungsansatz?

    Hallo in die Runde,

    ab welcher Starface-Version (Anlage + Client) ist das Yealink-Headset WH 66 einsetzbar - insbesondere: ab welcher Version oder unter welcher Voraussetzung wird die Rufannahme am Headsethörer unterstützt?

    Interessant wäre eine Aussage sowohl zu der Starface+Client-Version als auch im Zusammenhang mit z.B. dem Tischtelefon Yealink T57W ...

    Beste Grüße,

    Ulf

    Hallo zusammen,

    gibt es eine einfache Möglichkeit eine Starface über den Modul-Designer neu zu starten? Ich habe gesehen, dass es Bausteine zum Ausführen von Shell-Befehlen
    gibt (das dürfte aber nicht so einfach sein, da ich ja root-Rechte zum Neustarten benötige und ein Passwort mitgeben müsste und bei dem anderen kann man nur
    Skripte angeben).

    Gibt es hier eine "einfachere" Möglichkeit?

    Je nachdem, um welche Art des Neustartes es geht wäre sowas mit CheckSIP Advanced möglich - dort ist diese Funktion (zusätzlich) vorhanden und kann zeitgesteuert durchgeführt werden. Durchgeführt wird dort dann ein Dienste-Neustart. Das wäre dann zumindest eine "fertige" Lösung ...

    Den Hinweis zur aktuellen Firmware kann ich für alle neueren Handsets bestätigen - mit der von Starface ausgelieferten Frmware funktionieren die nur sehr eingeschränkt, Dinge wie Abruf der Anruferlisten, Anrufbeantworter u.a. funktionieren damit bei diesen Geräten nicht, mit der erwähnten Firmware .259 dann schon. Benannte Firmware wurde hier intern getestet - bisher können keine Probleme damit festgestellt werden - alles funktioniert wohl so wie es soll.

    Hat man die neue Firmware mal manuell installiert, wird diese NICHT durch die ältere, von Starface gelieferte Firmware überschrieben.

    Das Update kann man nach Login auf die N510-Basis im bereich Firmware durch Tauschen des Starface-Links zu profile.gigaset.net/device starten - geladen wird nach Speichern und manuellem Anstossen des Updates die jeweils aktuellste Firmware für die Basis. Nach dem Neustart des N510 steht automatisch wieder der Original-Starface-Link drin ...