Freepbx13, Anrufe werden stark verzögert registriert

[nixnuzz]

Guten Tag,


bei mir arbeitet FreePBX 13.0.105 auf einem virtuellen Server unter VMWare. Endgeräte im LAN sind zwei Cisco IP Telefone sowie ein X-Lite Softphone auf einem PC.
Es gibt zwei abgehende Verbindungen zu Telekom und Sipgate basic.
Mein Problem ist, dass die Reaktionsgeschwindigkeit des Konstrukts zu wünschen übrig lässt.
Innerhalb des LAN benötigt der Rufaufbau etwa 10 Sekunden von einem Teilnehmer zum Anderen.
Völlig unbefriedigend ist jedoch der Rufaufbau von aussen zu einem der Endgeräte. Erst nach 20 bis 30 Sekunden wird der ankommende Ruf von freepbx registriert, dann nochmal mehrere Sekunden bis das Endgerät klingelt.
Gibt es irgendwelche Timer oder Keepalives die ich übersehen habe? Ich glaube nicht, dass es am Netzaufbau oder einem Performanceproblem liegt.
Im Router habe Port 5060 habe ich sowohl TCP als auch UDP zu Freepbx genattet.
Grundsätzlich bin ich schon fit bezüglich Netzwerkkram, nur VoIP ist gar nicht so meine Domäne.

/nn


Das Konstrukt:
VMWare ESXI6 mit Dual Xeon und 36GB RAM
Freepbx 13 als virtuelle Maschine mit 4GB RAM und 4CPUs
im LAN ist ein Cisco Catalyst mit Gigabit Ethernet, der Server hängt über einen PortChannel mit 2Gbit/s am dem Switch
Internet über T-online, Zugang mit einem Cisco 2621XM, IPv4 und v6 als dualstack, von dort pppoe-passtrough durch einen Bintec RS232j auf einen 16Mbit/s Anschluss der Telekom.

 

[rentier-s]

Ich glaube nicht, dass es am Netzaufbau oder einem Performanceproblem liegt.

Gerade das wäre jetzt meine erste Vermutung gewesen. Mach auf der Konsole asterisk -rvvv, da kannst Du in Echtzeit zuschauen, was wann abgearbeitet wird. Wenn es vom wählen bis zur ersten Reaktion wirklich so lange dauert, gehen Dir wohl massenhaft SIP Pakete verloren. Dann evtl mit sip set debug on das SIP Debugging einschalten, da kommt dann verdammt viel Text. Wenn darunter vermehrt Pakete mit Re-Transmit sind, hast Du ein Netzwerkproblem.

 

[nixnuzz]

den Debugger auf der Konsole habe ich angeworfen, auch dort wird so stark verzögert angezeigt.
Der nächste Schritt war, auf dem Portchannel zwischen Server und Switch einen Kanal zu deaktivieren und nur mit 1xGigabitEthernet zu arbeiten. Ohne Erfolg.
Dann habe ich der virtuellen Maschine ein eigenes Netzwerkinterface auf dem Server zugewiesen, ganz exklusiv. Kein Unterschied.
Zu guter Letzt habe ich auf dem Switch einen Spiegelport eingerichtet, auf dem der Datenverkehr zu einem anderen Server geleitet wird, auf dem Wireshark läuft. Alles toll, keine retransmissions, Eingaben von den Telefonen werden sofort registriert. Blöderweise reicht mein Protokollverständnis bei VoIP noch nicht soweit, dass ich die Details verstehe.
Ich bastel jetzt erstmal einen neuen virtuellen Server mit Version 11. Wenn das auch nichts bringt, dann bekommt freepbx komplett eigene Hardware.
Danke erstmal
/nn

 

[nixnuzz]

bevor irgendwer - wenn auch höchst unwahrscheinlich - auf das gleiche Problem trifft und sich fragt, was daraus geworden ist: hier die Antwort.
Ich habe keine Ursache gefunden, allerdings in einem komplett neu aufgesetzten Konstrukt eine hervorragend laufende freepbx.
Vermutlich wird das sonst im privaten Umfeld mangels vorhandener Hardware niemand aufbauen.
Freepbx ist bei mir als virtuelle Machine unter VMware ESXI6 mit 4GB RAM, 16GB Harddisk und 8 Prozessorkernen installiert. Basis ist ein HP Server DL380G6.
Der Freepbx Basisinstallation wurden DHCP und DNS Server hinzugefügt (für das VoIP-VLAN 110) sowie Webmin als Administrations-GUI.
Warum VMware als Unterbau? Man kann äußerst komfortabel Snapshots anlegen und damit vor Umkonfigurationen oder Softwareupdates den aktuellen Stand sichern. Desweiteren ist der Server potent genug, noch andere Systeme abzubilden.
Die virtuelle Maschine ist an drei virtuellen Switches des VMware Hosts angebunden für das normale Datennetz (VLAN100), ein reines Voice Netz (VLAN110) und die DMZ (VLAN300). Real sind es zwei GE-Netzwerkinterfaces als Port-Channel zu einem Cisco Catalyst Switch. Als Telefone kommen mehrere Cisco 9951 zum Einsatz sowie ein 7961G. Die Konfiguration wurde mit dem OSS Endpoint Manager für freepbx erstellt. Es waren Anpassungen in den angebotenen Konfigurationen notwendig. Der Wechsel von SCCP- auf SIP-Firmware in den Telefonen erfolgte bereits früher.
Im normalen Netz (VLAN 100) sind noch ein X-Lite Softwaretelephon am sowie mehrere Smartphones mit Zoiper übers WLAN integriert.
Die Cisco Telefone beziehen ihren Saft mit PoE, die älteren PoE Switche von Cisco, wie z.B. Catalyst3560, können die 9951er Telefone nicht versorgen. Mein PoE-Switch ist ein 3750-24P.
Späteres Ziel ist noch, die Smartphones via VPN auch über mobiles Internet an die pbx anzubinden.
/nn