Telefonie / VoIP – Grundlagen

Was ist VoIP und warum ist es anders als ein normales Telefonat?

Klassische Festnetztelefonie (PSTN – Public Switched Telephone Network) reserviert für jedes Gespräch eine dedizierte Leitung. Du rufst an, eine Schaltung wird aufgebaut, der Kanal bleibt exklusiv für euch – egal ob ihr gerade redet oder schweigt.

VoIP (Voice over IP) macht das komplett anders: Deine Stimme wird digitalisiert, in kleine IP-Pakete zerschnitten und über das ganz normale Datennetz transportiert. Kein dedizierter Kanal – die Pakete teilen sich die Leitung mit HTTP-Traffic, E-Mails und allem anderen. Das ist billiger und flexibler, stellt aber höhere Anforderungen an die Netzwerkqualität.

Im KMU-Alltag begegnet dir VoIP in vielen Formen:

• Klassische IP-Telefonanlage im Serverraum (On-Premise PBX wie 3CX, Auerswald, Cisco)
• Cloud-Telefonanlage beim Provider (Hosted PBX / UCaaS)
• Microsoft Teams Phone als Ersatz für die traditionelle Telefonanlage
• Softphone-Apps auf dem PC oder Smartphone (Zoiper, 3CX App, Teams)

Die zwei zentralen Protokolle: SIP und RTP

VoIP trennt konsequent zwischen Signalisierung (Wer ruft wen an? Wann auflegen?) und Medientransport (die eigentlichen Audiodaten). Dafür gibt es zwei verschiedene Protokolle.

SIP – Session Initiation Protocol

SIP (RFC 3261) ist ein textbasiertes Protokoll – ähnlich wie HTTP. Es baut Verbindungen auf, ändert sie und baut sie wieder ab. SIP kümmert sich nicht um den eigentlichen Ton, nur um die Steuerung.

SIP-Nachrichten, die du kennen solltest:

SIP nutzt standardmassig Port 5060 (UDP/TCP) für unverschlüsselte und Port 5061 (TLS) für verschlüsselte Verbindungen.

RTP – Real-time Transport Protocol

RTP (RFC 3550) überträgt die eigentlichen Audiodaten. Es läuft über UDP – und das aus gutem Grund: UDP ist verlustbehaftet, aber schnell. Bei TCP würde eine Neuübertragung verlorener Pakete für Verzögerungen sorgen. Ein kurzer Aussetzer im Ton ist besser als eine halbe Sekunde Verzögerung.

RTP-Ports sind dynamisch und werden im SDP-Abschnitt (Session Description Protocol) des SIP-INVITE ausgehandelt. Typischer Bereich: UDP 10000–20000 (oder 16384–32767, je nach System).

SRTP (Secure RTP) verschlüsselt den Audiostrom – heute Standard bei modernen Systemen. Die Signalisierung läuft dann über SIP/TLS, der Medienstrom über SRTP. Ohne Verschlüsselung könnte jeder mit Wireshark im gleichen Netzwerk dein Gespräch mithören.

Typische VoIP-Komponenten im KMU

Ein VoIP-Setup besteht aus mehreren Bausteinen, die zusammenspielen müssen:

IP-Telefon / Hardphone

Physisches Tischtelefon mit Netzwerkanschluss. Bezieht seine IP-Konfiguration per DHCP, meldet sich dann am SIP-Server (PBX) an. Bekannte Hersteller: Yealink, Snom, Cisco, Poly (ehemals Polycom). Viele Modelle werden per PoE (Power over Ethernet) mit Strom versorgt – kein separates Netzteil nötig.

Softphone

Software auf PC oder Smartphone. Gleiche Protokolle wie Hardphone, läuft aber in einer App. Beispiele: Zoiper, 3CX App, MicroSIP, Linphone (Open Source). Praktisch für Homeoffice ohne physisches Telefon.

PBX / IP-Telefonanlage

Die Vermittlungsstelle. Steuert interne Durchwahlen, Warteschlangen, Weiterleitungsregeln, Voicemail, Konferenzbrücken. Im KMU-Umfeld sehr verbreitet:

