[Problem] Kopplung 5520 funktioniert nicht mehr

[bospre]

Hallo zusammen,
nach dem Studium zahlreicher Forenbeiträge weiß ich nicht mehr weiter.
Ich betreibe zwei 5020 an 2 Standorten. Beide Anlagen arbeiten in getrennten Subnetzen die per VPN geroutet werden.
Die Anlagen sind per VOIP gekoppelt, d.h. eingehende Rufe auf der einen Anlage werden auf der zweiten Anlage signalisiert. Weiterhin kann man von Standort "B" über die Anlage an Standort "A" heraus wählen.
Soweit so gut. Das ganze hat jetzt einige Monate störungsfrei funktioniert.

Bis etwa seit Anfang Mai kein Sprachkanal mehr aufgebaut wird. Die Rufe werden signalisiert, aber beim Abheben hören beide Teilnehmer nichts. Legt einer auf, wird die Verbindung getrennt und der andere Teilnehmer hört das Besetztzeichen.

Ein Rest der beiden Anlagen half nicht
Da dieses Phänomen kurz nach der Aktualisierung auf die Firmware Version 4.00D auf (von der "C"-Version) auftrat, lag es nahe die Firmware auf den alten Stand zurück zu setzen. Doch auch das half nicht.
Als letztes Mittel habe ich dann einen Reset auf Werkseinstellung gemacht und die Konfiguration vom April wieder aufgespielt. Auch das half nicht.
Ich hatte nichts an der Konfiguration der beiden Anlagen geändert, bin aber natürlich alle Einstellungen durchgegangen und konnte keine Unstimmigkeit feststellen.

Somit bin ich im Moment ziemlich ratlos. Hat irgend jemand eine Idee was da falsch laufen könnte? Oder was ich vielleicht noch ausprobieren könnte?

Achja in dem zeitlichen Zusammenhang hat eine Tarifumstellung der Telekom an einem der VDSL-Anschlüsse stattgefunden, das kann aber nicht die Ursache sein, da es erstens nur den Tarif betraf und zweitens der Rest des VPN nach wie vor einwandfrei funktioniert.

Schon mal vielen Dank im Voraus für Ideen.
LG
Boris

PS Eben nochmal meinen Beitrag gelesen: Es handelt sich natürlich um die Auerswald 5020. Den Fehler in der Titelezeile kann ich anscheinend nicht mehr korrigieren.
Beide Anlagen sind übrigens mit dem 6VOIP-Modul ausgestattet.
Ansonsten stecken ISDN und POTS-Module drin, bzw. bei der einen nur ein Türmodul.

 

[gandalf94305]

Das deutet darauf hin, daß SIP funktioniert, aber RTP nicht. Prüfe nochmals die Einstellungen genau nach. Beim Import und Export von Konfigurationen werden ggf. Netzwerkeinstellungen nicht korrekt übernommen bzw. erfordern einen nochmaligen Reboot der Anlage.

Kannst Du prüfen, ob die den in den Anlagen angegebenen Portbereich für RTP/UDP weiterhin alle Routings über den VPN-Tunnel und relevante Portfreigaben weiterhin existieren?

--gandalf.

 

[noDialPlan]

Hallo Boris,

in die Richtung wie Gandalf würde ich auch denken. Hast Du evtl. STUN für die Kopplung aktiviert? Dann finden die Anlagen ggf. ihre öffentliche IP des DSL-Anschlusses heraus und lassen die Gegenstelle die RTP-Pakete dort hin schicken. Das geht dann am VPN-Tunnel vorbei - bzw. versucht daran vorbei zu gehen...

Gruß noDialPlan

 

[bospre]

