Torsten.E

Im Augenblick kann ich nur sagen. Das "Test"-Telefon läuft derzeit bereits über 27 Stunden schon, das hatte ich bisher noch nicht. 2 DECT-Sender laufen ebenfalls bisher ohne Probleme. Ich gebe hier auf jeden Fall Bescheid, wie es weitergeht, bzw. das Ergebnis

bzw nur die "low" Einstellung, welche ich jetzt über den ASDM eingerichtet habe. Da wird dann nix geprüft.

# no inspect h323 h225 ERROR: Inspection not installed or parameters do not macht sieht so aus als ob gar keine Inspection eingerichtet ist

Ich will nicht widersprechen, weis es ja auch nicht 100%. G711 und G729 sind ja nur Codierungsverfahren für die Gesprächsübermittlung. Stimulus Protokoll für die Signalisierung zwischen System-Endgeräten und OpenCom 1000. Und hier ist eben nicht definiert, was genau "Stimulus" ist. Schaden kann Deine Einstellung aber auf keinen Fall ;-) Aber was bedeutet "no inspect" genau ? Ich hab mal im ASDM nachgesehen, da steht für die beiden Protokolle "Low". Ist dann "no inspect" dann noch weniger?

Aber H.323 wird doch überhaupt nicht verwendet. Ich meine, einstellen kann ich es schon. Was bewirkt ein "no inspect" ?

Was ich herausgefunden habe, ist, dass FIXUP jetzt INSPECT heist. Aber wenn ich es richtig verstanden habe, läuft bei mir KEIN SIP. Also SIP INSPECT ist es dann nicht. Die Aastra bzw. OpenCom1010 verwendet zwischen PBX und den IP-Endgeräten das sogenannte Stimulus-Protokoll.

Wo finde ich das genau "blacky" ?

Hi Blackblox, ich habe nachgefragt. Die Anlage verwendet G711 oder Komprimiert G729. Im Augenblick teste ich mit folgender Einstellung: policy-map global-class-IP-Telefone class global-class-IP-Telefone set connection timeout idle 0:00:00 set connection advanced-options tcp-state-bypass ! service-policy global-class-IP-Telefone global Da die Tests immer ziemlich viele Stunden in Anspruch nehmen kann ich bisher nur sagen, 7 Std. haben bisher schon geklappt. Torsten

Guten Morgen erst mal an alle. Hier ein Ausschnitt aus einem anderen Forum, welchen in gerade gefunden habe. Er beschreibt das Problem ganz genau. (weiter unten, gekürzt). Erklärung des Herstellers (sinngemäß) "...das Problem ist, dass nur die Cisco Router im VPN-Tunnel nochmals eine Firewall haben. Diese Firewall verwirft das 1. Datenpaket, welches aber für die IP-Telefonie benötigt wird. Anderen Router verwenden ..." Ich weis, ist ein wenig viel zu lesen, aber bevor sich jemand beschwert, ich würde das Problem nicht ausführlich beschreiben Gruss Torsten <----------------- Ich habe das gleiche Problem. Ich setzte seit Jahren bei meinen Kunden Router der Firma Bintec (jetzt Funkwerk) ein. Diese verbinden Standorte per VPN über IPsec. Die Tunnel laufen einwandfrei, keinerlei Programme (z.B. RDP) haben Probleme. Die IP-Systemtelefone OpenPhone 6x und 7x, sowie die Softphones haben alle während Gesprächen eine gute Sprachqualität und keinerlei Probleme, ausser.... Nach einer nicht genau definierbaren Zeit der "Nichtbenutzung", schlafen die Geräte ein. D.h., dass Telefon steht auf dem Tisch und erweckt den Anschein das alles OK ist, aber es kommen keine Rufe mehr an und wenn man selbst Telefonieren will passiert nichts. Manchmal bemerkt das Gerät dann seine "Nichtfunktion" und macht einen Neustart. In der Regel muss man diesen jedoch durch "Stromsteckerziehen" herbeiführen. An dieser Stelle die Bemerkung: Die DECT over IP Basis und auch die Aastra 5x SIP Telefone funktionieren einwandfrei und zwar zur selben Zeit, über den selben Tunnel!!?? Wenn Du jetzt sagst, dass es mit Zyxel <-> Zyxel auch nicht geht, dann kann ich Bintec wohl nicht mehr die Schuld geben und eher das Problem im DeTeWe Verbindungsprotokoll suchen. Der Gedankengang ist inzwischen soweit gereift, dass das Problem durch die in den Routern vorhandene SIF (StatefullInspectionFirewall) hervorgerufen wird. Laienhaft ausgedrückt würde ich annehmen, die SIF macht nach einer gewissen Zeit die Session/Port dicht und die Telefone versuchen nicht ernergisch genug die Anlage wieder zufinden. Was dann dazu führt, dass diese die Geräte als nicht verfügbar an sieht. ---- In diesem Forum wurde dann und wann von Reboots auf IP-Endgeräten in VPN-Netzwerken berichtet. Diese erfolgen immer nach dem gleichen Muster: nach einer gewissen Zeit der Inaktivität (keine Gespräche, kein LED-Zustandswechsel, kein Anruf) löst das Hörerabnehmen, ein Tastendruck oder ein eingehender Anruf einen Reboot auf ebendiesem IP-Endgerät aus. Beim OpenPhone 75IP wird beispielsweise auf dem Display angezeigt: IP PHONE terminated IP PHONE module load IP PHONE application start please wait starting protocol Danach ist das Endgerät wieder bereit. Ein allfälliger Anruf ist aber bereits verpasst; er ist aber in der Anrufliste protokolliert. Weil das Problem nur dann auftritt, wenn das Endgerät per VPN angeschlossen ist, fiel der Verdacht natürlich sofort auf die VPN-Router. Es zeigte sich, dass die Probleme mit Firewalls verschiedener Hersteller auftreten, aber nach unterschiedlichen Wartezeiten. Bei Firewalls vom Typ ZyXEL ZyWALL tritt das Problem alle 2.5 Stunden auf. Die Zeit von 9000 Sekunden entspricht dem Connection Tracker bzw. State Table Timeout für hängende Sessions. Der Workaround besteht darin, dass diese Zeit erhöht wird. Bei der aktuellen ZyXEL ZyWALL USG-Serie lässt sich der Wert bis auf 432000 Sekunden erhöhen, was fünf Tagen entspricht. Dadurch wird die Wahrscheinlichkeit eines Reboots praktisch auf 0 reduziert. Die beste Lösung wäre freilich, wenn Aastra ihr eigenes VoIP-Protokoll so anpassen könnte, dass es "firewallfreundlicher" wäre. Denn das beidseitige Deaktiveren aller Firewall-Funktionen, was einem zweiten funktionierenden Workaround bei ZyXEL ZyWALL-Geräten entspricht, kann ja keine praktikable Lösung sein.