[Problem] Verbindungsabbrüche 5020 VoIP mit COMfortel 1400 IP

meron90

Neuer User
Mitglied seit
22 Dez 2021
Beiträge
3
Punkte für Reaktionen
0
Punkte
1
Liebes Forum,

ich bin recht ratlos und hoffe nun auf diesem Wege Hilfe zu finden. Ich habe eine Auerswald COMpact 5020 VoIP mit 8 VoIP-Kanälen im Einsatz. Die Anlage hängt an einer FritzBox 7490. Die FritzBox ist via festen VPN-Tunnel mit weiteren FritzBoxen verbunden. Am Hauptstandort haben ich mehrere Comfortel 1400IP im Einsatz. An einem der Nebenstandorte ist auch ein 2600 IP angeschlossen. Das via Fritz-VPN-Tunnel angeschlossene 2600 IP Telefon funktioniert super und so wie ich mir das vorstelle. Sowohl bei den 'lokalen' als auch bei den entfernten 1400IP bricht jedoch die Verbindung regelmäßig zusammen. Meistens etwa nach 10 Minuten, manchmal bei knapp 30 Minuten, seltener nach längerer Zeit.

Das Telefon zeigt 'Fehler 500', beim Partner wird 'Teilnehmer hat aufgelegt' angezeigt.

Es kann kein Fehler des Telefon-Anbieters sein, weil das Problem auch bei internen, lokalen Gesprächen auftritt. Genügend VoIP-Kanäle stehen zur Verfügung; (4 intern, 4 extern).

Ich habe die Einstellungen des SIP-Session-Timers verändert und ihn ausgeschaltet. Keine Veränderung. Außerdem habe ich probiert, die Einstellungen des 2600 IP 1zu1 für die 1400 IP zu übernehmen; bis auf den jeweiligen Benutzer sind die Telefone gleich eingestellt. 2600 IP super, 1400 IP nicht zu verwenden.

Bevor ich die 1400 IP im Einsatz hatte, habe ich die einzelnen Teilnehmer als eigene Rufnummern in den FritzBoxen angelegt und so verschiedene Fritz Fon C5 in die Anlage eingebunden. Auch das hat ohne Abbrüche funktioniert, ließ aber die Vorteile der Telefonanlage nicht so recht zur Geltung kommen.

Da alles andere super funktioniert, gehe ich davon aus, dass das Problem irgendwo zwischen 5020 VoIP und Comfortel 1400 IP liegt, weiß aber nicht weiter.
Hat jemand eine Idee?
Lasst mich gerne wissen, wenn ihr andere Informationen braucht. Die ganze Thematik ist für mich eher eine Fremdsprache, entschuldigt also außerdem etwaige 'Grammtikfehler'.

Ich freue mich von Euch zu lesen, liebe Grüße und vielen Dank
Tobias

edit: ich habe ein 1400IP in der Anlage, das scheinbar problemlos funktioniert. Was das 2600IP und das 1400IP, das funktioniert gemein haben, ist der Standard-Account. In die Anlage sind zwei VoIP Anbieter eingebunden. Bisher ging ich davon aus, dass es nicht an den VoIP-Anbieter-Einstellungen liegen kann, weil das Problem auch in internen Gesprächen auftaucht. Liege ich hier vielleicht falsch? Kann eine Anbieter-Einstellung (z.B. Outbound-Proxy) auch Auswirkungen auf interner Gespräche haben? Vielen Dank für Eure Einschätzungen und die Hilfe bei der Fehlersuche
 
Zuletzt bearbeitet:

4Halix

Neuer User
Mitglied seit
26 Apr 2021
Beiträge
27
Punkte für Reaktionen
5
Punkte
3
Ich schätze, dass es keine Auswirkung haben dürfte, was in den externen Accounts steht.

Aber was du mal probieren kannst, ist bei den Telefonen in den Einstellungen zur Anlage im Bereich SIP von UDP auf TCP wechseln. Wirkt, gerade bei diversen VPN wahre Wunder :)
 