• 3CX (Windows/Linux, auch Cloud, kostengünstig)
• Auerswald (deutsches Unternehmen, viel in DACH)
• Cisco UCM / CUCM (Enterprise-Umfeld)
• FreePBX / Asterisk (Open Source, sehr flexibel)

SIP-Trunk

Die Verbindung vom internen System nach draussen, ins öffentliche Telefonnetz (PSTN). Du mietest beim Provider (z.B. Swisscom, Sipcall, Telekom, Sipgate) eine oder mehrere Rufnummern. Der SIP-Trunk liefert diese Nummern und stellt die Verbindung ins klassische Festnetz her. Wichtig: Ein SIP-Trunk kann mehrere gleichzeitige Leitungen (Channels) haben.

Session Border Controller (SBC): Der Grenzwächter zwischen den Netzen

Sobald VoIP über eine eigene Netzgrenze hinausgeht – vom Firmennetz ins offene Internet, zum SIP-Trunk-Provider oder zu Microsoft Teams via Direct Routing – braucht es eine Instanz, die genau an dieser Grenze sitzt und den Verkehr kontrolliert: den Session Border Controller (SBC). Ein SBC ist eine Kombination aus Firewall, NAT-Vermittler und Protokoll-Übersetzer, spezialisiert auf SIP und RTP.

Die wichtigsten Aufgaben eines SBC:

Topology Hiding

Der SBC ersetzt in den SIP-Headern (Via, Contact, Record-Route) die internen IP-Adressen und Hostnamen der PBX durch seine eigene öffentliche Adresse. Nach aussen sieht der Provider nur den SBC – nie die interne Netzwerkstruktur, nie die echte IP der PBX. Das ist Sicherheit (kein Angreifer sieht das interne Layout) und Praktikabilität zugleich: Interne IP-Adressen können sich ändern, ohne dass der Provider je davon erfährt.

Media Transcoding

Nicht jeder Endpunkt spricht denselben Codec. Die PBX bietet vielleicht G.722 an, der Provider verlangt G.711, ein mobiler Teilnehmer nutzt Opus. Der SBC dekodiert den einen Codec und kodiert ihn live in den anderen um – Transcoding. Das kostet Rechenleistung (ein Grund, warum SBC-Appliances oft dedizierte DSP-Hardware oder leistungsstarke CPUs mitbringen), löst aber genau die Interop-Probleme, die sonst zu “kein Ton” führen.

Weitere Aufgaben eines SBC

• SIP-Normalisierung: Gleicht Unterschiede zwischen SIP-Dialekten verschiedener Hersteller aus – Cisco, Microsoft und ein Provider-Trunk sprechen nicht immer exakt dieselbe SIP-Grammatik
• NAT-Traversal: Löst das unter “Einseitiges Audio” beschriebene Problem strukturell, weil der SBC als Media-Relay in der Mitte sitzt
• Schutz vor DoS und Toll Fraud: Rate-Limiting auf REGISTER/INVITE, Blockieren verdächtiger Anrufmuster
• Verschlüsselung terminieren: SIP/TLS und SRTP nach aussen, unverschlüsseltes SIP/RTP intern (oder umgekehrt für Ende-zu-Ende-Verschlüsselung)

Bei Microsoft Teams Phone mit Direct Routing ist ein zertifizierter SBC zwingend vorgeschrieben – Microsoft führt eine Liste zertifizierter Modelle (AudioCodes, Ribbon, Oracle, TE-Systems). Der SBC ist hier das Bindeglied zwischen einem klassischen SIP-Trunk und dem Microsoft-Tenant. Mehr zur Einrichtung auf der Seite Microsoft Teams Administration.

Codecs: Wie wird Sprache komprimiert?

Ein Codec (Coder/Decoder) wandelt das analoge Audiosignal in digitale Datenpakete um und zurück. Die Wahl des Codecs beeinflusst Qualität und Bandbreitenbedarf:

Faustregel: Im LAN immer G.711 oder G.722 nehmen – Qualität vor Bandbreite. Über langsame WAN-Strecken kann G.729 sinnvoll sein. Wenn deine PBX und das IP-Telefon verschiedene Codecs anbieten, verhandeln sie automatisch einen gemeinsamen (Codec-Negotiation via SDP). Gibt es keinen gemeinsamen Codec: kein Ton – ein klassischer Fehler.

