Posts by Layer8Problem

Das muss der Konflikt mit Teams sein.

Es kann nunmal nur ein System geben welches den Status im Outlook aktualisiert.

Haken bei Teams raus oder eben bei Starface raus.

Hey Slu,

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

Quote from slu

Schau mal mit

openssl s_client -connect IP:PORT

welches Zertifikat da kommt, vielleicht ergibt sich da ein Hinweis.

Hey Slu,

auch bei einer Abfrage wird das Zertifikat angezeigt:

das einzige was ich nicht weiß ist ob zufällig wieder das Cipher nicht akzeptiert wird:

Protocol : TLSv1.2

Cipher : ECDHE-RSA-AES256-GCM-SHA384

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?

Hallo Torsten,

wenn sowas passiert ist meistens das Problem das der Tomcat Keystore verloren gegangen ist oder beschädigt ist. Du findest hier im Forum auf jeden Fall Beiträge dafür. Den genauen Befehl kenne ich aktuell nicht.

Quote from Christoph (PM)

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.

Guten Tag Zusammen,

die Rufliste wurde nun mit Version 7.3 überarbeitet. Man sieht die Anrufe bei einer Weiterleitung aber immer noch nicht.

Mit welcher Version möchtet ihr das Problem denn Fixen? Es ist mittlerweile schon ein Jahr Vergangen...

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.

Quote from FabianZ

Wir haben das auch vereinzelt beobachtet, wir können es aber nicht zuverlässig nachstellen.

In unserem Fall war dann immer ein einzelner Call-Channel im Asterisk noch offen.

Ihr könnt das Prüfen, indem ihr per SSH

Code

asterisk -vvvvvrx 'core show channels verbose'

Falls ihr einen einzelnen aktiven Channel seht, könnt ihr versuchen diesen per:

Code

asterisk -vvvvvrx 'channel request hangup <channel>'

aufzuhängen.

MfG

Fabian

Display More

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.

Guten Tag BlueShift,

am besten einfach mal einen TCP-Dump erstellen und schauen was die Anlage genaue macht. Wenn dort nur ein Register abgesendet wird liegt es an etwas anderem.

Theoretisch reicht es aus im benutzen DNS Server einen eintrag für th1 zu machen und diesen auf irgendeine IP zu mappen.

Das ist natürlich unschön aber es funtkioniert..

Eventuell funtkioniort die Lösung von bytegetter auch..

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.

Quote from Jeri

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

Stefan kuehn

Wird hier nur DND Gesetzt oder kann auch z.B. der Chatstatus etc. Verändert werden?

Quote from d i r k

Habt ihr denn bereits Version 7.0.2.1 mit "Gigaset N670/N870: Firmwareupdate auf Version 2.39.1" installiert?

Hey Dirk,

das hab ich schon gelesen. Ich werde das Update auf jeden Fall einplanen. Was ich nur komisch finde ist, dass der Kunde meines erachtens nach überhaupt keine Voicemail benutzt...

Falls es aber das Problem sein sollte wäre das natürlich Klasse

Quote from slu

So sehe ich das auch.

Jetzt kann ich dir folgen, evtl. man den DECT Manager austauschen?
Vielleicht liegt ein Hardware Problem vor oder Unterspannung bei PoE?

Ansonsten wird da nur der GigasetPro Support helfen können...

Display More

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.

Quote from nucom

Es gibt in der DB in der Tabelle setup einen Key security.password.policy.user
Ich nehme an, dort kann man Statt SECURE eventuell PARANOID hinterlegen.

Was das genau bewirkt, weiss ich jedoch nicht.

MfG

Fabian

Display More

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