Anrufe werden nach 200ACK vom Provider beendet

[Kai_Hawaii]

Moin Zusammen,
seit ca. 2 Wochen haben wir bei eingehenden Anrufen das Problem, dass der Provider, nach dem 200 OK (Gesprächsannahme vom Anrufer) nicht mit einem ACK reagiert.
Dies geschieht sporadisch und wenn der Anrufer mit einer Handynummer anruft.
Unser Provider ist Easybell.
Alle Nutzer nutzen die 3CX-App auf ihrem Handy oder haben die 3CX-Desktop-App installiert.
Zusätzlich haben wir unsere Warteschleife mit einem T46S (als Routertelefon) realisiert, welches hinter einer Sophos-Firewall sitzt und an einer DigiBox2 angeschlossen ist.
Die Cloud-PBX liegt auf einem Hetzner-Server.

In der 3CX:
- Erweitert - Netzwerk - ist die korrekte statische öffentliche IP-Adresse hinterlegt. Ebenfalls die Standart-IP-Adresse für das Standard-Gateway.
- Der Firewall-Check läuft ohne Störung durch.
- Ich habe keine IP-Beschränkungen und lasse den Zugriff von überall aus zu.

Wie kann ich weiter vorgehen. Was kann ich prüfen?

 

[bitn2]

Bitte erstmal sämtliche Infos ergänzen...

3cx Version, wie und wo installiert... Trunk Template, welches wurde genutzt.. Firewallcheck läuft durch?... Welche Firewall wird genutzt? Proxy Ausnahmen eingestellt? DNS Server, welchen nutzt die 3cx? usw usw

 

[Kai_Hawaii]

1. Version 20.0 Update 7 (Build 1080 Release)
2. Typ Enterprise Jahreslizenz
3. Trunk Anbieter: Easybell
3.1 Registrar: voip.easybell.de
3.2 Trunk ist registriert
3.3 G722 / PCMA / PCMU
4. PFSense und der Firewallcheck läuft erfolgreich durch, ohne Fehler
5. Self-Hosted auf einer VM von Hetzner / OS: Debian GNU/Linux 12 (bookworm)
6. Öffentliche Erreichbarkeit: IP
7. NetzwerkportsSIP:5060 SIPS:5061 Tunnel:5090 Media:9000-10999 HTTP:80 HTTPS:443
8. DNS: vom Betriebssystem übernommen, DNS-Server: 185.12.xx.xx

 

[bitn2]

Bitte mal prüfen ob in der 3cx IPv6 aktiv ist und das deaktivieren. Codec Reihenfolge PCMA an erste Stelle. Wenn das nicht reicht, die Firewall mal deaktivieren und testen.

 

[Kai_Hawaii]

IPv6 ist deaktiviert und die Codec-Reihenfolge habe ich angepasst und werde das heute beobachten lassen.

 

[bitn2]

Deaktiviere auch mal die Firewall davor, der Checker prüft nicht alles. Wird irgend ein proxy benutzt? Ausnahmen entsprechend eingerichtet?

 

[fxbastler]

PFSense und der Firewallcheck läuft erfolgreich durch, ohne Fehler

Die 3CX Anleitung zur grds. Einrichtung einer PfSense vor einer 3CX
https://www.3cx.de/docs/pfsense-firewall/
wurde genutzt?
Insbesonders die Punkte Outbound NAT und 'Firewall Optimization Options' / 'Conservative' wurden wie beschrieben umgesetzt?

 

[Kai_Hawaii]

@fxbastler
Wir konfigurieren heute Abend die „Firewall Optimization Options“. Diese haben wir nicht eingerichtet.

Wir nutzen ein 1:1 NAT

@bitn2
Es wird kein Proxy genutzt.

 

[fxbastler]

Wir nutzen ein 1:1 NAT

