APN teilweise >20s später

nick81

Premier Customer
Advanced Certified
Mitglied seit
3. Mai 2024
Beiträge
29
Hi zusammen,

irgendwie signalisiert die 3CX App auf den iPhones teils recht spät. Laut pcap-Log scheint der Request an die api.push.apple.com manchmal sofort raus zu gehen und manchmal dauert es viele Sekunden (In meinem Beispiel-Log ca. 22 Sekunden). Bis dahin ist die Mailbox schon dran gegangen und die App klingelt dann noch. Zwischen meinen Tests mit/ohne Probleme liegen oft nur Minuten.

Selbst gehostet bei Hetzner (mit Floating-IP)
DNS ist 8.8.8.8 8.8.4.4
3CX Version 20.0 Update 2 (Build 715)


1725015331584.png
1725015373364.png
 
Fragen dazu:
  1. Welcher Hetzner Standort?
  2. Kombifrage: Hat die 3CX zwei IPv4 / Was ist mit der primären IPv4 / Warum wird eine floating IP stattdessen verwendet?
 
Der Standort ist Nürnberg
Die src-IPv4 Adresse ist die Floating-IP, es existiert aber noch eine andere IP. Floating IP ist für "schnelle Problemlösung, falls man einen neuen Server aufsetzen muss und man nicht auf eine DNS Änderung warten möchte".
 
Die src-IPv4 Adresse ist die Floating-IP, es existiert aber noch eine andere IP.
Die 3CX hat nur diese eine (floating) IP?
Der Standort ist Nürnberg
Damit hatten wir und soweit ich weiss andere schon gewisse Probleme. Ich will deswegen nicht rumningeln, aber ist es für dich möglich, das mit einem in FSN1 zu testen?

Auf was für einem Produkt von Hetzner läuft denn die 3CX?

Wenn die 3CX ein virtualisiertes Debian ist - wurde ntp installiert?

Grundsätzlich zur Klärung: Wir haben solche Push Probleme wg. Verzögerung nirgends.
 
  • Like
Reaktionen: nick81
Hi noch mal.
Es ist ein cx42 (80 Nebenstellen). Der Server hat eine eigene IP und zusätzlich eine Floating-IP. Auf der Floating-IP ist die 3CX-Domain aktiv (inkl. reverse-DNS Eintrag) und wird auch als source-IP für ausgehende Anfragen genutzt (sieht man auch im pcap).
Ich habe das 3CX V20 Image genutzt, was Hetzner in seiner ISO-Bibliothek anbietet. Ist Debian und scheint das Standard-3CX Image zu sein.
Es wird ein aktiver NTP-Server benötigt? Muss der nachinstalliert werden oder ist der im 3CX Image bereits vorhanden? Die Zeit auf dem Server geht aktuell richtig.

Ich kann den Server nach FSN1 migrieren und dort testen, klar. Noch läuft die Anlage nicht aktiv, soll im September/Oktober live gehen. Wird aber erst nächste Woche etwas, es sei denn, wir finden den Fehler noch vorher

Übrigens: Hut ab, schnelle Reaktion hier, danke
 
  • Like
Reaktionen: nick81
NTP habe ich installiert und ipv6 komplett abgeschaltet.
Code:
ip a
zeigt beide interfaces mit unterschiedlichen IPs an.

Meine ersten Testanrufe gingen schnell durch, egal ob 3CX App geschlossen ist oder nicht. Mal sehen ob das gereicht hat. Ich werde das die nächsten Tage testen und mich melden. Es hatte ja bislang auch immer nur sporadisch aber häufig nicht funktioniert.

Danke dir für den super Support :)
 
  • Like
Reaktionen: nick81 und mbehrens
Der Artikel bezieht sich auf Hyper-V.
egal, das gilt immer
Frage nur damit ich es verstehe
Jetzt kommt die Wand.

Jede VM, insbes. zeitkritische, sollte ihre Zeit selber komplett kontrollieren. Wenn man kann, dann die Zeitgebung durch den HV Host komplett deaktivieren. Der übertüncht sonst die virtuelle Uhr / Taktgeber des virt. Computer und das sehr unregelmäßig. Ein eigener NTP (nur für die Maschine, der muss seine Daten nicht weiter verbreiten) macht das bestens, chrony funktioniert anders, tut es prinzipiell auch, wir bevorzugen dennoch ersteres. Daher sollten virtualisierte DC auch keine Zeit des HV Host bekommen sondern eine eigene bilden oder anderswo ableiten und alles bezieht sich darauf. Bei uns sind es i.d.R. die Firewall, die als Zeitnormal im Netzwerk dienen, egal ob per eigener Hardware (die driftet), ntp mit Internet Synchronisation oder USB GNSS Empfänger der gut platziert ist und aus mehreren Quellen das Mittel zieht.