QoS und Voice VLAN: Warum VoIP eigene Netzwerkbehandlung braucht

VoIP ist extrem empfindlich auf Verzögerungen und Paketverluste. Ein grosser Download im Hintergrund kann ein Gespräch unverständlich machen. Deshalb braucht VoIP-Traffic besondere Behandlung im Netzwerk.

Die drei kritischen Qualitätsgrossen

DSCP – Pakete markieren

DSCP (Differentiated Services Code Point) ist ein 6-Bit-Feld im IP-Header. Damit markierst du VoIP-Pakete als hochprioritär. Der Switch und Router erkennen die Markierung und behandeln diese Pakete bevorzugt.

Für Sprachpakete (RTP) verwendet man DSCP EF (Expedited Forwarding) = 46. Signalisierungspakete (SIP) bekommen typischerweise DSCP CS3 = 24 oder AF31 = 26.

Die meisten modernen IP-Telefone und PBX-Systeme markieren ihre Pakete automatisch. Wichtig ist, dass der Switch die Markierung respektiert und nicht überschreibt.

Voice VLAN

Ein separates VLAN für Telefone hat mehrere Vorteile:

• Saubere Trennung von Daten- und Sprachverkehr
• Eigene DHCP-Optionen für Telefone (Option 66/160 für Provisionierungs-URL)
• Einfachere QoS-Konfiguration
• Sicherheit: Telefone können nicht auf Daten-VLAN-Ressourcen zugreifen

Ein Cisco-Switch-Port für ein IP-Telefon mit angeschlossenem PC (Daisy-Chain) konfigurierst du typischerweise so:

# Cisco IOS Beispiel: Access Port mit Voice VLAN
interface GigabitEthernet0/1
 switchport mode access
 switchport access vlan 10        ! Daten-VLAN fuer den PC
 switchport voice vlan 20         ! Voice VLAN fuer das Telefon
 spanning-tree portfast

End-to-End QoS über WAN: MPLS vs. Internet-VPN

DSCP-Markierung und Voice VLAN lösen die QoS-Frage nur im eigenen LAN. Sobald Sprache über die eigene Standortgrenze hinausgeht – Filialanbindung, Homeoffice, SIP-Trunk zum Provider – entscheidet die WAN-Anbindung, ob die Priorisierung überhaupt etwas nützt. DSCP-Markierungen wirken nur, wenn jedes Gerät auf dem Weg sie auch respektiert. Das öffentliche Internet tut das grundsätzlich nicht: Ein Provider-Router irgendwo dazwischen kennt die eigenen DSCP-Prioritäten nicht und behandelt VoIP genauso wie jeden anderen Traffic.

MPLS: Garantierte Bandbreite, aber teuer

MPLS (Multiprotocol Label Switching) ist ein Provider-betriebenes, privates WAN. Der Provider transportiert den Traffic über sein eigenes Backbone und kann dabei vertragliche Class-of-Service-Zusagen einhalten, zum Beispiel eine Voice-Klasse mit garantiert unter 20 ms Latenz und unter 0.1 % Paketverlust. Weil das Netz nicht das offene Internet ist, funktioniert Ende-zu-Ende-QoS zuverlässig: Die DSCP-Markierung wird vom Provider ausgelesen und in eigene MPLS-Labels (EXP-Bits) übersetzt.

Nachteile: deutlich teurer als reine Internet-Anbindungen, längere Vertragslaufzeiten, oft langsamer bei der Anbindung neuer Standorte, und eine engere Bindung an einen einzelnen Carrier.

Internet-VPN und SD-WAN: Günstig, aber ohne Garantie

Ein IPsec-VPN über normales Internet ist günstig und schnell aufgebaut, bietet aber von Haus aus keine QoS-Garantien – die Leitung wird mit dem gesamten übrigen Internet-Verkehr des Providers und aller anderen Kunden geteilt. Mehr zu den Grundlagen auf der Seite VPN Grundlagen.