Hallo Gandalf,
vielen dank für deine Antwort.
Das ist zumindest mal ein Hinweis in welche Richtung ich weiter suchen soll.
Leider weiss ich nicht wie ich den "Durchgang" der einzelnen Ports prüfen kann.
An den Routerkonfigurationen (PC's mit FLI4l als Linux-Betriebssystem und OPENVPN) wurde allerdings nichts geändert. Ausserdem rebooten diese täglich.
Ich werde aber mal mit einem VOIP-Telefon in beiden Netzen die jeweilige Erreichbarkeit der lokalen und der entfernten Anlage testen. Das bringt mich dann vielleicht einen Schritt weiter.
NAT-Transversal ist deaktiviert (bei SIP und RTP), Outbound-Proxy ist deaktiviert und so wie ich das verstehe ist auch STUN deaktiviert (die Einstellungsfelder sind ausgegraut).
Die Sache ist vermutlich auch noch komplizierter, da, wie ich gerade festgestellt habe, wenn man nur lange genug wartet, manchmal der Sprachkanal nach eine variablen Zeit (ca. 20-30 Sekunden) doch noch aufgebaut wird.

Falls es noch weitere Ideen gibt, bin ich dankbar.
Könnte es vielleicht ein Hardware-Defekt sein?

LG
Boris

 

[noDialPlan]

Die Sache ist vermutlich auch noch komplizierter, da, wie ich gerade festgestellt habe, wenn man nur lange genug wartet, manchmal der Sprachkanal nach eine variablen Zeit (ca. 20-30 Sekunden) doch noch aufgebaut wird.

In 9 von 10 Fällen die ich kenne, gehen solche von Dir beschriebenen Effekte auf einen IP-Adress-Konflikt im Netzwerk zurück. Geht manchmal - und dann doch nicht - oft aber doch und kam plötzlich, weil früher gings...
Einfach mal die Anlage aus dem Netz nehmen und die IP anpingen. Wenn dann jemand antwortet, ist der Fall klar.
Manchmal antwortet niemand und hat die IP trotzdem, dann lässt sich das über den ARP-Cache erkennen. Einfach einen PC in das Netzwerk vor Ort stecken, die verdächtige IP anpingen und anschließend "arp -a" in einem Konsolenfenster eintippen. Taucht dort unter der verdächtigen IP eine andere MAC-Adresse, als die der 5020 auf, dann ist das Problem klar...

Viel Erfolg!

 

[bospre]

Hallo noDialplan,
dein Tipp mit den IP-Adressen war Gold wert.
Ich habe mir zunächst die Rechnerlisten durchgesehen. Dabei fiel mir auf, dass in beiden Subnetzen ein VM-Ware Server läuft (das wusste ich natürlich schon, aber gerade bei den virtuellen PC's werden manchmal zusätzliche IP-Adressen belegt)
Daraufhin habe ich zunächst die IP-Adresse der einen TK-Anlage geändert und die Anlage und den Switch neu gebootet. Das brachte zunächst nichts.
Mit der anderen Anlage ist es schwieriger, da an dieser Anlage 7 Amtsleitungen mit rund 30 Nebenstellen dranhängen. Also habe ich die Anlage auf dem Switch in anderes VLAN gesetzt, mit Zugriff ausschliesslich auf den Router. Und siehe da, es funktionierte wieder. Allerdings läuft in diesem Subnetz ebenfalls ein Rechner mit VMware. Darauf wiederum läuft (u.a.) ein virtueller Rechner auf dem die LANTAPI installiert ist. Benutzt wird das ganze um Rufnummern- und Adressbuchanzeige auf den Arbeitsplatz PC's zu realisieren. Sobald ich das VLAN auf diesen Rechner erweitere wird kein Sprachkanal mehr aufgebaut. Wenn ich alle virtuellen PC's herunterfahre geht es wieder. Sobald aber ein virtueller PC läuft (es muss nicht der LANTAPI-PC sein) geht es nicht mehr.

Zunächst mal hat das ganze also nichts mit den TK-Anlage zu tun, sondern ist ein reines Netzwerkproblem. Auf die virtuellen PC'S kann ich nicht verzichten, hier muss ich mir jetzt eine Lösung ausdenken. IPCONFIG hat mir bis jetzt noch nicht weitergeholfen.
Das ist jetzt sicher auch nicht das richtige Forum um Netzwerkproblem zu lösen.
Aber vielleicht hat ja doch jemand eine Idee. Ich muss jetzt erst mal nachdenken.
Vielleicht kann ich auf dem Switch ein Routing über die MAC-Adressen einrichten (Ist ein Layer3 Switch, allerdings in Layer2-Betriebsart).
Trotzdem muss doch irgend etwas passiert sein, es hat mal funktioniert....

LG
Boris