[Gelöst] OpenStage 40 plötzlich mit "Telefonie ausgefallen"

[artanis]

Hallo zusammen,

seit gut zwei Jahren betreibe ich erfolgreich ein Unify OpenStage 40 an einer Fritz!Box 7490. Bei der Einrichtung bin ich damals der hier im Forum zu findenden Anleitung zur Einrichtung gefolgt (Danke dafür!) und konnte bisher nicht klagen, alles funktionierte einwandfrei. Seit einigen Tagen jedoch kann ich keine Anrufe mehr absetzen. Nach einem Neustart des Telefons erscheint die Meldung "Telefonie ausgefallen (LI1) Ausgehende Telefonie nicht möglich".
Ich habe bereits die Fritz!Box neugestartet, ebenso das Telefon mehrfach. Auch die Einrichtung eines neuen Telefoniegerätes in der Fritz!Box (unter Beachtung der neuen 8-Zeichen-Benutzername-Regel) nebst Rekonfiguration des Telefons hat nichts gebracht.
Eingehende Verbindungen sind hingegen möglich und werden von der Fritz!Box wie vorgesehen weitergeleitet.
Einzige Änderung in meinem Netzwerk in den vergangenen Tagen war das Update der Fritz!Box-Firmware von 7.11 auf 7.12.

Ich bin mit meinem Latein am Ende, zumal eingehende Anrufe funktionieren und das Log für mich keine Anhaltspunkte mehr liefert. Hat jemand eine Idee, woran dieses Verhalten liegen könnte?

Beste Grüße
Oliver

 

[pw2812]

Hallo @artanis,

laut Fehlermeldung und deinen eigenen Versuchen ist nur die ausgehende Telefonie betrofffen. Hast du denn schon einmal geprüft, ob ausgehende Telefonie über die verwendete Rufnummer grundsätzlich möglich ist? Du könntest testweise (falls vorhanden) z.B. ein analoges Telefon, ein DECT-Mobilteil oder die FritzFon App an deiner FB anschließen/anmelden und als abgehende Rufnummer jene einstellen, welche sonst dein OS 40 verwendet.

In deinen Logfiles ist mir aufgefallen, dass du als SIP-Registrar die IP-Adresse 192.168.1.1 (vermutlich die IP-Adresse deiner FB 7490) aber als DNS-Server die 192.168.1.9 verwendest. Ist das so gewollt? Welches Gerät mit der IP-Adresse 192.168.1.9 stellt denn in deinem Netzwerk den DNS-Server bereit?

 

[koyaanisqatsi]

Moin Moin

Auch die Einrichtung eines neuen Telefoniegerätes

Die werden für Auslandsgespräche und SIP URI Kurzwahlen automatisch in Quarantäne genommen.
Schon überprüft ?
Telefonie > Eigene Rufnummern > Anschlusseinstellungen > Sicherheit

Ansonsten, bis auf den lokalen DNS, worauf wir uns keinen Reim drauf machen können, registriert es sich brav und sogar der Anrufbeantworter...

SUBSCRIBE sip:[email protected];transport=udp SIP/2.0
Via: SIP/2.0/UDP 192.168.1.35;branch=<hash>
Max-Forwards: 70
From: <sip:[email protected]:5060>;tag=<hash>
To: <sip:[email protected]>
Call-ID: <hash>
CSeq: 1593344079 SUBSCRIBE
Allow: NOTIFY
Contact: <sip:[email protected]:5060;transport=udp>
Event: message-summary
Expires: 3600
User-Agent: OpenStage_40_V3 R3.40.0      SIP  150619
Content-Length: 0

...wird richtig abonniert

Wobei die Nummer bei CSeq: abartig hoch ist.
Das könnte darauf hindeuten, dass SIP Anfragen Amok laufen und die FRITZ!BOX sich "angegriffen fühlt".

 

[artanis]

Hallo zusammen,

viele Dank für die schnellen Reaktionen!
Weise ich die betroffene Nummer einem anderen Endgerät zu (in meinem Falle einem Fritz!Fon), so kann ich damit problemlos nach draußen telefonieren.
Bei dem DNS-Server handelt es sich um einen Odroid C2 mit installiertem Pi-Hole. Der läuft aber nun auch schon seit gut einem Jahr und hat bisher im Zusammenspiel mit dem OpenStage keine Probleme gezeigt. Allerdings hatte ich den auch schon im Visier und eigentlich vor, im OpenStage mal den DNS umzukonfigurieren. Allerdings wird mir der Eintrag unter Network -> General IP configuration nur angezeigt, änderbar ist er nicht. Eine andere Möglichkeit, das über die Weboberfläche zu ändern, habe ich bisher nicht gefunden.