meron90

Neuer User
Mitglied seit
22 Dez 2021
Beiträge
3
Punkte für Reaktionen
0
Punkte
1
Hey, vielen Dank für die Antwort! Ich hoffe, ihr hattet schöne Weihnachtstage! Kann man sagen, dass TCP insgesamt das stabilere Protokoll ist? Das 2600 IP läuft über TCP, das funktionierende 1400 IP über UDP; die Problem 1400IP auch auf TCP. Oder kann es auch ein Problem sein, dass die unterschiedlichen Telefone in der Anlage verschiedene Protokolle verwenden? Am besten alles auf TCP wechseln?
Vielen Dank für Eure Einschätzung! :)
Ich habe irgendwo hier im Forum einen Post gelesen, wo empfohlen wurde, die IP-Adressen der Teilnehmer in der IP-Freigabeliste anzugeben. Den Gedanken, dass die Anlage dicht macht, sobald zu viel Trafic über den Teilnehmer kommt, hatte ich auch schon. Aber bei Blick in die IP-Sperrliste erblicke ich nichts als leere. Ich hätte vermutet, dass hier IP-Adressen auftauchen, die die Anlage blockiert und ich sie dann(!) über die Whitelist wieder freigebe? Auch da bin ich gespannt auf Eure Einschätzung! Liebe Grüße
 

4Halix

Neuer User
Mitglied seit
26 Apr 2021
Beiträge
27
Punkte für Reaktionen
5
Punkte
3
UDP ist etwas performanter. TCP läuft meiner Erfahrung nach aber insbesondere im VPN besser. Sowohl bei ipsec als auch oVPN. Allerdings ist es nicht in jedem Szenario notwendig, ganz dahinter bin ich noch nicht gestiegen.

Ein Mischbetrieb sollte kein Problem sein. Schade, dass ausgerechnet die Problemtelefone schon auf TCP stehen.

Könnten es an den "Firewalls" dazwischen liegen? Die halten manchmal die Datenströme nicht lange genug offen. Da arbeitet man seitens der Geräte dann mit engmaschigen Keepalive Pings. Zusätzlich kann man bei Fritzen im Telefonie Bereich irgendwo sagen, dass auch sie länger warten (da waren Werte mit zum Beispiel 5 Minuten zu finden). Seltsam wäre auch hier, warum das beim 2600 nicht passiert.
 

meron90

Neuer User
Mitglied seit
22 Dez 2021
Beiträge
3
Punkte für Reaktionen
0
Punkte
1
Liebe(r) 4Halix, liebes Forum,

wie so oft, sitzt der Fehler eher vor der Tastatur als in der Technik...

Ich glaube, ich habe das Problem gefunden. Wie erwähnt, habe ich zunächst die Teilnehmer als Rufnummern in der FritzBox angelegt, bevor ich auf die 1400 IP umgestiegen bin. Scheinbar habe ich im Eifer des Gefechts die Rufnummern nicht aus der FritzBox gelöscht. Es waren also sowohl die Telefone, als auch die Rufnummern in der FritzBox als die gleichen Teilnehmer angelegt. Ich vermute, dass nun die FritzBox im regelmäßigen Abstand einen Ping an die Telefonanlage geschickt hat (NAT Keepalive?), der dann das ganze System ins Chaos stürzte.
Doof, aber irgendwie logisch.

Vielleicht hilft die Beschreibung ja irgendwem, der genauso auf dem Schlauch steht.

Vielen Dank für die Tips, 4Halix!
Liebe Grüße und schönen Abend!
 
Erhalten Sie 3CX für 1 Jahr kostenlos!

Gehostet, in Ihrer privaten Cloud oder on-Premise! Ganz ohne Haken. Geben Sie Ihren Namen und Ihre E-Mail an und los geht´s:

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.
oder via