SD-WAN verbessert das: Es kombiniert mehrere Uplinks (z.B. Glasfaser und 4G/5G als Backup), misst pro Pfad laufend Latenz, Jitter und Paketverlust und leitet Voice-Traffic aktiv über den jeweils besten Pfad – teilweise sogar mitten in einem laufenden Gespräch, indem Forward Error Correction und Packet Duplication kurze Ausfälle ausgleichen. Details dazu auf der Seite SD-WAN Grundlagen.

Traffic Shaping als Ergänzung

Unabhängig von der WAN-Anbindung lohnt sich an der Engstelle – meist der eigene Internet-Uplink – aktives Traffic Shaping: das kontrollierte Begrenzen und Priorisieren des ausgehenden Datenstroms, bevor der Router-Puffer überläuft. Ohne Shaping führt ein grosser Upload (Backup, Cloud-Sync) dazu, dass Pakete im Router-Ausgangspuffer stauen (“Bufferbloat”) und Sprachpakete trotz DSCP-Markierung in der Warteschlange stecken bleiben.

# Beispiel: Traffic Shaping und Priority Queueing auf einem Cisco-Router
class-map match-all VOICE
 match dscp ef
!
policy-map WAN-QOS
 class VOICE
  priority percent 20          ! garantierte Prioritaets-Bandbreite fuer Sprache
 class class-default
  fair-queue
  random-detect
!
interface GigabitEthernet0/0
 service-policy output WAN-QOS

Fax over IP: T.38 und Alternativen

Auch wenn E-Mail und digitale Signaturen das klassische Fax grösstenteils verdrängt haben, läuft es in manchen Branchen weiter im Hintergrund – Arztpraxen, Anwaltskanzleien, Behörden, Speditionen. Wird eine analoge Telefonanlage durch VoIP ersetzt, ist das Fax oft die erste Anwendung, die Probleme macht: Faxmodems sind für stabile, verzögerungsfreie Analogleitungen gebaut – das Gegenteil von einem paketvermittelten IP-Netz.

Warum G.711-Pass-through oft scheitert

Faxsignale sind Modem-Töne (bis zu 14’400 bit/s bei Fax Class 3). Schickt man sie einfach als normalen Sprach-Codec (G.711) durchs Netz, reicht bereits minimaler Paketverlust ab rund 1 % oder etwas Jitter, um die Übertragung abbrechen zu lassen. Ein komprimierter Codec wie G.729 funktioniert für Fax praktisch nie.

T.38: Der dedizierte Fax-Standard

T.38 (ITU-T) ist speziell für Fax over IP entwickelt: Statt die Modemtöne als Audio zu übertragen, decodiert das sendende Gateway das Faxsignal und überträgt die eigentlichen Bilddaten strukturiert über UDP (meist als UDPTL), mit Redundanz und Fehlerkorrektur. Das macht T.38 deutlich robuster gegenüber Netzwerkproblemen – tolerant gegenüber Paketverlusten von über 10 %, wo G.711-Pass-through schon bei 1 % versagt.

Voraussetzung: Beide Enden müssen T.38 unterstützen und während des Anrufaufbaus per SIP-re-INVITE von Audio auf T.38 umschalten. Genau das ist die häufigste Fehlerquelle: Unterstützt die PBX oder der Provider T.38 nicht sauber, bleibt das Gespräch im Audio-Modus und die Faxübertragung schlägt fehl.

Praxis-Alternativen im KMU

In der Praxis ersetzt man klassisches Faxen zunehmend durch:

• Fax-to-Mail-Dienste: Eingehende Faxe werden als PDF per E-Mail zugestellt, ausgehende PDFs werden vom Provider ins Faxnetz konvertiert – kein FoIP-Ärger mehr im eigenen Netz
• Analoge FXS-Adapter an einer separaten, klassischen Amtsleitung für das eine Faxgerät, das partout nicht sterben will – oft der pragmatischste Weg, wenn T.38-Troubleshooting zu aufwendig wird
• Cloud-Fax-APIs in ERP- oder DMS-Systemen, wo Fax nur noch ein Versandkanal neben E-Mail ist

Microsoft Teams Phone

Teams kann als vollständige Cloud-Telefonanlage genutzt werden – ohne separate PBX. Du brauchst dafür:

