Posts by Ulf

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

    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:

    Quote

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

    Ist das echt so?


    Wahnsinn. Hätte gedacht, dass die Leute gerade bei sowas kritischem wie TK Anlagen eher nicht in die Cloud gehen.
    Naja, zumindest ne VM sollte man dann doch als Ausfallsicherung bereit halten.


    Warum sollte man TK-Anlagen nicht mit Blick auf Erreichbarkeit und Überwachungstechniken, nicht in Rechenzentren hosten? Ich würde sagen: man ist eher flexibler und kann kaputte Installationen auch noch superschnell wiederherstellen ...


    Wir machen das hier seit Jahren fast ausschliesslich mit allen neuen Anlagen unserer Kunden auf eigenen Hosts im Rechenzentrum so - mit großem Erfolg und eigentlich eher bester Ausfallsicherheit. Was halt entscheidend ist: es muss einen 24/7-Service geben, der auch gewährleistet ist - in meinen Augen ohne Extra-Vertrag oder Aufpreis. Hier ist das so und funktioniert dann auch - ergo: gerade für bestimmte Szenarien oder auch spezielle Fälle hat sich das Hosten im RZ absolut bewährt und war gerade in Corona-Zeiten für das flexible Wechseln ins Homeoffice ohne irgendwelche Zusatzaufwendungen für einige Kunden regelrecht überlebensnotwendig.


    Grundsätzlich ist das Hosten im RZ jedenfalls nicht schlechter :)

    Bei zwei unserer Clouds sind die Premiumzuwesiung Verloren gegangen, und wir konnten nicht nachvollziehen weshalb.
    Ist jedoch nicht so schlimm, die Benutzer "ziehen" sich diese ja selber wieder beim Aktivieren des Softphones.


    Jein - ganz so einfach ist es dann nicht in jedem Fall: hat man nur eine bestimmte Anzahl der Benutzer mit den Premiumlizenzen und gezielt bei anderen Nutzern die z.B. gar nicht im Einsatz, klappt das mit dem "selber ziehen der Lizenzen" nicht, insbesondere, wenn richtigerweise und gutem Grund das automatische Zuweisen der Lizenzen abgeschaltet ist.


    Im Ernst: nach dem 2. Kunden mit dem gleichen Symptom hatte ich schon auch in diese Richtung gesucht und den Lizenzserver im Verdacht gehabt. Mir erschliesst sich allerdings nicht, warum manche Kunden betroffen waren und andere Kunden nicht - und das trifft auch eben auf die Fälle gleicher Bereitstellungsarten zu (und: keine Starface-Cloud-Anlagen). In jedem Fall ein sehr lästiger Effekt das diese Lizenzen bei einer solchen Störung gleich ausgetragen werden. Das kann nicht der Weisheit letzter Schluss sein - zumal der dadurch entstehende Aufwand nicht bezahlt wird (und die entstandenen Kosten+Arbeitszeit zur Problembehebung sind gegebenenfalls nicht so ganz unerheblich).


    Was mich aber wirklich stört:


    Hilfreich wäre es gewesen, zumindest dem Starface-Partner eine Mail zu senden, damit der Bescheid weiß. Man könnte sich wenigstens schneller um die entstandenen Probleme bei Kunden kümmern - niemand hätte das erst Stunden später genau da und nach Rückmeldung gestresster und verärgerter Kunden hinnehmen müssen, wo die Technik zu Arbeitszwecken genutzt werden sollte. Dieser Part ist dringend verbesserungswürdig und zunächst mal nur eine Frage der transparenten Kommunikation.


    @Starface: bitte dringend verbessern - mindest im Punkt Fehlermanagment und dazugehörende Kommunikation.

    Anmerkung zur Fehlersuche:


    Das ist allerdings tatsächlich (neuerdings) nur bei Lets Encrypt!-Zertifikaten so, die im Zusammenhang mit der SF genutzt werden - bei Zertifikaten des gleichen Ausstellers bei anderen Webseiten funktioniert das problemlos. Und JA - betrifft den Aufruf im Safari

    Hallo Michael,


    leider kann man auf diese Art (bzw. überhaupt) keinen weiteren Account auf dem Telefon einrichten, insofern dieses von der TK-Anlage (Starface) provisioniert wird. Denkbar wäre nur, das Provisionieren generell abzuschalten (in der Starface).


    Um eine solche Mischung zu nutzen, würde ich eher die Accounts allesamt auf der Starface führen - man kann (mittels Modullösung) auf problemlos Anrufe unterscheiden, die an mehrere Verschiedene Accounts gerichtet sind und sich so z.B. unterschiedlich melden oder im einfachsten Falll auch Firma und Privat oder was auch immer für Kombinationen unterscheiden.

    roady1969: "Abgekündigt" heißt dann üblicherweise eigentlich auch: kein Support mehr ... in dem Fall natürlich bitter, da die benannten Telefone zumindest was Yealink betrifft sehr verbreitet sind.


    Man kann sicher davon ausgehen, das unter dem Hinweis nichts anderes verstanden wird, als was zum Thema "EoL" allgemein gesagt wird - siehe HIER

    slu: wir haben es schon im Hintergrund besprochen - hier noch die Info dazu für all die anderen Betroffenen:


    Die Variable _calledNumber kann man alternativ auch aus der Funktion GetCallee beziehen - dort wird dann auch erwartungsgemäß als Wert sowohl externe wie interne Rufnummern (korrekt) geliefert. Bei der alternativen Funktion GetCalledNumber liefert die Variable nur noch externe Nummern. Ob das geänderte Verhalten bei GetCalledNumber ein Fehler oder so (neu) "erwartbar" ist, möchte ich dahingestellt lassen.


    Das ist wohl (vermutlich) eine aktuelle Beschränkung auch anderer Module, die via _calledNumber Inhalte auslesen wollen und das via GetCalledNumber versuchen - ein Problem, was man als Modulhersteller jedenfalls sehr schnell fixen kann. Wenn man um den Umstand weiß, ist das Handlimg der Modulanpassung tatsächlich eine Kleinigkeit und würde als ganz schnelle Lösung auch an anderen Stellen weiterhelfen ("Zeitgesteuerte Umleitung" (....) unter 7.x ?).


    ... nur so als Tipp für EINE Lösung aktueller Probleme ...

    @Starface: Hinweis, wo das Problem zu finden und vermutlich zu fixen ist, ging heute raus und liegt vor ...


    Martin: ja - hatte ich umgehend gemacht und auch eine Rückmeldung dazu erhalten. Möglich, dass das mit der Version 7.1 (Veröffentlichungstermin der Beta wurde hier kommuniziert) behoben ist. Ansonsten wäre jetzt bekannt, wo man wohl in den betroffenen Modulen suchen muss. Der Fehler selbst erscheint theoretisch banal, kann aber eben auch übersehen werden. Ich bin bei uns auch nur nach etwas Analysierei und fehlendem Willen zu schnell aufzugeben auf die Ursache aufmerksam geworden. Entsprechend würde ich niemandem vorwerfen, dass gegebenenfalls früher hätte finden zu müssen - kann man tatsächlich übersehen.

    uwe Sundermann:


    Das Problem kann seit der SF 7 grundsätzlich nachvollzogen / bestätigt werden. Meines Erachtens handelt es sich entweder um einen Fehler im Modúlsystem oder wohl eher um eine Verhaltensänderung, bei der eine Funktion anders als bisher reagiert. Das Problem sollte aber leicht behebbar sein - wir hatten das bei unseren Modulen teils auch beobachtet und mussten lediglich eine Option anders abfragen und schon funktioniert das wieder. Der Modulhersteller (in dem Fall Starface selbst) kann das vorr. leicht reparieren.


    Ich werde gerne eine entsprechende Info mit dem Hinweis zur Ursache / Fehlerquelle an Starface weiterreichen.