Failover Identitäten Snom 7.3.7

[herrmax]

Hi Leute,

Mein Problem mit Snom300+320 Firmware 7.3.7

Struktur:
1xASTERISK bristuff Primär-Server mit E1-Anschluss
1xASTERISK bristuff FAILOVER-Server mit Voip-Anschluss
ca. 70 Snom300 mit FW 7.3.7

Konfig:
Jedes Snom300 hat 2 Identitäten:
Identität1: Anmeldung am Primär-Server mit Failover auf Identität 2
Identität2: Anmeldung am Failover-Server.

Problem:
Manchmal aus heiterem Himmel und ohne erkenntlichen bzw. nachvorllziehbaren Grund, verwendet das eine oder andere Snom die Failover-Identität und damit den FAllback-Server um raus zu telefonieren (nicht immer die selben - nein, immer andere!!), obwohl der Großteil der anderen Snoms brav auf der Identität1 also dem Primären Server verbleiben.
Natürlich ist der Primäre Server im Lan nach wie vor erreichbar.

Leider lässt der Snom-Support völlig aus und können nach ZIG-mails einfach nicht bekannt geben, was die Bedingugnen für das switchen ist!

AUch habe ich einen 5MB-Debug an Snom geschickt - auch erfolglos!

Kann jemand von euch mit debug-Dateien etwas anfangen?
Kennt ihr das Problem?
habt IHr Ideen wie ich den Fehler einschränken könnte?

Besten Dank,
markus

 

[Ottone]

Hi Markus!

1. Die Firmware 7.1.30 ist alt (und die Überschrift Deines Postings spricht irreführenderweise von 7.3.1)

2. Ein Failover tritt (nur dann) auf, wenn das Telefon sich nicht registrieren kann, es spielt das Registrierungsintervall eine wichtige Rolle.

3. Oft sind DNS Problem Grund für Probleme, hier schafft die Verwendung von IP Adresse (und nicht Hostnamen) idR Abhilfe.

 

[herrmax]

Hello Ottone,
danke für dein Feedback...

1.) falsche Überschirift stimmt - Version ist 7.3.7 !!! SORRY!!!
2.) ich habe den Registrierungsintervall auf 60Sekunden bei ALLEN Telefonen eingestellt. kann dies das problem sein? Ich frage mich auch, warum sich 50-60 Telefone korrekt registieren können, aber 1 od. 2 nicht!?!? Wie oft probieren die Snoms die Registrierung bis diese zur Failover-Idenität wechseln?
3.) ich verwende nur die IP-Adresse im Registrar. Beide Server befinden sich mit statischen IP´s im LAN auch mit anderen Servern. Könnte es zu sonstigen Konflikten kommen?

Danke nochmals.
lg
mex

 

[Ottone]

2.) ich habe den Registrierungsintervall auf 60Sekunden bei ALLEN Telefonen eingestellt. kann dies das problem sein? Ich frage mich auch, warum sich 50-60 Telefone korrekt registieren können, aber 1 od. 2 nicht!?!?

Wenn Du diese Telefone z.B. zentral über einen PoE switch alle zeitgleich anschaltest, dann könnte der SIP Registrar plötzlich übefordert sein. Für solche Fälle gibt es ein passendes delay setting im SNOM um die Anfragen zeitlich verteilen zu können.

Vielleicht spielt auch Dein switch Dir den einen oder anderen Streich, oder aber Dein DHCP server. Schliesslich: Schon einmal firmware 7.3.14 ausprobiert?

Wie oft probieren die Snoms die Registrierung bis diese zur Failover-Idenität wechseln?

Ein Blick in das SIP log des SNOMs sollte es Dir sofort verraten.

P.S.: Die Überschrift ist immer noch nicht korrekt

 

[herrmax]

Hi Ottone,

danke nochmals fürs Feedback.
Also - das ist der STatus:
1.) Registrierungs-Intervall: Die Telefone laufen schon seit Monaten - daher unwahrscheinlich, dass es zu einem "Anfrage-Stau" bzw. Überlauf kommt oder - was meinst du??
2.) Delay-Setting: das kenn ich nicht! Welches meinst du? Habe auch gesucht - aber nix gefunden?? Wäre natürlich ein Hammer!!!
3.) Log-File: Das dumme ist, dass das Snom-interne Logging SEHR kurz ist. Bis ich dahinter komme, welches Snom gerade auf die Identität 2 wechselt, ist der Log nicht mehr aktuell. Ich habe allerdings ein DEbug-File, wo ein Snom umgefallen ist. doch leider kann werder SNOM noch ich damit etwas anfangen!
4.) Snom-Support: EIN WITZ!!! sonst kein Kommentar!
5.) Firmware: Firmware-Wechsel auf Verdacht taugt mir nicht so! Vor Allem, wenn seitens Snom dahingehend keine klare Aussage kommt, dass die 7.3.14 dieses Problem behebt...