Der Hintergrund ist auf Grund der PC Hardware teils technisch und historisch bedingt und gewachsen und wird noch verschärft durch neue Technik (kein steter Takt, dyn. Übertaktung, Wechsel des Kerns durch parallelisierende Prozesse u.a.) und Virtualisierung. Der originale Takt kam mit dem Ur PC, war recht grob und daher auch leicht ungenau, der präzise Takt kam erst viel später hinzu. Dennoch hoppeln diese Zeitgeber alle mehr oder weniger stark, auch heute noch. Daraus ergeben sich verschiedenste Probleme bei der Echtzeitkommunikation. Ntp leitet seinen eigenen Takt von einer Zentrale ab, leitet den selber, ermittelt Drift, und Korrektur und hat daher ein beständiges gleitendes stetiges Mittel. Der Takt der (womöglich virtuellen) Taktgeber ist das viel zu ungenau und wie gesagt: er hoppelt noch mehr. Das alles merkt man selbst bei hochpräzisen Messungen auf nackter Hardware und auch heute noch, auch wenn die CPU GHz bietet und nichts läuft. Nicht umsonst gibt es Firmen die permanent hochpräzise Zeitgeber in Hardware (nicht nur wegen der langfristigen, offline verfügbaren und sonst manipulierbaren sondern auch wg. der kurzfr. Abweichung) bauen und verkaufen, inkl. Software, Service und Kalibrierung - das wäre sonst obsolet. Man bekommt halt nicht überall DCF77 oder GNSS oder wie früher analoges terr. ZDF Fernsehen mit atomzeigenauer Austastung, zumal das alles jammed werden kann. Bei einer Computer Telefonanlage merkt man das am ehesten mit am Fax: es stirbt eher da keine zeitl. Korrektur. Bei der Telefonie steigt grundsätzlich die Qualität wenn man sich nicht auf die Hardware verlässt sondern das per o.g. Software nachjustieren und nur leicht gleiten statt hoppeln lässt. Es werden weniger RTP Pakete wegen Ungültigkeit der falschen Zeitstempel der Reihenfolge verworfen.

Um zum Thema zurück zu kommen: Zeit ist lt. seinem bisher letzten Post beim TO wohl nicht das Problem. Aber man sollte es dennoch umsetzen.
 
Die nicht benötigte komplett im System entfernen. Es kann nur eine(n) geben ...
Ich hatte noch überlegt über diese zweite "richtige" IP des Servers zukünftig einen 3CX Cluster aufzubauen. Aber das Thema hatte ich mir noch nicht im Detail angesehen.

Ich hatte gestern und heute noch mehrfach versucht das Gerät über die iPhone App zu erreichen, bislang gab es keinen Zeitverzug mehr. Ich gehe davon aus, dass das Problem gelöst wurde. Ob es jetzt an dem NTP oder an der IPv6 Adresse lag, keine Ahnung.

Vielen Dank noch mal für deine Hilfe.
 
egal, das gilt immer

Jetzt kommt die Wand.

Jede VM, insbes. zeitkritische, sollte ihre Zeit selber komplett kontrollieren. Wenn man kann, dann die Zeitgebung durch den HV Host komplett deaktivieren. Der übertüncht sonst die virtuelle Uhr / Taktgeber des virt. Computer und das sehr unregelmäßig. Ein eigener NTP (nur für die Maschine, der muss seine Daten nicht weiter verbreiten) macht das bestens, chrony funktioniert anders, tut es prinzipiell auch, wir bevorzugen dennoch ersteres. Daher sollten virtualisierte DC auch keine Zeit des HV Host bekommen sondern eine eigene bilden oder anderswo ableiten und alles bezieht sich darauf. Bei uns sind es i.d.R. die Firewall, die als Zeitnormal im Netzwerk dienen, egal ob per eigener Hardware (die driftet), ntp mit Internet Synchronisation oder USB GNSS Empfänger der gut platziert ist und aus mehreren Quellen das Mittel zieht.

Der Hintergrund ist auf Grund der PC Hardware teils technisch und historisch bedingt und gewachsen und wird noch verschärft durch neue Technik (kein steter Takt, dyn. Übertaktung, Wechsel des Kerns durch parallelisierende Prozesse u.a.) und Virtualisierung. Der originale Takt kam mit dem Ur PC, war recht grob und daher auch leicht ungenau, der präzise Takt kam erst viel später hinzu. Dennoch hoppeln diese Zeitgeber alle mehr oder weniger stark, auch heute noch. Daraus ergeben sich verschiedenste Probleme bei der Echtzeitkommunikation. Ntp leitet seinen eigenen Takt von einer Zentrale ab, leitet den selber, ermittelt Drift, und Korrektur und hat daher ein beständiges gleitendes stetiges Mittel. Der Takt der (womöglich virtuellen) Taktgeber ist das viel zu ungenau und wie gesagt: er hoppelt noch mehr. Das alles merkt man selbst bei hochpräzisen Messungen auf nackter Hardware und auch heute noch, auch wenn die CPU GHz bietet und nichts läuft. Nicht umsonst gibt es Firmen die permanent hochpräzise Zeitgeber in Hardware (nicht nur wegen der langfristigen, offline verfügbaren und sonst manipulierbaren sondern auch wg. der kurzfr. Abweichung) bauen und verkaufen, inkl. Software, Service und Kalibrierung - das wäre sonst obsolet. Man bekommt halt nicht überall DCF77 oder GNSS oder wie früher analoges terr. ZDF Fernsehen mit atomzeigenauer Austastung, zumal das alles jammed werden kann. Bei einer Computer Telefonanlage merkt man das am ehesten mit am Fax: es stirbt eher da keine zeitl. Korrektur. Bei der Telefonie steigt grundsätzlich die Qualität wenn man sich nicht auf die Hardware verlässt sondern das per o.g. Software nachjustieren und nur leicht gleiten statt hoppeln lässt. Es werden weniger RTP Pakete wegen Ungültigkeit der falschen Zeitstempel der Reihenfolge verworfen.

Um zum Thema zurück zu kommen: Zeit ist lt. seinem bisher letzten Post beim TO wohl nicht das Problem. Aber man sollte es dennoch umsetzen.
Danke für die kurze und knappe Erklärung!
 
  • Haha
Reaktionen: bitn2 und fxbastler

Statistik des Forums

Themen
44.752
Beiträge
233.659
Mitglieder
78.496
Neuestes Mitglied
FS-CG