1. Microsoft Teams Phone-Lizenz (Add-on zu M365 Business/Enterprise)
2. Eine Anbindung ans Telefonnetz – entweder:
   • Microsoft Calling Plan: Microsoft selbst liefert den SIP-Trunk und Nummern (einfach, aber begrenzte Länder und teurer)
   • Direct Routing: Du bringst deinen eigenen SIP-Trunk mit (via Session Border Controller, SBC)
   • Operator Connect: Provider-Partnerschaft, Nummern kommen direkt in Teams

Direct Routing ist die flexibelste Variante und im DACH-Raum sehr verbreitet: Dein Provider (z.B. Swisscom, Telekom, Sipgate) liefert einen SIP-Trunk, ein zertifizierter SBC verbindet ihn mit dem Microsoft-Teams-Tenant (Details zur Rolle des SBC weiter oben im Abschnitt “Session Border Controller”).

Verwaltung läuft über das Teams Admin Center unter admin.teams.microsoft.com. Mehr dazu auf der Seite Microsoft Teams Administration.

Nummernportierung, E.164 und Notrufstandort im Homeoffice

E.164: Das internationale Nummernformat

SIP-Trunks, PBX-Routingtabellen und Provider-Schnittstellen arbeiten intern praktisch immer mit dem Format E.164 (ITU-T-Standard): Eine Rufnummer beginnt mit +, gefolgt von Landesvorwahl und nationaler Nummer, ohne Leerzeichen, Klammern oder führende Null – maximal 15 Ziffern insgesamt. Eine Schweizer Nummer sieht in E.164 so aus: +41791234567 (nicht 079 123 45 67 oder 0041 79 123 45 67).

Warum das wichtig ist: Normalisiert die PBX-Routingregel nicht konsequent auf E.164, entstehen klassische Symptome – Anrufe an eine Nummer mit nationalem Präfix funktionieren, dieselbe Nummer im internationalen Format aber nicht (oder umgekehrt), weil zwei verschiedene Routing-Regeln nie greifen. In 3CX zum Beispiel unter den ausgehenden Regeln die Nummernnormalisierung konsequent auf E.164 stellen und die Amtsholung sauber entfernen.

Nummernportierung

Beim Providerwechsel sollen bestehende Rufnummern erhalten bleiben. Üblicher Ablauf in der Schweiz:

1. Kündigung beim alten Provider – die Portierung ersetzt keine separate Kündigung, meist braucht es beides
2. Portierungsauftrag beim neuen Provider stellen, inklusive Kundennummer und Vertragsdaten des alten Anbieters
3. Der neue Provider koordiniert die Portierung über die Nummernportierungsdatenbank; ein Umschaltetermin wird vereinbart
4. Kurze Unterbrechung während der eigentlichen Umschaltung – meist wenige Minuten bis Stunden, ausserhalb der Geschäftszeiten planen

Notrufstandort im Homeoffice – Pflicht in der Schweiz

Bei klassischer Festnetztelefonie ist die Adresse fix mit dem Anschluss verknüpft – ein Notruf landet automatisch bei der zuständigen Alarmzentrale mit korrekter Standortangabe. Bei VoIP ist das nicht automatisch der Fall, weil ein SIP-Endpunkt (Softphone, IP-Telefon) an praktisch jedem beliebigen Internetanschluss betrieben werden kann. Das BAKOM nennt das nomadische Nutzung.

Nach der Fernmeldedienstverordnung (FDV) müssen Anbieter öffentlicher Telefondienste sicherstellen, dass Notrufe an die richtige Alarmzentrale geleitet werden und der Standort identifiziert wird. Massgebend dafür ist die vom Kunden beim Vertragsabschluss hinterlegte Anschlussadresse. Bei nomadischer Nutzung – etwa ein Softphone, das mit der Firmen-Durchwahl von zuhause aus betrieben wird – kann der Provider für das Notruf-Routing nur den vertraglich hinterlegten Standort verwenden, nicht den tatsächlichen physischen Standort im Moment des Anrufs.

Praktische Konsequenz fürs KMU:

