SNOM Tischgeräte mit pascom.cloud legen nach 5 Sekunden auf

Seit heute früh legen die snom-Tischtelefone nach 5-6 Sekunden einfach auf.
Fehler tritt bei 3 Anlagen und nur mit snom Tischtelefonen auf!
Softphone und Yealink-Schnurlose sowie die M300 mit 2 schnurlosen Teilen funktionieren einwandfrei.

Bitte um Info, wann der Fehler behoben wird!

Fehlerlösung bei uns war:

In der Basis-Konfiguration der SNOM-Telefone ein zusätzlicher Eintrag:

check_fqdn_against_server_cert&: off

und ein Firmware-Update auf 10.1.37.11 - 10.1.33.x und 10.1.24.x sind beide keine Lösung.

Hoffe, es hilft.

  • Julian

P.S. - Sollte nur als Ausweichlösung gelten, Pascom ist an dem Thema weiter dran, die wissen auch schon, woran es liegt.

Die Ausweichlösung kann ich soweit bestätigen.

Musste die aktuellste Firmware sein und in die Basiskonfiguration:

check_fqdn_against_server_cert&: off

eintragen. Mit “check_fqdn_against_server_cert!=off” hat es nicht funktioniert.

Dann kann man erstmal wieder telefonieren.

Hm, scheint bei mir nicht zu funktionieren, habe das gerade bei meinem D375 / Firmware 10.1.33.33 versucht, also:

{{!-- TLS cert check issue workaround --}}
check_fqdn_against_server_cert&: off

ganz am Anfang (zufügen am Ende ändert auch nichts am Fehler) in eine vom pascom SNOM Template duplizierte neue Basis-Konfig eingetragen und dem Telefon zugeordnet, das rebootet danach auch, aber die Call-Abbrüche sind nach ca. 5-10sec immer noch da :disappointed:

Ich vermute mal, dass das Problem auch mit der Proxy Migration zu AWS vom WE zu tun hat, aber müsste das nicht sehr, sehr viele User betreffen, da Grundfunktion und SNOM?

Die 10.1.33.33 scheint hier auch kaputt zu sein - bitte mal mit der 10.1.37.11 mit der angepassten Basiskonfiguration versuchen, dann sollte es wieder klappen.

Danke, ja mit der FW 10.1.37.11 UND der Anpassung der Basis-Konfig

{{!-- TLS cert check issue workaround --}}
check_fqdn_against_server_cert&: off

läuft es nun wieder fehlerfrei :slight_smile:

1 Like

Bei mir hat es nur nach beiden (Firmwareupdate auf 10.1.37.11 UND der Eintrag in der Basiskonfiguration) Änderungen geklappt.

Hatte hier eine Anlage bei der ich nur das Update eingespielt habe und bei einer anderen nur die Basiskonfiguration geändert habe. Beides ohne Erfolg - erst der jeweils zusätzliche Schritt brachte Erfolg.

Der Eintrag in der Basiskonfiguration steht bei mir aber in der letzten Zeile und funktioniert einwandfrei.

Teilweise laufen die Anlagen schon mehrere Monate auf älteren Firmwareständen der snoms - ohne Probleme.
Haben den Fehler erst heute früh entdeckt (nach Arbeitsbeginn), so dass ich auch stark auf die Umstellung vom Wochenende tippe.

Hallo @Conrad.Hahl,

ja, das können wir so bestätigen. Beide Schritte sind notwendig. Und ja, seit dem Wochenende arbeiten wir mit Lastverteilung. Deshalb bekommen die SNOM Telefone von unterschiedlichen IP-Adressen Sprachdaten. Das ist nichts ungewöhnliches führt jedoch bei 10.X SNOMs zu dem beschriebenen Problem und lässt sich nur mit dem Schalter und der aktuellen Firmware wieder lösen.

LG
Mathias

Das ist ja auch super, dass die pascom.cloud nun mit Lastverteilung arbeitet.

Aber testet Ihr die Umgebung nicht vorher? Die snom sind ja nicht sooo selten - zumindest bei uns - und da kann man doch mal ein Gerät in einer Testumgebung durchtesten.

Ich finde es halt schade, dass wir bei den Kunden vor Ort keine Info darüber bekommen. Wenn wir das vorher wissen, können wir die Updates und Konfigs ja entsprechend einspielen.