Unter Telefonie > Eigene Rufnummern > Anschlusseinstellungen > Sicherheit in der Fritz!Box sind die Einstellungen, wie im Anhang zu erkennen. Habe dort auch keine Änderungen vorgenommen in letzter Zeit.

Viele Grüße
Oliver

 

[koyaanisqatsi]

Also ists OK, dass bei dir alle IP-Telefone keine Auslands-, oder SIP URI Kurzwahlen machen dürfen.

 

[Micha0815]

Mit diesem Problem -hier ein Raspi-Pi-Hole- hatte ich auch zu kämpfen, nachdem ich FW-Update 7.11->7.12 auf einer FB7590 gemacht hatte und anschliessend/gleichzeitig den Pi-Hole

 Pi-hole Version v4.3.1 Web Interface Version v4.3 FTL Version v4.3.1

geupdatet habe.
LG

 

[artanis]

@Micha0815 Das sieht bei mir genauso aus:

  Pi-hole version is v4.3.1 (Latest: v4.3.1)
  AdminLTE version is v4.3 (Latest: v4.3)
  FTL version is v4.3.1 (Latest: v4.3.1)

Jetzt wäre meine Frage an Dich: Konntest Du das Problem bei Dir lösen und wenn ja, wie?

Beste Grüße
Oliver

--

Hi,

Wobei die Nummer bei CSeq: abartig hoch ist.
Das könnte darauf hindeuten, dass SIP Anfragen Amok laufen und die FRITZ!BOX sich "angegriffen fühlt".

Wie kann man denn herausfinden, ob da SIP-Anfragen Amok laufen und wenn ja, was kann man dagegen tun?


Viele Grüße
Oliver

 

[koyaanisqatsi]

Zum Herausfinden: Erweiterte Supportdaten übers FRITZ!BOX Webinterface erstellen und anschliessend in dieser Textdatei nach CSeq: suchen
( Achte darauf, wie die Nummer hochgezählt wird )

Zum Tun: Vielleicht erst mal MWI deaktivieren, wenn sich das CSeq: Nummernraufzählen darauf bezieht

 

[artanis]

Hallo,

ich habe mal den SIP log Auszug aus den Support-Daten angehängt. Ich hoffe, er ist ausreichend anonymisiert...
CSeq wird fortlaufend hochgezählt, Lücken kann ich keine erkennen.

 

[koyaanisqatsi]

Das Log sieht OK aus.
Nur für die hohe CSeq: Nummer besteht weiterhin Erklärungsbedarf.
Bei der Registrierung der Telekomnummer ist sie "nur" vierstellig.
...keine Ahnung was da los ist.

Hier mal zum Vergleich, SNOM 320 bekommt Antwort von einer 7590 auf erfolgreiche Registrierung...

Received from udp:192.168.188.1:5060 at Aug 21 10:18:15.716 (865 bytes):

SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.0.2:5060;branch=<hash>;rport=5060;received=192.168.188.9
From: <sip:[email protected]>;tag=<hash>
To: <sip:[email protected]>;tag=<hash>
Call-ID: <hash>
CSeq: 738 REGISTER
Contact: <sip:[email protected]:5060>;q=1.0;reg-id=1;audio;mobility="fixed";duplex="full";description="snom320";actor="principal";events="dialog";methods="INVITE,ACK,CANCEL,BYE,REFER,OPTIONS,NOTIFY,SUBSCRIBE,PRACK,MESSAGE,INFO";expires=300
User-Agent: AVM FRITZ!Box 7590 (UI) 154.07.11 (Jul 3 2019)
Supported: 100rel,replaces,timer
Allow-Events: telephone-event,refer,reg
Allow: INVITE,ACK,OPTIONS,CANCEL,BYE,UPDATE,PRACK,INFO,SUBSCRIBE,NOTIFY,REFER,MESSAGE,PUBLISH
Accept: application/sdp, multipart/mixed
Accept-Encoding: identity
Content-Length: 0

 

[Micha0815]

Konntest Du das Problem bei Dir lösen und wenn ja, wie?

Naja ich hoffe doch. Dazu muss ich etwas weiter ausholen, um Missverständnisse bzgl. meines Aufbaus möglichst zu verhindern und um damit verbundene Besonderheiten zu erläutern.
Die Master-FB7590 hängt am VVDSL im EG und via WLAN-Repeatermode im 5GHz-Netz meine FB7590 (beide ohne MESHing bzw. als MESH-Master) An meiner hängt der Raspi-Pi-Hole, da an der Master-FB kein LAN-Port mehr frei.