• Wird ein Mitarbeiter dauerhaft im Homeoffice mit einem Firmen-Softphone oder -IP-Telefon eingerichtet, muss die Notrufadresse bei der PBX beziehungsweise beim Provider auf die Homeoffice-Adresse angepasst werden – sonst würde im Notfall die Rettung an den Firmensitz statt an die Wohnadresse geschickt
• Bei mehreren Homeoffice-Standorten braucht es entweder pro Nebenstelle eine individuelle Notrufadresse (viele Cloud-PBX- und Teams-Phone-Lösungen unterstützen das über Emergency Location Identification) oder eine klare Anweisung, im Ernstfall vom privaten Mobiltelefon aus den Notruf zu wählen
• Bei Microsoft Teams Phone lässt sich das über Dynamic Emergency Calling und Netzwerk-Standort-Zuordnungen im Teams Admin Center abbilden, siehe auch Microsoft Teams Administration
• Diese Pflicht regelmässig zu testen und zu dokumentieren gehört zu einer sauberen IT-Dokumentation, siehe auch IT-Dokumentation und Inventar

Kapazitätsplanung mit Erlang-B

Wie viele gleichzeitige Kanäle braucht ein SIP-Trunk wirklich? Zu wenig Kanäle bedeuten Besetztzeichen in Stosszeiten, zu viele sind unnötig gemietete und bezahlte Kapazität. Die Erlang-B-Formel – benannt nach dem dänischen Mathematiker Agner Krarup Erlang – beantwortet genau diese Frage. Sie ist seit über 100 Jahren der Industriestandard für Trunk-Dimensionierung, ursprünglich für analoge Vermittlungsstellen entwickelt, heute genauso gültig für SIP-Trunk-Kanäle.

Die Eingangsgrössen

• Verkehrsangebot in Erlang (A): Ein Erlang entspricht einer Leitung, die während der gesamten betrachteten Stunde durchgehend belegt ist. Berechnung: A = (Anzahl Anrufe pro Stunde × durchschnittliche Gesprächsdauer in Minuten) / 60
• Blockierwahrscheinlichkeit (B): Wie viel Prozent der Anrufe dürfen auf Besetzt laufen? Üblich für Geschäftskunden sind 1 % (0.01) bis 2 % (0.02)
• Gesucht: die Anzahl benötigter Kanäle (n)

Rechenbeispiel

Ein KMU hat in der Stosszeit durchschnittlich 60 externe Gespräche pro Stunde, jedes im Schnitt 3 Minuten lang.

A = (60 Anrufe × 3 Minuten) / 60 Minuten = 3 Erlang

Bei einer angestrebten Blockierwahrscheinlichkeit von 1 % liefert die Erlang-B-Tabelle für 3 Erlang 8 Kanäle. Mit nur 5 Kanälen läge die Blockierwahrscheinlichkeit bereits bei über 10 % – jeder zehnte Anruf bekäme in der Stosszeit ein Besetztzeichen.

(Werte gerundet nach der Standard-Erlang-B-Tabelle. Für exakte Werte oder krumme Eingaben: Online-Erlang-B-Rechner verwenden oder in Excel die Formel iterativ lösen.)

Praxistipp für die Trunk-Bestellung

Nicht nur mit dem Durchschnitt planen, sondern mit der tatsächlichen Stosszeit – meist zwischen 10 und 11 Uhr sowie zwischen 14 und 15 Uhr im Büroalltag. Beim Provider nach elastisch buchbaren Kanälen fragen, statt eine feste Zahl über Jahre vertraglich zu binden.

Redundanz: SIP-Trunk-Failover und Least-Cost-Routing

SIP-Trunk-Failover

Ein einzelner SIP-Trunk zu einem einzigen Provider ist ein Single Point of Failure – fällt die Internetleitung oder der Provider aus, ist die Firma telefonisch nicht mehr erreichbar. Für Betriebe, die auf Erreichbarkeit angewiesen sind (Handwerksbetriebe mit Notdienst, Arztpraxen, Support-Hotlines), gehören deshalb mindestens zwei unabhängige Pfade zum Standard:

• Zwei SIP-Trunks von zwei verschiedenen Providern, mit automatischem Failover in der PBX-Konfiguration (Priorität A/B, Health-Check per SIP OPTIONS-Ping)
• Zwei physisch getrennte Internetanschlüsse, zum Beispiel Glasfaser plus 4G/5G-Backup – sonst nützt der zweite Trunk nichts, wenn beide über dieselbe Leitung laufen
• Ein analoger Notfallanschluss als letzte Rückfallebene, angeschlossen über einen FXO-Port an der PBX – bei kompletter WAN-Störung immer noch ein funktionierender Kanal nach draussen