Steh dort echt an!! Der Kunde (wichtiger Kunde!) ist schon STOCKSAUER!!

danke Euch.
lg
mex

PS: Wie kann ich eine Überschrift im Forum ändern????

 

[Ottone]

Registrierungs-Intervall: Die Telefone laufen schon seit Monaten - daher unwahrscheinlich, dass es zu einem "Anfrage-Stau" bzw. Überlauf kommt oder - was meinst du??

Das hat mit Wahrscheinlichkeiten nichts zu tun, wenn Du sie alle zeitgleich anschaltest, dann erneuern sie auch zeitgleich. Du hast nicht gesagt ob Du das tust.

Delay-Setting: das kenn ich nicht! Welches meinst du? Habe auch gesucht - aber nix gefunden?

Also der erste hit in Google mit "snom registration delay" führt schon fast zum Ziel, nur das es hier um subscriptions geht. Gemeint habe ich "Max. Startverzögerung (Sek)" (Stichwort max_boot_delay).

Log-File: Das dumme ist, dass das Snom-interne Logging SEHR kurz ist.

Dann mach auf Asterisk Seite ein längerfristiges SIP DEBUG für diese IP, und schalte evtl. qualify=yes an. Die könntest u.U. ein passendes event der Aktion URLs zur besseren Überwachung einsetzen welches Dir dann vielleicht sogar sofort das aktuelle SNOM log holen und speichern kann.

Snom-Support: EIN WITZ!!! sonst kein Kommentar!

Nein, ist er nicht.

Firmware-Wechsel auf Verdacht taugt mir nicht so! Vor Allem, wenn seitens Snom dahingehend keine klare Aussage kommt, dass die 7.3.14 dieses Problem behebt...

Du bist der Integrator, also musst Du etwas tun, von selbst wird sich das nicht lösen. Vielleicht sind die SNOMs einfach defekt, oder Du hast ein Kabelproblem, ein Problem mit einem Switchport, oder solltest die Ethernet auto-negotiation fest auf 100 Mbit/s stellen... . Vielleicht hast Du auch mehrere DHCP server im Netz und die SNOMs kommen damit (immernoch) etwas durcheinander (siehe firmware changelogs). Meine Glaskuglen ist leider heute etwas vernebelt.

Steh dort echt an!! Der Kunde (wichtiger Kunde!) ist schon STOCKSAUER!!

PS: Wie kann ich eine Überschrift im Forum ändern????

Ich sag' jetzt mal nix, bis auf: Editieren --> Knopf "Erweitert" drücken.

 

[alf296]

Stellungnahme snom support

Hallo,

ich möchte als Vertreter des snom supports mal eine kurze Zusammenfassung der bisherigen Verlaufs posten:

Es ist eine Tatsache,dass:
1) die Gründe für einen regulären Failover herrmax gleich nach Öffnen des Trouble Reports genannt wurden, nämlich "wenn die Erneuerung der Registrierung am primären SIP Server fehlschlägt". Seitdem gibt es einen intensiven Mailverkehr (ca. 12 Follow- Ups) mit support & Entwicklung.
2) snom support / Entwicklung das Problem nicht reproduzieren können und der gelieferte Syslog nicht aussagekräftig genug ist, da Failover nicht explizit geloggt werden; leider kann uns herrmax auch keinen Ferndiagnose- Zugriff für eigene Tests geben.
3) Troubleshooting -Vorschläge geliefert worden sind:
a) FW Update auf 7.3.14 --> Grund: allgemeine Stabilitätsverbesserung, seit der 7.3.7 ist einiges getan worden.
b) Konfiguration einer pimären SIP Identität eines ANDEREN SIP Servers (auch extern) und einer zweiten vorhandene Failover- Identität auf einem dedizierten Test- Telefon. Generierung von Kontrollanrufen. --> Wenn - ohne nachweislichem Ausfall des primären SIP Servers - ein Failover aufträte, ist das ein Hinweis auf einen Bug. Ansonsten muss man davon ausgehen, dass der primäre SIP Server zeitweise tatsächlich überlastet war, so dass die Registrierungsanfrage mehrerer Telefone gleichzeitig nicht erneuert werden konnte.

