3CX Phone System Deep-Dive
3CX ist eine softwarebasierte IP-Telefonanlage, die als Linux-Appliance oder in Docker-Containern betrieben wird. Sie bietet eine vollständige Unified-Communications-Plattform — von klassischer Telefonie über Video-Conferencing bis hin zu Live-Chat-Integration. Im Enterprise-Umfeld überzeugt 3CX durch die nahtlose Provisionierung hunderter Endgeräte und die zentrale Verwaltung mehrerer Standorte über ein einziges Management-Interface.
- Installation & Deployment: Die Bereitstellung erfolgt auf Debian 12 via
wget -O- https://downloads.3cx.com/downloads/debian12install.sh | bash. Für Hochverfügbarkeit empfehlen wir die Docker-basierte Installation mitdocker compose, wobei Volumes für/var/lib/3cxpbxund/var/lib/postgresqlpersistent gemappt werden. Die initiale Konfiguration erfolgt über den Web-Wizard auf Port 5015 (HTTPS). - Session Border Controller (SBC): Der 3CX SBC fungiert als Tunnel-Gateway für Remote-Standorte und überwindet NAT/Firewall-Beschränkungen. Die Installation auf einem Raspberry Pi oder einer VM erfordert lediglich
apt install 3cxsbcund die Eingabe des Provisioning-URLs. Der SBC baut einen verschlüsselten Tunnel (Port 5090/TCP) zur Zentrale auf und routet SIP/RTP transparent. - Provisionierung: 3CX unterstützt Zero-Touch-Provisioning für Yealink, Fanvil, Grandstream und Snom. Telefone werden über DHCP Option 66 oder RPS (Redirect & Provisioning Service) automatisch konfiguriert. Die Provisionierungs-URL folgt dem Schema
https://pbx.domain.tld:5001/provisioning/{mac}.cfg, wobei Templates pro Modellreihe anpassbar sind. - Backup & Restore: Automatisierte Backups werden über die 3CX Management Console konfiguriert — empfohlen ist ein täglicher Schedule mit Rotation über 14 Tage. Das Backup umfasst die PostgreSQL-Datenbank, Voicemail-Dateien, Aufzeichnungen und die System-Konfiguration. Restore erfolgt über
3CXPhoneSystem --restore /path/to/backup.zip.
SIP Trunking & Trunk-Konfiguration
SIP Trunking ersetzt herkömmliche ISDN-Anschlüsse durch IP-basierte Sprachverbindungen zum Provider. Die Konfiguration eines SIP-Trunks erfordert präzise Abstimmung von Authentifizierung, Codec-Negotiation und NAT-Traversal. Fehlerhafte Konfigurationen führen häufig zu One-Way-Audio, fehlenden DTMF-Tönen oder Registrierungsfehlern (SIP 401/407).
- Trunk-Setup: Die Registrierung erfolgt über SIP REGISTER mit Digest-Authentifizierung (RFC 3261). Typische Parameter umfassen: Registrar-Adresse, Outbound-Proxy, SIP-Benutzername (oft die Rufnummer), Passwort und Domain. Bei IP-Authentifizierung entfällt die Registrierung — stattdessen wird die öffentliche IP-Adresse beim Provider hinterlegt.
- Codec-Konfiguration: Die Codec-Priorität wird im SDP-Body des SIP INVITE ausgehandelt. Für LAN-Verbindungen empfehlen wir G.722 (HD-Voice, 64 kbit/s) oder Opus (6–510 kbit/s variabel). Für WAN-Strecken mit begrenzter Bandbreite ist G.729 (8 kbit/s) optimal, erfordert aber Lizenzierung. Die Konfiguration in der
pjsip.conf(Asterisk) lautet:allow=!all,g722,alaw,ulaw. - NAT-Traversal: SIP-Pakete enthalten im Contact-Header und SDP oft private IP-Adressen, was hinter NAT zu Routing-Problemen führt. Lösungen umfassen STUN-Server (
stun:stun.l.google.com:19302), dierport-Erweiterung (RFC 3581) und dieforce_rport-Option. Bei symmetrischem NAT ist ein TURN-Server oder SBC zwingend erforderlich. - Failover-Trunk: Zur Absicherung gegen Provider-Ausfälle konfigurieren wir einen sekundären SIP-Trunk mit geringerer Priorität. Die Umschaltung erfolgt automatisch über SIP-Response-Code-Auswertung (503 Service Unavailable, 408 Request Timeout). In 3CX wird dies über die Gateway-Priorität in den Outbound Rules gesteuert.
Microsoft Teams Telefonie
Microsoft Teams Phone System ermöglicht die vollständige Integration von PSTN-Telefonie in die Teams-Plattform. Unternehmen können zwischen Microsoft Calling Plans, Operator Connect und Direct Routing wählen. Direct Routing bietet maximale Flexibilität, da bestehende SIP-Trunk-Verträge weitergenutzt und komplexe Rufnummernpläne abgebildet werden können.
- Direct Routing: Die Anbindung erfolgt über einen zertifizierten SBC (z. B. AudioCodes Mediant 800), der als Vermittler zwischen dem SIP-Trunk des Carriers und Microsoft 365 fungiert. Die Konfiguration erfordert ein öffentliches TLS-Zertifikat (DigiCert/GlobalSign), DNS-SRV-Records für
_sips._tcp.domain.tldund die Freischaltung der Microsoft-Signaling-IPs (52.112.0.0/14) auf Port 5061. Die PowerShell-Konfiguration lautet:New-CsOnlinePSTNGateway -Fqdn sbc.domain.tld -SipSignalingPort 5061 -Enabled $true. - Operator Connect: Als vereinfachte Alternative zu Direct Routing bietet Operator Connect eine vom Carrier verwaltete SBC-Infrastruktur. Die Aktivierung erfolgt direkt im Teams Admin Center unter „Voice > Operator Connect“. Vorteil: kein eigener SBC-Betrieb, Nachteil: eingeschränkte Anpassungsmöglichkeiten bei komplexen Szenarien wie Multi-Site-Routing oder Analog-Geräte-Anbindung.
- Voice Routing Policies: Die Zuordnung von Rufnummern und Routingregeln erfolgt über Teams Voice Routing Policies. Jede Policy enthält PSTN-Usages und Voice Routes mit Regex-Patterns für Rufnummern-Matching. Beispiel:
New-CsOnlineVoiceRoute -Name "DE-National" -NumberPattern "^\+49(\d{10})$" -OnlinePstnGatewayList sbc.domain.tld -Priority 1. - Compliance Recording: Für regulierte Branchen (Finanz, Gesundheit) wird Teams Compliance Recording über zertifizierte Partner (NICE, Verint, ASC) eingerichtet. Die Aufzeichnung erfolgt policy-basiert und erfasst Audio, Video und Screen-Sharing. Die Konfiguration erfolgt über
New-CsTeamsComplianceRecordingPolicymit Zuweisung an Benutzergruppen.
Session Border Controller (SBC) Architektur
Ein Session Border Controller ist das zentrale Sicherheits- und Steuerungselement an der Grenze zwischen internem VoIP-Netzwerk und externen Carriern. Der SBC übernimmt Protokoll-Normalisierung, Codec-Transcoding, Topologie-Hiding und DDoS-Schutz. In Enterprise-Umgebungen mit mehreren Standorten und Carriern ist der SBC die kritischste Komponente der Sprachinfrastruktur.
- AudioCodes Mediant: Die Mediant-Serie (800/1000/2600/4000) bietet Hardware- und VM-basierte SBC-Lösungen. Die Konfiguration erfolgt über das Web-Interface oder die CLI. Wesentliche Konfigurationselemente sind IP Groups (Carrier/PBX-Zuordnung), IP Profiles (SIP-Varianten-Anpassung), Media Realms (RTP-Port-Bereiche pro Interface) und Routing Rules (Call-Routing-Logik). Für Teams Direct Routing wird der „Microsoft Teams Direct Routing Configuration Wizard“ genutzt.
- Topologie-Hiding: Der SBC maskiert interne IP-Adressen und SIP-Header gegenüber externen Netzen. Via Header-Manipulation-Rules (HMR) werden
Via,Contact,Record-RouteundP-Asserted-IdentityHeader umgeschrieben. Dies verhindert Informationsleckage und schützt die interne Netzwerkstruktur vor Reconnaissance-Angriffen. - Transcoding: Bei inkompatiblen Codecs zwischen Carrier (G.711) und internem Netz (Opus/G.722) übernimmt der SBC die Echtzeit-Transkodierung. Die DSP-Kapazität bestimmt die maximale Anzahl gleichzeitiger transkodierter Calls. Ein AudioCodes Mediant 800 unterstützt bis zu 200 transkodierte Sessions bei G.711↔G.729.
- Sicherheit & DDoS-Schutz: Der SBC implementiert SIP-Rate-Limiting (max. INVITE/s pro Quell-IP), SIP-Message-Validation (Erkennung malformierter Pakete), TLS-Terminierung mit Zertifikats-Pinning und eine integrierte SIP-Firewall mit Blacklist/Whitelist. Bei Überschreitung konfigurierbarer Schwellwerte werden Quell-IPs automatisch für definierte Zeiträume gesperrt.
Fax2Mail & analoge Migration
Die Migration von analogen Faxgeräten und Türsprechanlagen zu VoIP erfordert sorgfältige Planung. Während T.38 Fax-over-IP den zuverlässigsten Übertragungsweg darstellt, unterstützen nicht alle SIP-Provider dieses Protokoll. Fax2Mail-Lösungen bieten eine moderne Alternative, bei der eingehende Faxe als PDF per E-Mail zugestellt und ausgehende Faxe über ein Web-Portal oder E-Mail-Gateway versendet werden.
- T.38 Fax-over-IP: T.38 (ITU-T) überträgt Faxdaten als UDP/UDPTL-Pakete statt als Audio-Stream und ist damit unabhängig von Jitter und Paketverlust. Die Aktivierung erfordert T.38-Support auf SBC, PBX und SIP-Trunk. In Asterisk:
fax_detect=bothundt38_udptl=yesin der Endpoint-Konfiguration. Fallback auf G.711-Passthrough muss konfiguriert werden, falls T.38-Negotiation fehlschlägt. - Fax2Mail-Gateway: Lösungen wie HylaFAX+ mit AVM-Gateway oder cloud-basierte Dienste (eFax, Retarus) empfangen Faxe und konvertieren sie via Ghostscript/LibreOffice in PDF. Die Zustellung erfolgt über SMTP mit konfigurierbarem Routing (DID → E-Mail-Adresse). Ausgehende Faxe werden als E-Mail-Anhang an
[email protected]gesendet. - Analog Telephone Adapter (ATA): Für Türsprechanlagen, Aufzüge und Frankiermaschinen werden ATAs (Grandstream HT801/802, Cisco ATA 191) eingesetzt. Diese wandeln analoge Signale in SIP/RTP um. Kritisch sind die Konfiguration von DTMF (RFC 2833 / SIP INFO) und die Deaktivierung von Silence Suppression (VAD), da analoge Geräte auf kontinuierlichen Audio-Stream angewiesen sind.
- Migrationsplanung: Die Umstellung erfolgt in Phasen: Inventarisierung aller analogen Ports → Klassifizierung (Fax/Tür/Aufzug/Alarm) → Pilotphase mit ATA-Testgeräten → paralleler Betrieb (ISDN + VoIP) → vollständige Migration. Notfalleinrichtungen (Aufzugnotruf) erfordern zusätzlich eine USV-gestützte Stromversorgung des ATA und eine dedizierte VLAN-Anbindung.
QoS für VoIP
Quality of Service (QoS) ist die Grundlage für eine zuverlässige VoIP-Kommunikation. Ohne priorisierte Behandlung von Sprachpaketen führen Netzwerk-Engpässe zu erhöhter Latenz (>150 ms), Jitter (>30 ms) und Paketverlust (>1 %), was die Sprachqualität massiv beeinträchtigt. Eine End-to-End-QoS-Strategie umfasst Klassifizierung, Marking, Queuing und Policing auf allen Netzwerkschichten.
- DSCP-Marking: VoIP-Signalisierung (SIP) wird mit DSCP CS3 (24) oder AF31 (26) markiert, Sprachdaten (RTP) mit DSCP EF (46 / Expedited Forwarding). Die Markierung erfolgt am Endgerät (IP-Telefon), am Access-Switch (Policy-Map) oder am SBC. Cisco-Konfigurationsbeispiel:
policy-map VOICE→class VOIP-RTP→set dscp ef→priority percent 30. - Traffic Shaping & Policing: Am WAN-Interface wird die verfügbare Bandbreite für Voice reserviert. Eine Faustregel: pro G.711-Call werden 87,2 kbit/s (inkl. L2-Overhead) benötigt. Bei einer 10-Mbit/s-Leitung können maximal 30 % (3 Mbit/s ≈ 34 Calls) für Voice reserviert werden. Shaping glättet Bursts via Token-Bucket, Policing verwirft überschüssige Pakete — für Voice ist Shaping vorzuziehen.
- VLAN-Segmentierung: Voice-Traffic wird in ein dediziertes VLAN (z. B. VLAN 100) separiert, um Broadcast-Domains zu verkleinern und QoS-Policies granular anzuwenden. Switches konfigurieren LLDP-MED oder CDP, um IP-Telefonen automatisch das Voice-VLAN zuzuweisen. Die DHCP-Konfiguration im Voice-VLAN liefert neben IP-Adresse auch TFTP-Server und NTP-Server für die Telefon-Provisionierung.
- Monitoring & MOS-Score: Die Sprachqualität wird über den Mean Opinion Score (MOS, Skala 1–5) bewertet. Werte über 4.0 gelten als „gut“. Tools wie VoIPmonitor, Homer SIP Capture oder der 3CX Call Quality Report erfassen RTCP-XR-Daten (RFC 3611) und berechnen R-Faktor/MOS in Echtzeit. Alarme werden bei MOS < 3.5 oder Paketverlust > 0.5 % ausgelöst.
Ausfallsicherheit & Failover
Telefonausfälle haben unmittelbare geschäftliche Auswirkungen — von verpassten Kundenanrufen bis zu unterbrochenen Notfallketten. Eine resiliente VoIP-Architektur muss Ausfallszenarien auf allen Ebenen adressieren: Provider, WAN-Anbindung, SBC, PBX und Endgeräte. Das Ziel ist eine Verfügbarkeit von 99,99 % (max. 52 Minuten Downtime pro Jahr).
- SIP-Trunk-Redundanz: Zwei oder mehr SIP-Trunks von unterschiedlichen Carriern werden konfiguriert, wobei DNS SRV Records (
_sip._udp.domain.tld) mit unterschiedlichen Prioritäten und Weights die automatische Umschaltung ermöglichen. Bei Registrierungsverlust (SIP 408/503) schwenkt die PBX innerhalb von Sekunden auf den Backup-Trunk. Die Rufnummernportabilität zwischen Carriern muss vertraglich sichergestellt sein. - PBX-Hochverfügbarkeit: 3CX unterstützt kein natives HA-Clustering. Die Hochverfügbarkeit wird über VM-Replikation (VMware vSphere HA / Hyper-V Replica) oder Container-Orchestrierung (Docker Swarm / Kubernetes) realisiert. Die PostgreSQL-Datenbank der 3CX wird über Streaming-Replikation auf einen Standby-Knoten synchronisiert. RTO (Recovery Time Objective): <60 Sekunden bei VM-Failover.
- WAN-Failover: Eine dual-homed WAN-Anbindung (z. B. Glasfaser + LTE-Backup) mit SD-WAN-Steuerung ermöglicht automatisches Failover bei Leitungsausfall. Der SD-WAN-Controller (Cisco Viptela, Fortinet SD-WAN) überwacht die Link-Qualität und routet VoIP-Traffic priorisiert über den besten verfügbaren Pfad. SIP-Sessions bleiben bei Mid-Call-Failover dank SIP Session Timers (RFC 4028) erhalten.
- Survivable Branch Appliance: Für Standorte ohne zuverlässige WAN-Verbindung wird ein lokaler SBC mit Survivability-Funktion eingesetzt. Im Normalfall routet der SBC alle Calls zur zentralen PBX. Bei WAN-Ausfall übernimmt der SBC lokale Anrufsteuerung mit eingeschränktem Feature-Set (interne Calls, PSTN-Breakout über lokalen SIP-Trunk). Nach WAN-Wiederherstellung erfolgt automatische Re-Synchronisation mit der Zentrale.
Telefonie modernisieren?
Wir implementieren 3CX oder Microsoft Teams Telefonie, konfigurieren SIP Trunks mit Failover und optimieren Ihre VoIP-Infrastruktur mit professionellem QoS-Design.
Kostenlose Erstberatung →