In 3CX konfiguriert man das über mehrere SIP-Trunks mit Failover-Reihenfolge; die PBX erkennt über regelmässige OPTIONS-Pings, ob ein Trunk erreichbar ist, und schaltet automatisch auf den nächsten um:

SIP-Trunk 1 (Provider A, primaer)    -> OPTIONS alle 60s
SIP-Trunk 2 (Provider B, Failover)   -> aktiviert bei 3 fehlgeschlagenen Pings
Notfall-FXO (analoge Leitung)        -> letzte Instanz, manuell oder per Regel

Least-Cost-Routing (LCR)

Hat eine Firma mehrere SIP-Trunks – etwa für unterschiedliche Zielländer oder Mobil-/Festnetz-Tarife – lohnt sich Least-Cost-Routing: Die PBX wählt automatisch den günstigsten verfügbaren Trunk für jede Zielrufnummer, basierend auf einer Routingtabelle mit Vorwahlmustern und hinterlegten Tarifen.

Beispielhafte LCR-Regel-Logik:

LCR und Failover ergänzen sich: Die Routingtabelle bestimmt den primär gewünschten Trunk pro Ziel, das Failover greift, wenn genau dieser Trunk gerade nicht erreichbar ist – dann probiert die PBX die nächste Alternative in der Kette, auch wenn das minimal teurer wird.

Troubleshooting: Die häufigsten VoIP-Probleme

Einseitiges Audio (Ein-Weg-Audio)

Du hörst den anderen, er hört dich nicht – oder umgekehrt. Klassische NAT/Firewall-Ursache.

Was passiert: SIP signalisiert die interne IP-Adresse (z.B. 192.168.1.50) im SDP-Abschnitt. Der Provider sieht aber nur die externe IP. Die RTP-Pakete fliessen deshalb in die falsche Richtung.

Lösungsansätze:

• RTP-Ports (UDP 10000–20000) in der Firewall öffnen
• NAT-Hairpinning aktivieren
• SIP ALG deaktivieren (siehe Callout oben)
• In der PBX die externe IP konfigurieren (NAT-Traversal-Einstellungen)
• STUN-Server in der PBX-Konfiguration hinterlegen

Kein Ton / Codec-Probleme

Verbindung kommt zustande, aber kein Audio – kein Rauschen, gar nichts.

Ursachen:

• Codec-Mismatch: Telefon bietet G.722 an, Provider unterstützt nur G.711 → PBX-Konfiguration anpassen, nur gemeinsame Codecs aktivieren
• Falsche RTP-IP im SDP
• Firewall blockiert UDP-Ports

Diagnose mit Wireshark:

# Wireshark-Filter fuer SIP und RTP
sip || rtp

# Nur SIP INVITE zeigen
sip.Method == "INVITE"

# RTP-Pakete auf bestimmter IP
rtp && ip.addr == 192.168.1.50

Abbrüche und schlechte Qualität

Gespräche brechen nach 30–60 Sekunden ab, oder die Qualität ist schlecht (Aussetzer, Echo, roboterhafte Stimme).

Diagnosevorgehen:

# Latenz zum SIP-Provider messen
Test-NetConnection -ComputerName sip.provider.ch -Port 5060

# Paketverlust und Jitter ermitteln
ping -n 100 sip.provider.ch

# Bandbreite pro Gespraech abschaetzen:
# G.711: ~85-100 kbps (inkl. IP/UDP-Header)
# G.729: ~25-32 kbps
# Bei 10 gleichzeitigen Gespraechen mit G.711: ~1 Mbit/s Upload benoetigt

Wenn die Verbindung nach exakt 30 oder 60 Sekunden abbricht, liegt das oft am SIP-Session-Timer: Die PBX schickt ein re-INVITE zur Verbindungserhaltung, der Provider antwortet nicht wie erwartet. In 3CX: unter SIP-Trunk > Optionen > Session Timers anpassen.

Registration Failures