So wie ich das nun verstanden habe, bleibt das “Ausweichmanöver” nun als standard oder?
Jetzt muss die Standard-Basiskonfiguration von Euch für snom auch noch in der pascom.cloud geändert werden oder wie soll das Thema zukünftig behoben werden?

Der Fehler tritt ja anscheinend “nur” auf, wenn der Kunde die pascom.cloud nutzt und snom-Telefone im Einsatz hat.

Wir haben für unsere pascom.cloud drei stages: alpha, beta und productive. Jede Änderung durchläuft alle Stages. Wir testen einen ganzen Katalog von Endgeräten und Funktionen. Leider haben unsere SNOM Test-Modelle mit deren Firmwares funktioniert.

Hier werden wir in Zukunft für eine besser Verteilung der Firmwarestände sorgen.

Alles in allem ein recht unglücklicher Fehler. Ich hoffe auf euer Verständnis.

Wir sprechen gerade mit SNOM was man hier machen kann.

Wir haben heute bei einem Kunden diesen Fehler in Verbindung mit Yealink T48S Geräten.

Zudem spielen die BLF-Verrückt. Teilweise Grün, obwohl man schon länger telefoniert. Irgendwann werden die dann rot und nach dem Auflegen bleiben die dann rot. Im aktuellen Fall bei uns nun schon seit min 5-Minuten.

Hallo @NAS

danke für die Meldung aber wir können keine Probleme mit T48S Geräten nachvollziehen.
Welche Firmware verwendest Du genau?

LG
Mathias

Ich hatte das gestern auch mit einem einzigen T48S und nur bei eingehenden Verbindungen. Allerdings an einer 17.12 onsite - also ein wenig abseits von diesem Thread. Dahler lege ich dazu gleich noch einen eigenen Thread an mit alle notwendingen Infos.

Update:
Ich konnte inzwischen feststellen, dass es dann auftritt, wenn der Softclient in der aktuellen Version gestartet ist und als Gerät für abgehende Gespräche konfiguriert ist.

Gespräche, die man dann auf einem dem ebenfalls dem Benutzer zugewiesenen Yealink T48S-Endgerät annimmt, brechen nach 5 Sekunden ab

Schließe ich den Softclient, erfolgt kein Abbruch.

Pascom Onsite 17.12
Yealink T48S 66.81.0.110

Scheint also, als ob es irgendwie mit dem letzte Updates des Softclient zu tun hat, da sich andere Komponenten (17.12, Firmware Yealink) seit mind. 6 Monaten nicht verändert haben.

Gruß
Michael

Hallo @noses,

ich habe eben vergeblich versucht das mit einem T48 (Firmware 35.81.0.110) und einer 17.12 nachzuahmen.
Ist ein Headset angeschlossen? Tritt das Problem bei internen und externen Gesprächen auf? Ist vor dem Abbruch noch Audio vorhanden?
Die Support-Info-Datei (am besten Client mit --logSipMessages und --logXmppMessages starten) und ggf. ein Asterisk-CLI-Trace sollte uns hier schon weiterhelfen.

Besten Gruß
Sebastian

Hallo @Sebastian_F

ja, ein Headset ist angeschlossen, allerdings am PC (Softclient). Probiert habe ich es nur mit externen Anrufen und dort auch nur mit eingehenden Anrufen (abgehend werden die ja über Headset und Softclient geführt).

Audio konnte ich nicht wahrnehmen.

Gruß
Michael

PS: Für die Logfiles muss ich da erst wieder hinfahren… das kann also ein paar Tage dauern…

In dem Fall bitte zum Test auch einmal den Headset-Support für alle Hersteller deaktivieren.

Besten Gruß
Sebastian

Hallo Sebastian,

die sind ziemlich angenervt aufgrund der Thematik. Daher hat es für Logfiles nicht gereicht. Aber ich kann Dir sagen, dass das Verhalten nicht auftritt, wenn man den Headset-Support (in dem Fall Plantronics) deaktiviert, also von ‘Auto’ auf ‘ignorieren’ umstellt. In dem Moment werden die am Tischtelefon angenommenen Anrufen nicht mehr einfach beendet.

Gruß
Michael

Hallo @noses,

schade, das macht Hilfe natürlich schwieriger. Kannst du uns wenigstens sagen welche Plantronics-Headset Modelle hier verwendet werden?

Grüße,
Jan