Posts by ranX

    Hallo und danke für Eure zahlreichen Antworten !
    Neros Information, dass in der V7 keine einstelligen Nummern mehr konfigurierbar sind, war der entscheidende Hinweis.

    Mir war nicht bewusst, dass es an dieser Stelle eine Änderung gab.

    Durch den Import der alten Konfiguration gab es die interne 0 immer noch, bloß eben mit Fehler.

    Nachdem ich der Gruppe "Zentrale" intern eine andere Rufnummer zugeordnet habe, funktioniert weider alles, wie gewohnt.

    Mit freundlichem Gruß

    ranX

    Hallo ans Forum,


    vor wenigen Tagen haben wir von 6.7 auf 7.2 upgedatet.

    Das ganze war angenehm einfach erledigt.Nur ein seltsamer Effekt ist heute aufgefallen:

    Die "0" ist bei uns der Rufgruppe "Zentrale" zugeordnet.

    Interne Nummer ist die 0

    Externe Nummer ist Vorwahl + Anschlussnummer + 0

    Rufe ich von extern die Durchwahl "0" (Zentrale) an, funktioniert das.
    Die zur Gruppe gehörigen Telefone klingeln.

    Mache ich das am Client von intern per Besetztlampenfeld oder wähle per Tasteneingabe des Clients, wählt die Anlage "0049" und ich bekomme die Ansage "die gewählte Rufnummer ist unvollständig"
    Wähle ich am Yeahlink Tischtelefon, erfolgt wie gewohnt die Durchwahl zur Zentrale.

    Gibt es eine Möglichkeit, die Anlage so zu konfigurieren, dass vom Client wieder nur die 0 gewählt wird und keine automatische Vervollständung auf eine unvollständige Nummer stattfindet ?

    Bereits vorab Danke für Eure Hilfe !

    Gruß
    ranX

    Moin zusammen und danke an slu !

    Dass die Starface Log4j 1.2.17 benutzt ist zwar insofern schön, dass sie nicht von der genannten Sicherheitslücke betroffen ist.
    Dafür ist für diese Version bereits seit Dezember 2019 CVE-2019-17571 bekannt.
    Schlimmer ? Besser ?
    Man weiß es nicht ...

    Gruß
    ranX

    Moin Ulf,

    Danke, dass Du mir mit viel Rat zur Seite gestanden hast !
    Ich habe die Ursache nun mittlerweile gefunden.
    Traue mich kaum, es zu sagen - selbstgemachte Leiden ...
    Da in der Firma einige Anpassungen gewünscht wurden (anderer Hintergrund, zusätzliche Klingeltöne, bestimmte Zeiten für Energeiesparmodus ...) habe ich diese "zu Fuß" umgesetzt.
    Dazu habe ich in den Filetemplates die *-settings.cfg bearbeitet.
    Diese Dateien werden aber bei Update jedes Mal überschrieben.
    Aus dem Grund kopiere ich die angepasste Version nach jedem Update wieder auf die Starface.

    In der neuen Version hat es aber entweder bei Yealink oder Starface genau dort Anpassungen gegeben.
    Die Variablen #ADMINPASS# und #USERPASS# werden nicht mehr aus dem Backend gefüllt.
    Sie sind einfach keine Variablen mehr, sondern werden an Stelle des Passworts gesetzt.

    Ich habe mittlerweile meine *-settings.cfg auf die neue Version angepasst - damit funktioniert wieder alles wie gewohnt.

    Noch mal besten Dank !
    ranX

    Moin Ulf,

    habe ich grade mit meinem Apparat versucht.
    Danach war das Telefon dann total "lost in space" und hat sich nicht mal mehr automatisch an der Anlage angemeldet.
    Ich habe es darum komplett aus der Konfiguration gelöscht und einen zweiten Werksreset gemacht.
    Jetzt habe ich es zwar wieder in der Übersicht und kann damit telefonieren - die Anmeldung funktioniert jedoch weiterhin nicht.
    Weder mit dem in der Anlage konfigurierten Passwort, noch mit "admin".

    Falls Du oder Andere noch Lösungsvorschläge haben - immer her damit !

    Gruß
    ranX

    Hallo Ulf,

    vielen Dank für Deine Antwort !

    Bisher habe ich Folgendes -erfolglos- getestet:
    Anmeldung unter https: - bei einem anderen Forenmitglied mit T53 hat es darüber funktioniert
    Anmeldung mit verschiedenen Passworten (0000, password, admin)
    Erneutes Setzen des Logins für die Telefone an der Anlage (Telefone haben danach automatisch neu gestartet)

    Bei mir tritt das Problem übrigens bei allen Geräten auf.
    Wir haben hier ausschließlich Yealink T48G im Einsatz und ich kann mich bei keinem Telefon anmelden.

    Momentan bin ich ratlos und freue mich weiterhin über Lösungsvorschläge.

    Gruß
    ranX

    Moin zusammen,

    ich habe grade das Update auf die aktuelle Version (6.7.3.11) auf unserer Starface eingespielt.
    Die Telefone (Yealink T48G) wurden dabei neu provisioniert.
    Seitdem ist das Login am Webfrontend der einzelnen Telefone nicht mehr möglich.

    Testweise habe ich der Verwaltung der Anlage das Passwort noch einmal neu gesetzt und abgespeichert, was zu einem Neustart der Telefone geführt hat.
    Leider kann ich mich weiterhin nicht mit dem im Admin-Backend gesetzten Passwort anmelden.

    Ist das Verhalten bekannt und kennt jemand eine Lösung ?

    Ich freue mich auf Eure Antworten

    Gruß
    ranX

    Moin,

    gibt es zu dem Thema schon was Neues ?

    Sind möglicherweise neue Ports hinzugekommen, die ich auf der Firewall für die Kommunikation von mobilen iOS Geräten zur Starface freigeben müsste ?
    Ich frage deshalb, weil ich diesen Fehler nur habe, wenn die iPhones über mobile Daten von extern auf unsere (selbst gehostete) Starface zugreifen.
    Sobald die Fons per Wlan im internen Netz sind und direkt mit der Starface kommunizieren können, lässt sich der Schieber "Softphone aktiviert" ohne Fehlermeldung auf "aktiv" schieben.

    Wenn das so ist, sind diese Ports erst durch die leidigen iOS Updates und den daraus resultierenden neuen Versionen des Starface iOS Clients dazugekommen.
    Vor den Updates hat das alles irgendwann mal mit den zur Zeit freigegebenen Ports funktioniert.

    Ist ein iPhone mit dem internen Wlan verbunden und der Schieber aktiv, springt er sofort auf inaktiv, wenn ich die Wlan Verbindung unterbreche und sich das Telefon nur noch von extern über die Firewall auf die Starface verbinden kann.
    Bin ich im internen Netz, kann ich auf der Statusseite des Clients auf mein Profilbild tippen und er springt ohne Fehlermeldung zu den Einstellungen.
    Bin ich extern verbunden und tippe auf das Bild, bekomme ich die Fehlermeldung "Fehler - Ein unerwarteter Fehler ist aufgetreten. Details_ error(403,Optional(222bytes),Alamofire.AFError.responseValidation-Failed(reason:Alamofire.AFError.ResponseValidationFailureReason.unacceptableStatusCode(code:403))))

    Vielleicht helfen diese Infos ja, dem leidigen Thema auf die Schliche zu kommen und den Client wieder vollumfänglich gebrauchsfähig zu machen.

    Gruß

    ranX

    Vielen Dank für das Bereitstellen der Beta.

    Mein bisherigen Erfahrungen:
    Neon generiert eine relativ hohe Systemauslastung; bei einer Videokonferenz per Teams bleibt der Rechner ruhig.
    Neon bringt den Lüfter sofort richtig auf Touren.

    Meine Anregungen:
    Ich nenne mal ein paar Funktionen, die meinen Kollegen wichtig sind und die mittelfristig verfügbar sein sollten, um gegen andere Anbieter zu bestehen:
    - Integration im UCC Client und in Outlook
    - Zusammenstellung einer Telefon/Viedeokonderenz sollte einfach aus dem Outlook-Adressbuch incl. Einladung möglich sein
    - hier müsste es zusätzlich die Möglichkeit der Terminplanung geben, d.h. nicht nur Spontanmeetings
    - dazu ein Plugin in der Outlook Kalenderfunktion, die das geplante Meeting incl. Links und benötigter Informationen als Outlook-Termin an alle Teilnehmer verschickt.
    - Teilnahme sollte für Mitglieder außerhalb der Organisation möglich sein, ohne dass dort die Einrichtung von Portfreigaben auf der Firewall notwendig ist.
    Gruß
    Renke

    Moin Fabian,

    hast Du Dein Modul denn schon auf die Änderungen in der V6.7 angepasst ?
    Sonst wird es in dieser Version zumindest für Yealink T4x Modelle nicht mehr funktionieren, weil sich der Pfad geändert hat, aus dem die Yealink-CFG gezogen wird.
    Wenn Dein Modul nur in den alten Pfad schreibt, ist es nicht weiter verwunderlich, dass die Änderungen nicht übernommen werden.

    Ich verweise auf meinen "Käfer-Report" :)

    Gruß

    Renke

    Umgebung:
    Starface - Version 6.7.0.24
    Telefone: Yealink T48G

    beobachtetes Verhalten:
    die Telefone übernehmen die Einstellungen, die unter "\var\lib\tomcat6\webapps\localhost\starface\WEB-INF\filetemplates\yealinkConfig\t4x\T46_48-basic-settings.cfg" gemacht wurde nicht mehr.
    Bis V 6.6 funktionierte dies.

    Fehleranalyse:
    Ich habe mir das autoprovison.log angeschaut.
    Dort kann ich die CFG Datei sehen, die von der Starface automatisch "zusammengebaut" und an startende Telefone übermittelt wird.
    Um zu sehen, aus welchen CFG Dateien die Datei erstellt wird, die die Starface ans Telefon überträgt, habe ich in alle Dateien im o.g. Ordner einen Kommentar zur Identifizierung eingefügt.
    Keiner dieser Kommentare taucht in der übermittelten CFG auf.

    Sichtbar wurden allerdings Kommentare, die ich in Konfigurationsdateien unter "\var\lib\tomcat6\webapps\localhost\starface\WEB-INF\filetemplates\yealinkConfig\t4xs" eingetragen habe.

    Zusammenfassung:
    Ein Yealink T48G bekommt also die Konfiguration, die für ein T48S hinterlegt wurde.
    Soll so bestimmt nicht sein.
    Melde ich darum als Bug

    Gruß Renke

    Moin zusammen,

    ich habe unsere Starface gestern auf V 6.7 upgedatet.
    Lief so weit alles schön, nur die Autoprovisionierung funktioniert nicht mehr, wie gewohnt.

    Bisher konnte ich über die Datei "\var\lib\tomcat6\webapps\localhost\starface\WEB-INF\filetemplates\yealinkConfig\t4x\T46_48-basic-settings.cfg" für unsere Yealink T48G
    den automatischen Download von Klingeltönen und Hintergrundbildern, so wie das Setzen des Standard Hintergrundbilds und des Klingeltons steuern.

    Jetzt übernehmen die Telefone keine Einstellungen mehr, die dort eingetragen werden.

    Ich habe mir das autoprovison.log angeschaut.
    Dort kann ich die CFG Datei sehen, die von der Starface automatisch "zusammengebaut" und an startende Telefone übermittelt wird.
    Um zu sehen, aus welchen CFG Dateien die Datei erstellt wird, die die Starface ans Telefon überträgt, habe ich in alle Dateien im o.g. Ordner einen Kommentar zur Identifizierung eingefügt.
    Keiner dieser Kommentare taucht in der übermittelten CFG auf.

    Daher nehme ich an, dass sich der Mechnismus zur Erstellung der provisionierten CFG geändert hat bzw. dass die dazu verwendeten Dateien jetzt aus einem anderen Quellordner gezogen werden.

    Weiß jemand von Euch Genaueres und kann mir weiterhelfen, damit ich die Provisionierung unserer Telefone wieder wie ans Laufen bekomme ?

    Bereits vorab vielen Dank !

    Gruß Renke

    Moin Andreas,

    Ich war zwar schon in dem Menü; weil ich dort nicht täglich unterwegs bin, wusste ich allerdings nicht, dass ich für jedes einzelne Gerät definieren kann, auf welcher Nummer es klingelt.
    Damit lässt sich genau das abbilden, was wir benötigen.
    Außerdem hat es den Charme, dass die Kollegen nach einmaliger Konfiguration von iFMC Bereitschaftsanrufe auf dem Mobiltelefon einfach selbst steuern können:
    über ein zusätzliches Besetztlampenfeld können Anrufe, die über die Supportgruppen reinkommen, aktiviert und deaktiviert werden.

    Herzlichen Dank für diesen prima Hinweis - Du hast mein Problem gelöst !

    Gruß

    Renke

    Hallo zusammen !

    Ich hoffe auf Eure Hilfe, da mir grade die passende Idee fehlt.
    Folgende Aufgabenstellung möchte ich lösen:

    Außerhalb der Bürozeiten und am Wochenende soll eine Supportrufnummer auf Mobiltelefone umgeleitet werden.
    Um möglichst vollständige Erreichbarkeit zu gewährleisten, soll nach 1 Min. Klingeln auf Mobilnummer A auf Mobilnummer B umgeschaltet werden
    (falls A aus irgendwelchen Gründen den Anruf nicht annehmen kann)

    Bisherige Ansätze:
    No. 1
    Ich konfguriere eine Gruppe "Support" und richte dafür eine Weiteleitung auf Mobilnummer A ein.
    Dann ist leider schon Schluss, weil ich nicht weiß, wie ich es bei dauerhafter Weiterleitung hinbekommen soll, dass bei Zeitüberschreitung Mobilnummer B angerufen wird

    No. 2
    Ich konfiguriere eine Gruppe "Support" und eine Gruppe "Support-Backup"
    Von "Support" wird nach Zeitüberschreitung auf "Support-Backup" abgeworfen.
    Den Kollegen mit Mobilnummer A füge ich zur Gruppe "Support" hinzu; den Kollegen mit Mobilnummer B zur Gruppe "Support-Backup"
    Für beide konfiguriere ich iFMC und richte die Zeitsteuerung des iFMC so ein, dass das Telefon nur außerhalb der Bürozeiten klingelt.

    Damit habe ich schon fast erreicht was ich will.
    Leider mit folgendem Schönheitsfehler - wird Kollege A oder Kollege B außerhalb der Bürozeiten auf der Büro-Durchwahl angerufen, klingelt bei diesem Anruf ebenfalls sein Mobiltelefon.
    Ziel ist aber, dass nur Anrufe auf der Supportdurchwahl zu A oder B weitergeleitet werden.
    Bei Anrufen auf der Büro-Durchwahl, soll es dort einfach klingeln, ohne dass eine Weiterleitung erfolgt. (so dass dort immer noch eine Annahme möglich wäre)

    Ich hoffe, das Ziel ausreichend gut beschrieben zu haben und würde mich freuen, wenn Ihr mir Tipps geben könnt, wie ich es erreichen kann.

    Gruß Renke

    Nachtrag:
    Die Bereitschaftsnummern ändern sich wöchentlich.
    Am Schönsten wäre darum eine Lösung ähnlich No. 2, damit die Kollegen selbst die Möglichkeit haben, die Supportbereitschaft für Ihr Mobiltelefon zu aktivieren,
    ohne dass jede Woche Änderungen über das Admin-Backend vorgenommen werden müssen.

    Mit welchem Provider hast Du denn das Vergnügen ?
    Ich frage, weil es ungewöhnlich ist, die Box nicht einfach als dummes Modem hernehmen zu können.
    Das geht sogar bei Vodafone am Privatkunden(kabel)anschluss

    Aber mit der Fritzbox allein sollte es auch gehen.
    externes Portforwarding auf die Starface ist folgendermassen eingerichtet ?
    XMPP (5222-5223) als UDP
    RTP (10000-20000) als UDP
    SIP over SSL (5061) als TCP

    Das war ganz klar mein "Layer 8 Problem" :D
    Nach Deiner Antwort fiel es mir wie Schuppen aus den Haaren:
    - für Anrufe auf der externen Nummer ist bei allen Benutzern ein Abwurf nach 15 Sekunden konfiguriert
    - für Anrufe auf der internen Nummer, sprich für interne Gespräche gibt es das nicht
    Aber - genau dorthin habe ich den Abwurf von Gruppe "A" umgeleitet.

    Ein ganz herzliches Dankeschön für Deine prompte Antwort !

    Gruß Renke

    Hallo ans Forum,

    ich beobachte bei unserer Starface (v. 6.6.0.10 VM Edition) folgendes Verhalten und wüsste gern ob das so beabsichtigt ist oder es sich eher um einen Bug handelt.

    Folgende Konfiguration:
    In einer Gruppe "A" habe ich eingestellt, dass nach 15 Sekunden Klingeln an einen Benutzer "Z" weitergeleitet wird - funktioniert.
    Bei dem Benutzer "Z" habe ich eingestellt, dass nach 15 Sekunden Klingeln an eine Gruppe "B" weitergeleitet wird - funktioniert.

    Klingelt es jetzt bei Gruppe "A", erfolgt nach 15 Sekunden der Abwurf auf den Benutzer "Z".
    Ich würde erwarten, dass von Benutzer "Z" nach weiteren 15 Sekunden Klingeln auf Gruppe "B" abgeworfen wir; das passiert aber nicht.

    Noch mal zusammengefasst: wird Benutzer "Z" selbst angerufen, funktioniert der Abwurf nach 15 Sekunden; erhält er einen Anruf durch Abwurf, wird dieser nicht nach 15 Sekunden weitergeleitet, sondern es klingelt dauerhaft bei "Z" weiter.

    Soll das so sein, bzw., wie bekomme ich die gewünschte Abwurfkette Gruppe A ---15sek--- Benutzer Z ---15sek--- Gruppe B hin ?

    Ich freue mich auf Eure Antworten

    Gruß Renke

    Aber hilft es da, den Support künstlich auszulasten?


    Sollte das Problem von gravierender Bedeutung für eine Vielzahl von Benutzern sein, ist es durchaus berechtigt, wenn die sich melden.
    Und wenn es für den Großteil keine Bedeutung hat, dann wird meinem Vorschlag niemand folgen.
    Hat also mit künstlicher Auslastung nichts zu tun.

    Ach so: ich bin Dir gegenüber bisher höflich geblieben - ich bitte Dich, das auch zu tun.