Das Telefon meldet sich nicht am SIP-Server an (kein Ausschlag, “nicht registriert” Display).

# SIP-Port testen
Test-NetConnection -ComputerName pbx.firma.local -Port 5060 -InformationLevel Detailed

# DNS aufloesen
Resolve-DnsName pbx.firma.local

Prüfe: Stimmen Benutzername, Passwort und Domain überein? Ist die Firewall-Regel für SIP (5060/5061) vorhanden? Ist der DHCP-Scope für das Voice VLAN korrekt konfiguriert?

Nützliche Diagnose-Tools

Ein kurzes Testrezept für den Alltag:

# 1. Latenz und Paketverlust zum SIP-Provider messen (100 Pings)
ping -n 100 sip.deinprovider.ch | Select-String "Minimum|Maximum|Average|loss"

# 2. UDP-Port-Erreichbarkeit testen (PowerShell)
$udpClient = New-Object System.Net.Sockets.UdpClient
$udpClient.Connect("sip.deinprovider.ch", 5060)
$udpClient.Close()
# Keine Exception = Port erreichbar

# 3. Traceroute zum SIP-Endpunkt
tracert sip.deinprovider.ch

# 4. Netzwerkqualitaet live pruefen
pathping sip.deinprovider.ch -n

Checkliste: Neue VoIP-Installation im KMU

Bevor du ein VoIP-System in Betrieb nimmst, geh diese Punkte durch:

1. Netzwerkinfrastruktur prüfen: Switch PoE-fähig? VLAN-Unterstützung vorhanden?
2. Voice VLAN einrichten: Eigenes VLAN für Telefone, DHCP-Scope konfigurieren
3. QoS aktivieren: DSCP EF (46) für RTP auf Switch und Router priorisieren
4. SIP ALG deaktivieren: In Firewall/Router nachsehen und abschalten
5. Firewall-Regeln setzen: SIP (5060/5061 TCP/UDP) und RTP-Bereich (UDP 10000–20000) freigeben
6. Bandbreite berechnen: Gleichzeitige Gespräche × 100 kbps (G.711) = benötigter Upload
7. Provisionierung testen: Telefon holt Konfiguration per DHCP Option 66 / HTTP
8. Verschlüsselung aktivieren: SIP/TLS + SRTP, besonders bei Cloud-PBX
9. Backup-Leitung planen: Was passiert bei Internetausfall? Failover auf Mobilnetz oder zweiten SIP-Trunk?
10. Notfallnummern testen: 112 / 117 / 144 müssen auch über VoIP zuverlässig funktionieren, Notrufadresse pro Homeoffice-Standort korrekt hinterlegt
11. Kanalzahl dimensionieren: Erlang-B-Berechnung für die erwartete Stosszeit statt Bauchgefühl
12. Least-Cost-Routing und Failover-Reihenfolge festlegen: Bei mehreren SIP-Trunks Routingtabelle dokumentieren und Failover aktiv testen

Weiterlernen

• Elektronik-Kompendium: VoIP Grundlagen – Solide Einführung mit Protokolldiagrammen
• Elektronik-Kompendium: SIP – SIP im Detail, Nachrichtenformat, Ablaufdiagramme
• 3CX: QoS und Echtzeit-Übertragung – Praxisorientierte QoS-Erklärung vom PBX-Hersteller
• Computer Weekly: SIP und RTP Troubleshooting – Troubleshooting-Grundlagen auf Deutsch
• Microsoft: Teams Phone Direct Routing – Offizielle Doku für Teams Phone mit eigenem SIP-Trunk
• BAKOM: Leitweglenkung und Standortidentifikation der Notrufe – Offizielle Regelung zu Notruf-Routing bei VoIP und nomadischer Nutzung
• TransNexus: Session Border Controller Basics – Grundlagen und Funktionsweise von SBCs im Detail
• Wikipedia: Erlang B – Herleitung und Mathematik der Formel
• RFC 3261 – SIP – Der Standard selbst, für wenn du es wirklich genau wissen willst

Verwandte Seiten: TCP/IP Grundlagen · DNS Grundlagen · VPN Grundlagen · SD-WAN Grundlagen · Microsoft Teams Administration · IT-Dokumentation und Inventar

Videos

YouTube

YouTube