Wir bemühen uns wirklich, herrmax und vor allem dem Kunden zu helfen, aber dazu benötigen wir konstruktive Mitarbeit und keine missverständlichen Aussagen. Es liegt auch nicht in unserem Interesse weitere Diskussionen zu dem Thema anzufachen. Danke!

PS: Es gibt keine spezielle Delay- Funktion für Registrierungen seitens des snom, sondern nur für Subskriptionen/Boot Up: http://wiki.snom.com/Settings/subscription_delay / http://wiki.snom.com/Settings/max_boot_delay. Diese Aufgabe sollte der SIP Server durch Variation des "Expire" Wertes realisieren.

 

[herrmax]

Sehr geehrtes SNOM-Support-Team,

natürlich werde ich unseren Support-Case nicht in diesem Forum fortsetzen und daher auch keinen Bezug nehmen.

Dennoch benötigen wir Lösungen - die bisherigen Lösungsansätze haben alle nichts gebracht - und wir haben SEHR VIEL probiert - auch über den Vorschlägen von Snom hinaus.

Ein Vorschlag lautet auf 7.3.14 upgraden --> ist das ein "Versuch" oder eine Empfehlung der ich tunlichst nachgehen sollte? Bei 40 Geräten im Callcenter eher aufwändig, da von 09:00 - 21:00 täglich in Verwendung - daher zeitlich recht aufwändig...

lg
mex

 

[foschi]

Eine Lanze für snom

Vorab: ich bin auch Kunde von snom.

Ich halte den snom-Support für hilfreich, kompetent und sorgfältig. So kann ein Support nur arbeiten, wenn ihm vernünftige Problembeschreibungen, vernünftige Logs, ggf. ein Fernzugriff zur Verfügung gestellt sowie das Nachstellen des Problems in einer Testumgebung ermöglicht wird. *Das* ist IMHO die Mindestvoraussetzung.

Ich beobachte bei VoIP/SIP-Installationen von Integratoren oft eher PEBKAC als o.g. Voraussetzungen. Andererseits gibt es auch beim Support mal was was liegen bleibt.

@herrmax: bitte den Support direkt vom Hersteller in Anspruch nehmen. Der kann besser helfen als wir hier im Forum. Wir ergänzen aber gerne.

Zwei Dinge:
- ein failover-System gehört IMHO anders realisiert
- durch die Autoprovisionierung lässt sich *sehr* komfortabel die Firmware der snom-Endgeräte up-/downgraden.

 

[herrmax]

Hi foschi,
ich gehe konform, dass für einen zielführenden Support entsprechende Infos notwendig sind...
Daher habe ich auch ein Debug-File eines Telefones geschickt, dass die Switch der Identität protokolliert. Leider ohne Ergebnis! Auch hätte sich gerne jemand von Snom auf die Box+Telefone einloggen können - der Vorschlag kam nur nie (habe soeben ALLE mails durchgelesen)!!!

However - ich habe mich an das Forum gewendet, da ich mit dem Support nicht weiter gekommen bin und jemanden gesucht habe, der ebenfalls solch ein Problem hat!?!?!

@Failover anders realisiert: stimmt --> grundsätzlich hätte ich lieber mit Junghanns Failover-Switch gearbeitet - Kunde hat aber dagegen entschieden, da ja die Snom´s diese Funktion zur Verfügung stellen.
Auch vrrt hätte mir besser gefallen - however - die Funktion ist auf den Snom´s implementiert - daher habe wir diese verwendet...

@Firmware: spricht nichts dagegen die Gerät upzugraden - dumm nur, dass 30% der Snom´s beim neustart hängen bleiben und ich daher jedes einzelne kontrollieren muss ob upgrade ok. Von da her hab ichs noch nicht gemacht....

Ich habe Snom auch nie beschuldigt, dass der Fehler an den Telefonen liegt - aber ich kenne bis heute nicht die Bedingungen wann und warum die Failover verwendet wird? Gibt es Timeouts? Gibt es Retries?

Wie würdest du Failover zwischen 2 Asterisk realisieren?
Wie könnte ich den Fehler einschränken?

über Ideen wäre ich glücklich

lg
m

 

[Ottone]

vrrt: Was ist das?

Failover: Guckst Du z.B. hier (der SNOM Weg ist auch legitim, es ist aber immer die Frage welches Problem man genau lösen will). Vor dem Failover kommt aber überhaupt ersteinmal monitoring per Nagios oder Mon.

Failover Bedingungen: Einfach einmal selbst ein Failover Szenario bauen und dann austesten und mitloggen (und hier berichten). Ist sowieso zwingend notwendig wenn die Lösung verlässlich sein soll.

 

[herrmax]

hoppla - vrrp - meinte ich.
lg