Posts by Layer8Problem

    Hey Slu,

    Ich blick es noch nicht ganz, dein Client kann auf die Starface mit dem LE Zertifikat aber nicht direkt auf die Starface mit dem eigenen Zertifikat?

    Ist denn die CA auf dem Client hinterlegt und wird auch verwendet?

    Der Client kann auf die Weboberfläche zugreifen und sieht eine Trusted Verbindung.


    Wenn ich den UCC Client allerdings starte kommt die Fehlermeldung, dass die Rest Anmeldung nicht funktioniert. (Dadurch funktioniert das Telefonbuch nicht)

    Im LOG taucht dann die oben aufgezeigte Fehlermeldung auf, dass keine sichere TLS Verbindung aufgebaut werden.


    Die Root CA ist auf jedem Laptop vorhanden sonst würden unsere anderen Services intern nicht funktionieren.


    Wenn ich den Client aus dem WAN aus starte läuft die Verbindung(Port 443) über einen Reverse Proxy, welcher ein Lets Encrypt Zertifikat pro Host erstellt und präsentiert. Hier kann der UCC Client eine "Sichere Verbindung" aufbauen.


    Aus diesem Grund war meine Vermutung das beim Einspielen des Backups beim Updaten auf Version 7 das Webserver zertifikat der Starface irgendein schaden erlitten hat. Als erstes habe ich es dann neu erstellt. Im Nachgang hab ich noch ein Request über unsere CA gesigned und eingespielt. Dieses wird auch bei anfragen präsentiert.

    Guten Tag Zusammen,


    nach dem Update auf die Version 7.3 hab ich das Problem, dass der Client sich nicht an der REST API anmelden kann.


    Im Log steht folgendes:

    Could not get login object. Error: 0, Error calling GetLogin: Die Anfrage wurde abgebrochen: Es konnte kein geschützter SSL/TLS-Kanal erstellt werden.., Die Anfrage wurde abgebrochen: Es konnte kein geschützter SSL/TLS-Kanal erstellt werden..


    Wenn die Anmeldung über unseren Reverse-Proxy, welcher ein Lets-Encrypt Zertifikat präsentiert, aufgebaut wird funktioniert die Verbindung.


    Ich habe auf der Starface im Nachgang ein Zertifikat, welchers über unsere AD-CA ausgestellt wurde, eingespielt. Die Weboberfläche präsentiert dies auch und zeigt eine sichere Verbindung an.

    Die Anmeldung an der REST API im Client scheitert allerdings mit dem selben Fehler.


    Noch ein paar zusätzliche Dinge die ich bisher probiert habe:


    -Login mit der IP anstatt FQDN

    -XMPP Domain auf den FQDN abgeändert

    -"Neues Zertifikat" über die Weboberfläche erstellt


    Was sind die Vorraussetzungen für die erfolgreiche TLS Verbindung?

    Redest Du von der Anzeige bei "Immer-Umleitung"? Falls ja, haben wir das hier beantwortet: RE: Ruflisten enthalten nicht mehr die umgeleiteten Anrufe

    Bei den anderen Umleitungsszenarien erfolgt die Anzeige unverändert.

    Hallo Christoph,


    genau von diesem Thema hab ich geredet.


    Ich finde es schade dass Starface immer die Funktionien zu 100% definiert anstatt dem User eine Auswahloption zu geben. Einige Kunden gewöhnen sich an bestimmte verhalten der Anlage. Diese werden mit dem Update auf Version 7, was jetzt pflicht geworden ist, gezwungen auf die Funktion zu verzichten. Das "Workaround" mit IFMC und Umleitung nach Zeit ist in meinem Fall leider nicht möglich, da die Umleitung nach Zeit bereits benutzt wird und bei IFMC keine interne Rufnummern eingetragen werden können.

    Tipp für die Fehlersuche. Sehr häufig hatten Probleme wie Wartezeiten/Abbrüche etc. zusammenhänge mit DNS Probleme.

    Ich lass bei so sachen immer per TCP Dump die DNS Abfragen mitlaufen.

    Wenn eine Starface kein Zugang zum Internet hat (bzw. Lizenzserver etc.) treten die seltsamsten Dinge auf.


    Grundsätzlich habe ich auch einen Kunden bei dem die Analge jetzt 2 mal "Ausgefallen" ist. Hierbei ist aber die CPU Last auf 100% geschossen. Ein Grund konnte hierfür aber noch nicht gefunden worden. Nach 2-3 Min ist die CPU last wieder runtergegangen und alles funktionierte wie davor.

    Wir haben ebenfalls ein Call offen #7142510 (seit 23.02 keine Antwort) bei dem der Anruf stehen bleibt. Bei diesem Fall wahren es verschiedene Calls (z.B Telefonkonferenz). Nachdem der Call hängen bleibt kann der User machen was er will er bleibt rot/besetzt. Nur ein neustarten der Anlage hilft weiter.

    Habe das selbe Problem und dein Vorschlag war auch mein erster Gedanke. Leider findet ich in meinen Fällen kein Channel der zu dem Anruf passt.

    Hallo Rainer,


    wird hatten einen ähnlichen fall und Grund hierfür war nach sehr lange recherche der DNS. Schau mal auf deinen Cache Timer.


    Beim Telekom Siptrunk steht im Contact header "ID@th1". Dies versucht die Starface über DNS aufzulösen. Th1 wird allerdings nie aufgelöst werden.


    In der Zeit in der er versucht th1 aufzulösen gibt es keine Sprachübertragen da die Starface kein ACK sendet.


    Der Fehler tritt immer dann auf wenn der DNS Server den eintrag th1 verliert und wieder versucht aufzulösen.


    Das Fehlerbild ist zu erkennen in dem im TCP Dump mehrere ACKS der Telekom kommen und nach X Sekunden die Starface auf alle ACKs gleichzeitig Antwortet.

    was ist das für ein Modul?


    Das ist die Zeitgesteuerte Umleitung.


    Ich glaube man konnte einstellige Rufnummern auch einfach über einen zusätziche Rufnummer anlegen.


    Sprich: Einzelrufnummer : 9


    Vielleicht wurde das aber auch mal rausgenommen..


    Hallo Slu,


    wir haben bei einem Kunden genau das selbe Problem. Seit dem Firmwareupdate, welche mit dem SF Update auf V7 gekommen ist, ist das DECT jetzt 3x in 2 Wochen mit dem selben Fehler zusammengebrochen. Ich schicke die Logs nun mal zu Gigaset + Starface.

    Hallo Sebastian,


    du kannst die Zeitgesteuerte Uml. auf z.B. die Gruppe Bereitschaft (600) umleiten und die 600 nach X sekunden (z.B. 2) auf die Rufnummer des Handys umleiten. Wenn dann User X in der Gruppe ist sieht er die Anrufe.


    Ich gehe davon aus, dass das die Telefonpasswörter sind.

    Hallo Zusammen,


    mirist Aufgefallen, dass das Starface Adressbuch auf einem Endgerät wie z.B. ein Yealink überhaupt nicht nutzbar ist.


    Wenn man dort einen Bentuzer der Anlage aufruft bekommt man alle Rufnummern inklusive Gruppenrufnummern angezeigt. Alle Rufnummern haben vorne (SF) D.h. der User muss raten wo er jetzt anruft.


    Meines erachtens nach ist es ein Bug, laut Starface ist es so gewollt.
    Die vorgeschalgenene Lösung: Es ist vorgesehen BLFs zu definieren. Bei 300 Usern ist diese Lösung aber nicht umzusetzen.


    Aus diesem Grund habe ich mal einen Featurerequest erstellt. Das Starface Adressbuch sollte meines erachtens nach komplett überarbeitet werden. (Zugriffsrechte auf Ordner etc.)


    Hier der Link:
    https://starface.useresponse.c…berholung-des-adressbuchs