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? 
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,
super - besten Dank ... damit passt es jetzt! Super und DANKE!
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?
Hallo Fabian,
super - so macht es Spaß!
Das Ganze hat punktgenau geklappt und sofort für Abhilfe geschaffen / der Logbereich funktioniert wieder und ich kann mich beruhigt an den nächsten Schwung Starfaces zur Umstellung auf die Version 7 machen 
Besten Dank auch an Daniel Mauritz!
Euer beider Hinweis hat das Problem natürlich bestens erklärt ...
Danke für den Hinweis - ich sende Dir mal den Logauszug per PN ...
Die betreffende Installation läuft mit 4 GB RAM
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?
Danke für die schnellen Antworten! Das hilft weiter.
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 ...
Ein Anruf eines unserer betroffenen Kunden bei der Telekom hatte ergeben, das der dortige Support (ohne Bezug auf die Starface) von einer bekannten allgemeinen Störung bei den SIP-Trunks bei der Anmeldung sprach und zu dem Zeitpunkt auch keine Lösung parat hatte. Es scheint damit wohl nicht nur die Starface betroffen gewesen zu sein ...
Hallo Nero,
damit dürfte Dir geholfen sein: Modul CallDisplay Detective
Die Lösung setzt zwar nicht in den Kontakten der Starface an, löst das Problema aber über einen Eintrag in einem Modul. Ist ein kleiner, aber effektiver Zwischenschritt.
Das Modul gibt es für SF6 und SF7.
UDP 120: Ja - ist bekannt, dass das seit langem als Standard gesetzt ist, tatsächlich wurden aber eben auch bessere Erfahrungen mit den kleineren Werten gemacht. Im Zweifelsfall scheint wohl "probieren" kein schlechter Rat zu sein- Ich hatte noch keine Anschlüsse gesehen, an denen an der Stelle größere Werte erfolgreicher sind und nicht andere komische Fehler produzieren (z.B. Anschluss nach einem gerade geführten Gespräch nicht erreichbar).
Interessant erscheint mir aber auch der zweite Hinweis - hier geht es ja um Lancom-Router der Telekom der Hinweis lautet ja nicht, Lancom-Router an Anschlüssen der Telekom) - also die Geräte, die die Telekom mitliefert. Die haben eine etwas andere Firmware. In welchen Punkten die sich unterscheiden, weiß ich nicht - aber vermutlich spielt da etwas eine Rolle, sonst wäre das wohl nicht so erwähnt worden. Ist das denn in Deinem Fall ein Lancom, der von der Telekom geliefert wurde und von denen auch per Fernwartung administriert wird?
Hallo Max,
ich habe mich auf den 3. Beitrag bezogen - dort hattest Du das UDP-Aging erwähnt:
QuoteHi Fabian,
keine Regeln für besagte Ports auf der Firewall.
UDP Aging habe ich bereits auf 600 gestellt.
BTW: wir nutzen unseren Telekom SIP Trunk auch mit TLS über 5061 ohne diese Probleme
Grüße Max
Für das TCP-Aging setze ich sogar höhere Werte als 600 - bei UDP lautet die Empfehlung aber tatsächlich < 120 und ich habe mit dem Wert von 40 immer sehr gute Erfahrungen gemacht (habe die Lancoms bei vielen Kunden im Einsatz). Nur in Ausnahmefällen kann es sein, dass man sich beim UDP-Aging-Wert mal vorsichtig nach oben vorantasten muss - aber eben die magische 120 nicht überschreitet.
