Zeige Ergebnis 1 bis 5 von 5

Thema: Telefone (Yealink) lange offline nach Internetunterbrechung

  1. #1
    STARFACE Newbie
    Registriert seit
    27.07.2021
    Beiträge
    3

    Standard Telefone (Yealink) lange offline nach Internetunterbrechung

    Hallo,

    wir kämpfen derzeit mit einem sehr unglücklichen Verhalten eines Starface Cloud Setups bei einem Kunden, wobei die Yealink T53 Tischtelefone bis zu eine Stunde die Verbindung zur Starface Cloud verlieren bzw. nicht wieder aufbauen, nachdem es einen reconnect oder Failover der Internetleitung (= Änderung WAN IP Adresse) gab.

    Der Starface Support ist dran, aber ich wollte mich mal umhören, ob es ähnliche Erfahrungen mit der Kombination und evtl. gefundene Lösungen gibt.

    Zwischen Telefonen und Starface ist ein normales, VLAN segmentiertes Netzwerk und eine Sophos UTM mit insgesamt 3 WAN Leitungen (VDSL) im Einsatz.

    Der Yealink Support hat bestätigt, dass die Telefone sich alle 3600 Sekunden bei der Anlage neu registrieren. Ein manueller Neustart der Telefone lässt diese sich sofort wieder registrieren. Es scheint, als ignorierten die Telefone den Verbindungsverlust zur Anlage und warten einfach den Timer ab. Das würde erklären, warum die Telefone mal nach 20 Minuten, mal nach 45 Minuten wieder onlie sind.

    Wenn jemand eine Idee oder Erfahrung mit dem Fehlerbild hat, würde ich mich über eine Anwort freuen.

    Viele Grüße
    Felix

  2. #2

  3. #3
    STARFACE Expert
    Benutzerbild von andreas.stein
    Registriert seit
    04.12.2014
    Ort
    Bitburg
    Beiträge
    715

    Standard

    Ergänzend dazu mal der Hintergrund und die Systemgrenzen:

    Das Problem tritt auf, wenn die Internetverbindung durch den Router getrennt wird und der Router seine dynamische NAT-Tabelle (verständlicherweise) dabei löscht. Ab diesem Zeitpunkt kann die Starface nicht mehr mit dem Telefon kommunizieren, es kommen also auch keine Anrufe an den Telefonen an. Das Telefon muss sich also aktiv wieder bei der Starface melden, um die Verbindung wieder herzustellen. Eben dies passiert in der Standardeinstellung aber nicht korrekt, sodass tatsächlich erst nach dem Reregister-Timeout von 3600 Sekunden das Telefon wieder funktioniert.
    Über mein Modul wird die KeepAlive-Funktion im Yealink umgestellt auf "NOTIFY". Das passiert standardmäßig dann alle 60 Sekunden. Solange die Starface auf dieses Keepalive-Paket antwortet, passiert nichts. Kommt keine Antwort mehr von der Starface (weil Internetverbindung unterbrochen), wird im Telefon ein Reregister ausgelöst. Sobald die Verbindung wieder steht, registriert sich das Telefon also automatisch neu an der Starface.

    Ein Problemchen bleibt jedoch: Wenn beispielsweise eine PPPoE-Verbindung für den Internetzugang genutzt wird und diese verliert nur kurzzeitig für weniger als 60 Sekunden die Verbindung, kann es sein, dass das Telefon genau in diesem Zeitraum kein SIP NOTIFY sendet sondern nur kurz davor und kurz danach. Da die Starface auf beide antwortet, ist für das Telefon scheinbar alles in Ordnung. Es wird kein Reregister ausgelöst. Die Starface kann dann weiterhin keine Verbindung zum Telefon aufbauen, bis sich dieses neu registriert.

    PS: Das ist mein Kenntnisstand zur STARFACE 6.X, eventuell hat sich zur Version 7 durch den neuen Asterisk Unterbau ja etwas verändert...

    PPS: Anstatt das Telefon neu zu starten, reicht auch ein ausgehender Anruf vom Telefon, um ein Register auszulösen.
    Viele Grüße,

    Andreas Stein
    IT Fabrik Systemhaus GmbH & Co. KG

    STARFACE Excellence Partner

  4. #4
    STARFACE Newbie
    Registriert seit
    27.07.2021
    Beiträge
    3

    Standard

    Hallo Andreas,

    vielen Dank für den Hinweis und das Modul! Das scheint genau unser Problem zu sein und deckt sich haargenau mit der Hypothese, die ich selber hatte.

    Leider scheint es auch so zu sein, dass der Effekt eintritt, den du beschreibst: die Unterbrechungen sind zu kurz und die Keepalive Funktion hat keine Auswirkung.

    Alls Fallback funktioniert jedoch den Parameter account.1.sip_server.1.expires auf z.B. 180 Sekunden runterzusetzen. Somit sind die Ausfälle zumindest relativ kurz. Die 180 Sekunden wären laut Starface Support ein vertretbarer Wert.

    Wenn ich nun versuche, diesen Parameter in dein Modul als eigenen Parameter einzutragen, kommt dieser aber nicht in den Telefonen an. Kannst du mutmaßen wieso?

    Telefon-, Diensteneustart - alles versucht.

    Viele Grüße
    Felix

    Edit: Ich sehe gerade in den Thread zum Modul, dass du vor ca. einem Jahr mal geschrieben hast, dass man für T5x Geräte die Werte in das T4x Feld schreiben soll. Das hatte ich noch nicht versucht. Teste ich heute Abend.
    Geändert von stankewitz (16.08.2021 um 08:54 Uhr)

  5. #5
    STARFACE Newbie
    Registriert seit
    27.07.2021
    Beiträge
    3

    Standard

    Der Eintrag des Parameters in das T4xS Feld hat die Einstellung schlussendlich auf die T53W übertragen.

    Viele Grüße
    Felix

Ähnliche Themen

  1. Yealink-Telefone und Beistellgeräte
    Von bytegetter im Forum STARFACE Einrichtung & Administration
    Antworten: 10
    Letzter Beitrag: 15.02.2019, 16:03
  2. Nach Update lange Wartezeit (30++sec) bis Verbindung
    Von loosi im Forum STARFACE Einrichtung & Administration
    Antworten: 7
    Letzter Beitrag: 03.12.2012, 11:06
  3. Snom 370 nach kurzer Zeit offline
    Von slu im Forum STARFACE Einrichtung & Administration
    Antworten: 7
    Letzter Beitrag: 12.03.2010, 20:32
  4. [Gelöst] Alle Leitungen offline nach IP-Wechsel durch Provider
    Von goofy im Forum STARFACE Einrichtung & Administration
    Antworten: 3
    Letzter Beitrag: 29.01.2010, 08:41
  5. ISDN in Starface light nach einger Zeit immer offline
    Von Krockett im Forum STARFACE Einrichtung & Administration
    Antworten: 11
    Letzter Beitrag: 30.12.2009, 12:17

Lesezeichen

Forumregeln

  • Es ist Ihnen nicht erlaubt, neue Themen zu verfassen.
  • Es ist Ihnen nicht erlaubt, auf Beiträge zu antworten.
  • Es ist Ihnen nicht erlaubt, Anhänge hochzuladen.
  • Es ist Ihnen nicht erlaubt, Ihre Beiträge zu bearbeiten.
  •