Der erste zu erkennende Effekt war, das bei vormaliger Einstellung sowohl am Pi alsauch der Master-FB -dort unter den "eigenen" DNS-Einstellungen- regelmässig nach einer gewissen Zeit die SIP-Registrierungen flöten gingen und nach einer Stunde die roten LEDs ansprangen. Durch try+error habe ich im Laufe der Zeit eine für mich funktionierende Einstellung sowohl in der Master-FB alsauch dem Pi-Hole gefunden, der auch in meiner besonderen Konstellation funktioniert. Als Hauptproblem sah ich für mich, dass der Raspi über das WLAN bei einem Reboot der Master-FB wohl zuspät -bis über das WLAN der Pi erreichbar ist dauert es etwas- zur Verfügung stand, sodass die SIP-Registrierungen fehlschlugen.
Wählte ich neben der lokalen IP des Raspi alternativ noch 1.1.1.1 oder 8.8.8.8 wurden diese permanent als "bevorzugt" hergenommen und die Blockfunktion des Pi war für die Katz.
Nach meinem laienhaften Verständnis sollte die FB für die SIP-Registrierung die "heimlichen/internen" DNS-Adressen 192.168.180.1 und 192.168.180.2 verwenden, die auf die ISP-DNS-Server zugreifen und u.a. für dessen SIP-Registrierungsserver zuständig sind, da diese u.U. über öffentliche DNS-Server nicht auffindbar sind.

Durch try+error funktioniert hier folgende Einstellung.
In der Master-FB habe ich die lokale Raspi-Pi-Hole-IP sowohl als DNS1 alsauch DSN2 eingetragen.
Im Pi-Hole sieht es so aus

Dies hat zwar den Nachteil, dass ich im Pi-Hole nur die FB als Client sehe und was geblockt wird. Nur stört es mich nicht, nicht zu wissen, welcher FB-Client was aufgerufen hat bzw. was von ihm initiiert geblockt wurde.
LG und ohne Gewähr

 

[artanis]

@Micha0815 Vielen Dank für die Infos! Das werde ich bei Gelegenheit ausprobieren (mir fehlen aktuell Zeit und Ruhe). Ich verstehe das soweit, als dass das eine der möglichen Varianten des Einbindens des Pi-hole in ein lokales Netz ist (DNS-Anfrage an Pi-Hole -> von dort an die FritzBox -> von dort an den Provider). Ich habe die andere Variante gewählt (DNS-Anfrage an Pi-Hole -> von dort an den Provider), die bisher auch problemlos funktioniert hat.

Ich melde in den nächsten Tagen auf jeden Fall zurück, ob es geklappt hat.

Viele Grüße
Oliver

 

[artanis]

Hallo zusammen,

folgende aktuelle Info zum Sachverhalt von meiner Seite: Ich habe den Pi-Hole aus dem Netzwerk entfernt, damit übernimmt wieder die Friitz!Box als DNS-Server. Das Problem besteht trotz Neustart von Fritz!Box und OpenStage 40 weiterhin...

Viele Grüße
Oliver

 

[pw2812]

Einzige Änderung in meinem Netzwerk in den vergangenen Tagen war das Update der Fritz!Box-Firmware von 7.11 auf 7.12.

Das Problem besteht trotz Neustart von Fritz!Box und OpenStage 40 weiterhin.

Man liest hier im Forum davon, dass auch andere Nutzer seit dem FW-Update auf Version 7.12 Probleme mit der ein- und ausgehenden Telefonie haben. Du könntest mal "einen Gang runterschalten", sprich zurück zur vorherigen FW-Version gehen und schauen, ob es damit wieder klappt. Ein recovern ist dazu nicht zwangsläufig nötig, da du die "Startpartition" deiner FB umschalten kannst. Wie das geht, steht hier im IPPF beschrieben. Evtl. funktioniert dann auch wieder dein pi-hole-Konstrukt.

 

[artanis]

Hallo zusammen,

nachdem sich in den letzten Tagen herausgestellt hat, dass auch die zwei per DECT verbundenen C4-Mobilteile Probleme mit der Telefonie hatten (kein Empfang von Anrufen, sie klingelten einfach garnicht und der AB sprang an), habe ich den von @pw2812 vorgeschlagenen Weg eingeschlagen und per linux_fs_start die Startpartition verbogen. Und siehe da, nach dem Reboot in die Version 7.11 läuft die gesamte Telefonie wieder ohne Probleme.

Vielen Dank an alle Mitglieder für die Unterstützung und die hilfreichen Tips!
Oliver