Grundsätzlich oder nur dort für ein spezielles Szenario? Ungeachtet dessen: so lange die source ports nicht umgeschrieben werden (siehe https://docs.netgate.com/pfsense/en/latest/nat/outbound.html#nat-staticport ) ist das in Ordnung. Der normale 3CX Firewall Check sollte das schon aufdecken wenn die umgeschrieben werden.

Wir konfigurieren heute Abend die „Firewall Optimization Options“. Diese haben wir nicht eingerichtet.

Das mit 'Firewall Optimization Options' / 'Conservative' kann man wohl auch anders lösen, indem die State Timeouts - hier insbes. UDP - entspr. angepasst werden. Bei Lancom haben wir das so machen müssen, bei PfSense stellen wir halt auf Conservative.
Wir haben seit unseren ersten eigenen produktiven 3CX v15 (und div. fremden v14 und v12 davor) damit nie Probleme - bis auf letzte Woche (das erste Mal überhaupt). Wir verwalten grds. bei unseren Kunden alles - bis glaub auf drei Spezialfälle. Einer davon hatte zeitweilig einen schlauen IT Admin, der vor geraumer Zeit an der Firewall maßgeblich Änderungen vorgenommen hat um alles zu verbessern. Wir haben die PfSense als v16 vor Jahren mit den üblich notwendigen Parametern in Betrieb genommen. Dann hat 'irgendwann' 'irgendjemand' die PfSense beim Kunden (die entspr. Liste ist halt sehr kurz) wieder auf normal gestellt. Das lief erstaunlich lange gut. Aber seit einigen wenigen Wochen fällt dem Kunden das richtig auf die Füße. Regelmäßig 'schläft' die 3CX ein: keine eingehenden Anrufe u.a. Abnormitäten. Zurückgestellt: geht sofort. Jetzt suchen wir in den Backups rückwärts wann das war, das wer ist unstrittig.

 

[Kai_Hawaii]

Wir haben die Firewall grundsätzlich für alle Kunden so eingestellt und bisher haben wir nur bei unserer Anlage diesen Fehler.
Auch die Anpassungen an der Firewall haben keine Verbesserung gebracht.

Was mir die Kollegin mitgeteilt hat: Sie hat diese Abbrüche bisher nur mit ihrem Apple iPhone.

 

[fxbastler]

Um es zusammenzufassen: es betrifft nur eine 3CX Anlage und auch dort nur einen Nutzer mit nur einem Mobiltelefon (iOS) mit der Smartphone App - richtig?

 

[Kai_Hawaii]

Korrekt.
Ein Nutzer mit der (iOS) Smartphone App hat dieses Problem. Heute gab es bei eingehenden Anrufen, über die PWA App, keinen Abbruch.

Als kleine Zusatzinfo:
Ich habe einige Kunden kontaktiert und diese teilten mir mit, dass keinerlei Abbrüche bei eingehenden Anrufen auftreten.

 

[fxbastler]

Korrekt.

Gegenüber der urspr. Beschreibung und Aufgabe läuft das jetzt gerade einmal in eine ganz andere Richtung.

Sofern das tlw. reproduzierbar ist würde ich eine pragmatische Herangehensweise testen, z.B.:
Tritt das Problem auch auf, wenn man auf dem derzeitigen Smartphone der Nutzerin die 3CX App entfernt und ihr zeitweilig und leihweise ein anderes Endgerät (notfalls auch ein anderes Smartphone mit 3CX Smartphone App und das nur für die 3CX Telefonie) zur Verfügung stellt?

 

[Kai_Hawaii]

Vielleicht habe ich mich falsch ausgedrückt.

• Es betrifft wirklich nur unsere 3CX Anlage
• Ursprünglich: Sporadisch bei mehr als 4 Nutzern und nur bei eingehenden Anrufen, egal ob über iOS oder Desktop-App.
• Aktuell: Eine Nutzerin hat bis heute morgen nur die iOS Smartphone App genutzt und hat die Abbrüche gehabt .
  Diese Nutzerin hat seit heute morgen 7 Uhr, nach meiner Aufforderung, die PWA-App genutzt und keinen Abbruch gehabt -> korrekt. Daher könnte man evtl auf das Endgerät schließen.

Aber:

• 1 Nutzer hatte über den Tag verteilt vereinezelte Abbrüche (bei eingehenden Anrufen). Dieser hat bis heute die Edge Erweiterung genutzt. Ab morgen werden die Telefonate über die Desktop-App geführt.
• 2 Nutzer waren krank und ich habe von denen keine Rückmeldung erhalten.
• Ich zum Beispiel nehme die Telefonate über die iOS Smartphone App entgegen und habe keine Abbrüche.

 

[fxbastler]

Ich sag's gleich: das wird jetzt etwas zur Suche nach der Nadel im Heuhaufen.

Es betrifft wirklich nur unsere 3CX Anlage

Dann ist es ein Problem bei euch, eher nicht 3CX. Wahrscheinlichkeit: sehr hoch

Ursprünglich: Sporadisch bei mehr als 4 Nutzern und nur bei eingehenden Anrufen, egal ob über iOS oder Desktop-App.

Sind wenigstens die Desktop App Endgeräte per LAN angebunden?

Gibt es mehrere genutzte Internetzugänge oder Gateways (VPN) am Standort?
Gibt es Traffic Management, ist der Traffic Shaper o.ä. auf der PfSense aktiviert?
...

 

[Kai_Hawaii]

Die Endgeräte sind bei uns alle via LAN angeschlossen.

In der Firma gibt es einen Internetzugang mit LTE Fallback.

In der pfSense ist der Traffic Shaper nicht aktiv.

Bei der Kollegin mit dem Handy wird sie morgen weiterhin über die Desktop App die Gespräche annehmen.

 

[fxbastler]

Es ist und bleibt euer Problem, ein Problem in eurem Netzwerk. Darüber können wir jetzt noch wochenlang philosophieren. Das dürft ihr selber klären. Keiner hier wird sich mit solch einem indifferenten Problem in eurem Netzwerk beschäftigen wollen.

Sonst zeige hier bitte ausführlich, dass das Problem in der 3CX auftritt - am besten reproduzierbar.

Das Mini Fenster mit einem Bruchteil eines Paketmitschnitt sagt keinem hier etwas, außer dass es rote Zeilen gibt - ohne Anfang, ohne Mitte, ohne Ende. Noch dazu unter Einbeziehung des SBC - warum auch immer das so sein soll.

Es ist wie immer: deduktive Herangehensweise an das Problem.

 

[Kai_Hawaii]

Ist ja in Ordnung.
Wir haben bei uns definitiv etwas angepasst, das hat mir weitergeholfen.

Probleme in unserem Netzwerk sind eben unsere Probleme, korrekt.

Danke für die Unterstützung.